Well, I wouldn’t try to incorporate as many as possible, just multiple, to show the user a certain range of possibilities you get with Panda3D. Certainly, it’s not possible – nor would it be a good idea – to try and showcase everything you can do with Panda (we’re not even covering non-game related applications), but it would be good if we could use the tech-demo to pleasantly surprise people with what Panda has to offer.
That’s true. Anyway, these were just some ideas I thought would be cool to start out with. Further discussions would undoubtedly lead to a more refined view of what exactly should be added and in what way. Let’s wait and see what others think !
For sure, the more samples, demos, tutorials, docs that exist for Panda the better!
So to summarize what I’m hearing on the thread (great discussion from everyone by the way):
Folks agree the current crop of Panda samples aren’t indicative of what the engine can do
It seems many people (from this thread alone) have ideas and would like to contribute to building out some better samples (including myself!)
The range of sample complexity desired, from this thread looks to be across the spectrum: from very simple/concise, to fully functional mini-games and mini-demos. And it looks like folks agree with the idea of doing both simultaneously - break the bigger samples up into smaller ones and have them import each other.
So let’s talk some ideas on how to execute? A few questions from my side (new to Panda dev here, although I’ve done lots of opensource through the years…)
Quality control - is there any persons that can review contributions from folks? If we have a growing set of samples that fit together, it would be nice if they were all well designed for this level of modularity. Who would those persons be if any? My guess is we would get a flurry of nice samples started but need to pass some bar of quality before they get into an official Panda source tree? It would be cool if some really senior/knowledgeable Panda devs could put eyes on this so things are put together well
Should we spin up a github repo and collaborate there until things are ready for submission?
Should we just plan to add to Panda’s existing sample folder? Or is this warranted to be some new structure someplace?
Although I’d like to get to fully-working 3rd person or 1st person mini games, I’m fond of the idea of starting with smaller, simpler samples that fit together to make the bigger ones. We could release early/release often and get a lot of feedback on the fundamentals before building the bigger pieces.
Another quick idea - I was thinking along the lines of how to make these new samples a bit more consistent, and try to keep an eye for visual appeal (so that folks new to Panda like what they see).
What do you think about the following free media packs for most of the 3d art? https://quaternius.com/
License seems good - almost public domain CC0.
It has animated characters, of a few different game genres, and lots of low poly static stuff (vegetation, etc.) to boot. Seems to fit Panda’s style already and being low poly would help with folks on lower hardware - good for samples to perform well right? And should work on mobile as well.
Just an idea, or if there are other more complete 3d art packs feel free to post here, I have a lot of scattered media that is of different formats and styles, but it’s hard to find something that is comprehensive and consistent.
I seriously doubt we’ll be able to make a great tech demo in the same vein as Half Life or Prey (2006) without doing entirely custom artwork. This kind of work takes a lot of time and is generally speaking not free of charge!
I am with you until this Act 2 part. This seems like a tractable yet ambitious demo. I’m imagining the aesthetic is like a Jim Burns painting. I think by far the hardest part would be making art assets to the quality level expected by the audience, which seems to be poorly defined at this point. How good is good enough?
I would suggest that this–whether housed in a single repository or multiple–be kept separate from the Panda repository. For one, it is a community project, not an official one. Whether the samples end up becoming official or not, I’m inclined to keep the initial phases of the work, at least, external to anything official.
I will note here that I think that even the small samples might benefit from having some sort of demonstrative program to show them off. A third-person camera-module, for example, doesn’t do much of interest without something to move it about, something for it to show, and something for it to potentially collide with.
These demonstrative programs needn’t be complex, however, let alone full games. Taking again the hypothetical third-person camera-module as an example, I imagine its individual demo being nothing more than the camera following a single character around a single, simple environment.
Hmm… My feeling is that I would want a showcase to impress with what the engine is capable of. And while the models there are good and often appealing, I’m not sure that the style used there is conducive to that end.
I do like the idea to use free art, and it may be worth looking for it, but I’m not sure that I’m a fan of that specific set for this purpose.
(Which is not to say that I think that they’re bad, let me clarify. Those models could indeed work well for a variety of games, I daresay!)
I mean, I don’t think that we’re talking about making anything anywhere near that big! This is a showcase, and potentially a tech demo–it needn’t be a full AAA game twenty hours long! (And indeed, I suspect that it would be better that it weren’t that.)
This is a question that I have, too. Specifically, what should the models include? Colour and normals, I imagine–but gloss maps? Glow maps? Other sorts of map?
Please forgive the double-post, but I thought it relevant to this thread to note that I’ve just set up a repository providing a simple third-person camera-controller, along with a very simple demo showing the controller in action.
Said demo isn’t pretty, I fear, and so doesn’t at time of writing meet the suggested standard for an official sample, I daresay. (I simply didn’t put much effort into creating good models for this purpose.)
However, it would be easy enough to swap out the models used, should better become available.
The thread for the controller should be in the “Code Snippets” sub-forum, here:
And the repository itself should be available from GitHub, here:
Wow very cool! And this is the second great set of example code we’ve gotten since starting the discussion.
I went ahead and started to update my original post to aggregate these links, also adding Simulan’s first person shooter example. I don’t want any of this great work to get lost in discussion. Thank you both for jumping right in and rolling up sleeves here.
I’m about to grab the code for the 3rd person cam example and kick the tires as well.
Thank you very much! I’m glad that you like it, and glad to have it listed in the first post!
Indeed, I think that aggregating such things in that first post is a good idea–as you say, that way they’re less likely to get lost as regards being part of this effort.
I’m working under the assumption that some bar of quality likely needs to be met for samples to get into Panda officially. Of course - any samples (Even hosted on github) are better than none - but, I’d really like to see Panda’s official sample library to grow as well! But not at the expense of quality, of course.
In my mind - more samples → easier to use engine → more contributors → ‘all panda users benefit!’
Just speaking from personal experience, especially with open-source projects there can be a lot of opinions on how to structure code, to keep things high-quality and consistent (regarding an official repository) there usually needs to be some sort of process.
Agreed here, for sure. From what I gather on this thread however - it looks like folks are supportive of the idea of building things out in pieces - smaller / simpler samples might only need simple little 3d meshes to make a testable app.
Once those smaller pieces are built out we can aggregate into some much bigger / more complex demos, and create media. I’m thinking working in small ‘baby steps’ helps to deliver lots of nice results and also - if these fit together well - give all the building blocks needed to put together the much bigger exciting stuff we all are eager for as well. (Just my opinion here!! Happy to hear other ideas of course!!)
Agree here. Simply out of curiosity (and since I’m so new) I’m wondering if there is any advice / guidance floating around that might help us structure things to ‘eventually’ be considered official, I’m just thinking that a nice secondary-goal is to help ‘all’ new users of Panda with better samples. Right now I feel like the out-of-the-box samples give the wrong impression. If that makes sense.
I’m open for other ideas as well! Or if there are any alternatives available. My thoughts here (all opinion, happy to hear others). Its nice if the samples ‘look nice/professional’ as well as ‘work well’. Having some art to draw from may help give a quality/consistency that helps to sell Panda, nice visuals are always good for 3d game engine demos. But not to go overboard, if the user needs a very modern GPU just to run a collision sample, then that may be overboard. Myself being a coder, I know that if I ‘made’ the art it would look much more terrible than if I used an artist’s. Also - making art can slow things down - it’s nice to have quickly available media.
Unreal engine uses a simple, animated blue character and cubes for the most part. And that’s a AAA game engine - so very basic stuff. Other samples do have themed/curated and very professional assets integrated, when they’re showcasing advanced features. Just ideas / food for thought!
I do see what you’re saying, indeed, I do believe. While a few of the samples are perhaps fine, some of them really do not convey well what the engine can do, I fear.
That said, I really don’t know what guidelines there might be for something to become “official”! For that I’ll defer to other forum-members!
Hmm… We do have a few assets already available, I believe: not long ago there was a similar drive to this, and while it didn’t get very far, it did end up resulting in a few things, as I recall:
I remember trying to create a convention for the documentation programming style. However, I am not a native English speaker, and it is difficult for me to write a text for it.
Panda uses several versions of python. So the code should work for everyone.
For example for formatting strings it is optimal to use format()
Avoid unnecessary dependencies, such as the gltf format, for python only. You can replace it with bam, so that C++ users are not left behind and can use these resources.
By programming style.
This is a transparent style.
from direct.showbase.ShowBase import ShowBase
from direct.task import Task
class Player():
def __init__(self):
pass
def update(self):
print("update player")
player = Player()
class Ai():
def __init__(self):
pass
def update(self):
print("update ai")
ai = Ai()
class MyApp(ShowBase):
def __init__(self):
ShowBase.__init__(self)
self.taskMgr.add(self.update, "global update")
# Global update.
def update(self, task):
player.update()
ai.update()
return Task.cont
app = MyApp()
app.run()
bad style
from direct.showbase.ShowBase import ShowBase
from direct.task import Task
class Player():
def __init__(self, base):
base.taskMgr.add(self.update, "player update")
def update(self, task):
print("update player")
return Task.cont
class Ai():
def __init__(self, base):
base.taskMgr.add(self.update, "ai update")
def update(self, task):
print("update ai")
return Task.cont
class MyApp(ShowBase):
def __init__(self):
ShowBase.__init__(self)
player = Player(self)
ai = Ai(self)
app = MyApp()
app.run()
And much more.
The cherry on the cake is that the ShowBase needs to be rewritten for a certain style of play.
Let’s not get lost in the weeds with regard to style and code structure. If it runs and runs well it is acceptable in my opinion. One can make arguments for and against many style guidelines. Unfortunately what doesn’t happen when style policing is, actually getting work done and presenting working solutions. Good code runs fast, compiles with a minimum of warnings and errors, contains tight logic structures.
I am personally excited about @Epihaius 's idea of the spaceship tech demo. Would it be technically possible to generate geoms to a specified shape? As in, I make a spaceship model outline and then your procedural geom code generates to that shape? I’m just trying to think through the actual implementation of a procedural spaceship which is then also a real game asset which we can walk around inside of and so forth.
@svf have you ever actually used the Unreal 4 default mannequin armature in Blender? Last time I worked with it, it was a cobbled together nightmare. My simplistic Armature in the Arena demo is superior, already, in terms of speed of building solutions upon it. If we defined actual quality standards for the assets I’d be more than happy to provide models to that standard. It is totally trivial to add some boxes, including collision simulated ones, to be beyond the standard of the Unreal 4 base environment within a few days or weeks.
Here I don’t. I think that there’s a strong argument to be made that “good code” is also readable: Readability eases understanding–even of one’s own code, and especially in large code-bases, I daresay. That in turn makes it easier to to spot potential issues and opportunities, to maintain code over time (especially–but not only–the code of others), and even simply to find where one left off or to build on what’s already there.
Indeed, I’d argue that in many cases it’s preferable to have code that’s readable but not ideally efficient than code that’s fast but impenetrable. (Barring performance-critical sections, of course.)
Okay, I’m not sure if this will affect my work though. I’m sure it’s possible to build a bunch of Classes around my logic to make it more readable, but it’s not something I’m likely to do myself. I am probably in the minority of programmers in that I find most Class groupings beyond the framework unnecessary or difficult to read. That’s just me, I just wouldn’t want to throw great code examples in the dust bin because they’re not 100% matching somebody’s rubric of quality.
Note that I said that good code is “readable”–not “readable to everyone” or even “readable to the majority”. As long as the code is readable to those who use it, then fair enough, I say.
Indeed, if changing your style would make the code less readable to you, then there’s a fair argument to be made there that doing so would make it, for you, worse code.
(Although that it is potentially worth being aware that one’s code might not be readable to others, of course. In some cases, comments might help in code that’s to be seen by other developers.)
All I was arguing, really, was that there’s at least that one more thing to code being “good”: readability.
The description I gave of the different acts might have given the impression that I wanted something that takes hours to complete, but that really wasn’t my intent. Each act could last for only a few minutes, with a minimal amount of assets needed to give the feeling of a single scene from a fully fleshed-out game.
As I’m not all that great myself at texturing and using special effects, I’m not in a position to judge what is “good enough” with regard to what others would want to contribute.
But generally speaking, while using all of these different kinds of maps could show what Panda can do with them, I think it depends on how much of a visual difference they make, per model. For example, a complex normal map can add lots of detail to a low-poly mesh, but if the model is high-resolution, then it won’t have the same impact and may even be redundant. Another example that comes to mind is the use of a gloss map for a wet stone wall. If the effect is too strong it can end up looking like plastic, while toning it down could make it barely noticeable. In that case it might be better to just not bother with it.
What I’d suggest then, is to start out with simple, low-poly models without any maps or effects and gradually enhance them and see what works and what doesn’t.
Indeed. And as such, it seems a bit early to me to already start worrying about details like what effects, maps, materials etc. to use for which models – I mean, have we already come to a consensus regarding the actual content of the tech-demo? It’s great if you want to use my ideas, of course, but maybe others would like to offer alternative ideas as well.
In terms of coding, one thing I would keep in mind is that to some extent, a tutorial or samples or anything that is meant to teach in some way, is responsible for potentially shaping the coding habits of new, inexperienced programmers. It happens often that someone new to programming starts a project by copying code from such instructional material and deems its style to be more-or-less authorative. Even if not, they will usually code around it in a way that adheres to that style, simple because “it works, so why not”. That would be one reason to have some kind of “standard”, I guess.
Apart from that, when I see things like a Panda method – e.g. attach_new_node – being used in some places written like that, while in other places it’s written like attachNewNode, then I worry a little bit that new Panda users are going to get confused – and might ultimately settle on a name that will get deprecated at some point (the camelCase version, to be precise). Yeah there I go again – I can be such a nag sometimes .
One reasonably straightforward way would be to create the model as a collection of 3D primitives (spheres, cylinders, boxes, etc.), which can easily be built up procedurally. My proposed geometry sample pack already contains an example where you can see this happen (primitives_assembly.py). In fact, it’s while making that particular sample that I got the starship-in-hangar idea.
If a shape consisting purely of primitives is unacceptable, the alternative would be to create the model in a modelling program as usual and clear its GeomTriangles primitive. Then it would be a matter of deciding on the exact order in which to re-add the triangles to it over time.
That’s fair! I have no argument with that scale, I think!
My quoted reply was, I think, in response to a mention of Half Life and Prey (2006)–both full-scale games, not brief tech-demos.
While I hear you, my thought is that this is intended to be a demo that impresses, that shows to a potential new user what Panda can do. If the assets are generally low-poly and without fancy effects, it may appear that such is all that the engine supports.
Polishing assets as we go might work, but I do then fear that they might be left half-complete.
Further, it might help to have some idea of what we’re aiming for in the end.
For my part, I’m less concerned with what is applied to what specific models, than with a general idea of what we’re aiming for. I’m not going to advocate for glow-maps on simple rocks, but should we be looking to have them on, say, neon-bedecked robots or glowing-eyed monsters? Or would we look for other approaches to keep it simple? And so on.
So less a fine-grained “let’s list what textures we’ll apply to everything, right now”, than “what level of flashiness are we aiming for?”.
That’s a risk in general with such an ambitious project, I fear. It needs people who are truly motivated to continue their part, to be sufficiently dedicated to see it through.
If you mean how to achieve a specific effect technically in the most efficient way possible (e.g. the use of shaders, appropriate material settings and the like), then I have to admit that I’m not the most qualified to answer this, I’m afraid. So I’m hoping that others more knowledgeable in that department will chime in on this.
Obviously, the flashier the better I’d say. Because, as you rightly said, it’s all about impressing people. There is the consideration that Panda3D has always prided itself of being able to run on lower-spec hardware though, but having certain effects (and model resolution) user-configurable should take care of that, I think.
So in conclusion – and assuming that my idea for the intro of the tech-demo is accepted – I’d suggest to go all out in whatever way the contributors feel most comfortable realizing those fancy visuals. The hangar itself, for example, could be littered with small blinking lights, glowing circuitry, screens with animated content and perhaps an additional layer of bloom on top of all that. That’s the kind of thing I’d like to see, but if you ask me the best, most efficient way to realize all that, then I must confess I don’t really know.
Great info! I started to keep track of the samples we’ve built in this thread as well as the links that are coming up to useful resources for building samples. Here’s the latest update:
New samples created by the community here! (Updated as we build them):
!
.