Never heard of “*” meaning None. OK then.
I’ve created this page, but again we will need more descriptions.
panda3d.org/manual/index.php … _Libraries
Also, I think some libraries are OS specific, so someone else should add those.
This page is pretty outdated: panda3d.org/manual/index.php … d_Examples
I think it could be replaced with something like this: panda3d.org/manual/index.php/Preusser
Reading actual game source code is a a great way to learn the engine, but you need to do a lot of manual searching to find them.
I’ll probably add something to the “Performance Issue: Python Calculation” and “Performance Issue: Collision System Misuse” pages now.
So what do you guys think of replacing the page in my previous post?
That looks good, thanks! Please go ahead and replace the page.
OK. I just added a small notice that the list is not meant to be complete and up-to-date:
panda3d.org/manual/index.php … d_Examples
I’m still hoping someone will add the missing descriptions to the few libraries and improve few others here so we can add it to the table of contents: panda3d.org/manual/index.php … _Libraries
Performance Issue: Python Calculation: panda3d.org/manual/index.php/Preusser
Preusser: what would really be nice is to get a great introduction/tutorial on how to get stunning rendering in Panda.
So far I’m onlly getting crappy scenes with ambient + a couple of directional lights, and most of the examples i’ve seen in the tutorials have poor quality.
There is no reason why Panda should not have nice realistic effects such as friends are getting in Irrlicht or Ogre.
grazie
tonio
Please post if there is anything I should change before adding the text to the “Performance Issue: Python Calculation” page.
@zonzagolo: Sorry, but there can’t be a single page for “how to get stunning rendering”. I’ve never seen anything like that in other engine’s documentation as well. it wouldn’t make much sense, there are hundreds of ways to make your scene look better, each deserving its own topic, stuffing them all in one page would be a bad idea. If you would read some more of the manual, I’m sure you would learn “how to get stunning rendering” by using different features explained in different pages.
I would suggest the pages about the “Shader Generator” and “Common Image Filters”.
It seems like a fine introduction to the problem to me. I might quibble with the emphasis a bit (a lot of times, troublesome Python routines can be improved simply by writing the Python code better), but it gets the point across. Thanks!
OK, I added a sentence like that.
I’ll probably also be able to write the “Collision system misuse” page.
The only things I can think of is wanting to use Geoms for collisions, using one big collision geometry instead of splitting it into parts and not using masks. Is there anything else I’m missing?
Poor geometric distribution, too many tiny little polygons, or too many “from” objects also come to mind.
I think the first means splitting the geometry into parts, but not splitting them equally, but what do tiny polygons mean?
Hello preusser
Actually I was looking for a micro-tutorial with some code example or guidance.
Shader generator sounds very good, is there a way to see the Cg code generated?
The point of egg-octree is that it structures your scene graph to match the geometric arrangement of the polygons, so that clusters of polygons that are close to each other are also grouped under the same node together. Clusters of nodes that are close to each other are in turn grouped under the same parent node together, and so on. This is a useful and important optimization, because when Panda traverses the scene graph for collisions, it tests the bounding volume of each node as it visits it (which includes the bounding volumes of all the nodes below that node), and if the bounding volume is completely outside the intersection, then it can avoid visiting that node and all of its children. So it’s very important that your bounding volumes be reasonably spaced apart. If you put all of your geometry under a single node (for instance), then Panda will have to test each one of them individually, instead of pruning whole sections of them at once.
By “too many tiny little polygons”, I’m just referring to the common mistake of using geometry created for visual rendering as your collision geometry (even if you convert it to CollisionSolids). There is usually far too much detail in that kind of geometry; collisions need to be much coarser. It’s not that there is a problem with small polygons per se, but there’s certainly a problem with too many polygons. The performance cost for collisions is directly proportional to the number of polygons it has to test, so if you test against a 10,000 polygon model, it will be 100 times slower than if you test against an equivalent 100 polygon model. And usually, for the purposes of collisions, that 100 polygon model is perfectly adequate (and maybe you can do it with a 10-polygon model or even a single CollisionSphere instead).
David
Just curious.
Would a very simple mesh, like a large box or cube, used as collision geometry, still be a really bad idea? I’m just thinking (probably wrongly ) that as its so simple it’s not much worse than a dedicated collision object.
I might be wrong, but I think there wouldn’t be any difference between using a CollisionPolygon generated from data read from a Geom (which happens when you set Geoms to collide) or a CollisionPolygon generated from data read from elsewhere like a file.
In the first case Panda will need to generate a CollisionPolygon from the visible geometry which will take additional time itself, but I don’t think the data used by CollisionPolygon and Geom are much different, except maybe vertices in Geoms have some additional data useless to the collision system which will probably get discarded anyway, so colliding with both shouldn’t be different if they have the same amount of polygons.
This will only be true for CollisionPolygon vs Geoms though, CollisionBox and the other specialized solids use different algorithms to check for collisions.
Um, hmm. I think there’s a bit of confusion here.
There are only two ways to get a CollisionPolygon: load it from an egg file, or create it explicitly. There’s no way built into Panda to convert a Geom into a CollisionPolygon. (You can, of course, write a loop to iterate through the vertices of the Geom and create your own set of CollisionPolygons, and that would be all right.)
There is a feature in Panda to use a Geom as if it were a CollisionPolygon directly, simply by setting the collide masks on the Geom appropriately. This is is far, far slower per-polygon than using the equivalent mesh of CollisionPolygons, because Panda has to do a lot of extra calculations on-the-fly, and then throw it away (since there’s no place to store this extra information in a GeomNode). With some effort, an industrious developer could improve this situation, but we haven’t worried too much about that, because we consider this feature to be just a quick hack for prototyping–you wouldn’t really want to collide with Geoms anyway, because Geoms are generally far too dense to use for collisions (see my point above).
The important thing to understand is that setting a collide mask on a GeomNode does not convert the GeomNode into a CollisionNode. You could, of course, easily write a function that does convert a GeomNode into a CollisionNode, by iterating through the vertices and creating the equivalent CollisionPolygons yourself, as I mention above. That would be fine.
Now, I think silveralex was asking about using a six-polygon GeomNode shaped like a box for collisions. Actually, this would be a 12-polygon GeomNode, because Geoms don’t support quads, only triangles. You could do this, and it would be slower than the equivalent box of 6 CollisionPolygons, but only a little bit slower really (because we’re only talking about 12 polygons here), so it probably wouldn’t matter that much to you.
Note that a CollisionBox is actually implemented internally with six CollisionPolygons.
David
Thx David, that’s exactly what I was asking.
So there is a bit of advantage to it, but it’s not huge in this specific case (using cube-shaped meshes and just setting their collide mask on)
I’ve set up a very simple city scene with buildings made of different size cubes and I have actors running around. I set the collide mask on to prevent the actors from running through them and it works great. Was wondering how critical it was to optimize further with real collision solids . I guess I could add some logic to my loader method for the buildings to auto-create a collision box of the right size when loading the mesh.
Of course, that “little bit slower” is multiplied for each time you do this, so if you have a bunch of buildings, each of which is a box, it’s probably time to talk about using CollisionPolygons instead of GeomNodes.
It’s not hard to do it, so there’s really no excuse for using GeomNodes.
David
Yes, that makes sense.
Is the basic strategy to calc the bounds and build a collision (polygon?) when loading the building mesh?
What would I need to do so actors can’t walk through it (and can stand on it, etc)