From reading the “manual” It seems that triangle mesh collision ( “collision with geometry” ) detection is quite expensive on the CPU. Is that true of Panda3D? Do I really need to spend the time to create special nodes around each object I want the player to colide with?
I’m very new to 3D programming and python. So please pardon my ignorance.
I have somewhat of a programming background, and it seems like it is a waste of time to create a “world” with double objects. One for visuals and the other for collision detection. Is this how everyone does it? Is there no way to automate this? I just want to make sure I am reading correctly.
Most of my experinece is in shell and c++ programming. eheheheh… I’m way our of my field, ain’t I?
I have seen other engines make it much simpler. I don’t mean to compare engines. I’m not saying one is better than the other. However, I do need to point out an example so what I am saying can be understood.
Example: Irrlicht
To get collision detection with a “map” object and the “player” it is very simple. It’s a matter of about 20 lines of code. If you like you can throw in a real physics engine like ODE. This is also quite trivial. You don’t have to “create special collision geometry, such as spheres and polygons, to determine collisions.” It’s fast too. See for yourself: http://irrlicht.sourceforge.net/tut007.html
So ultimately my question is: Is “create special collision geometry, such as spheres and polygons, to determine collisions” the norm in 3D engines these days? Should I expect that from any engine and just stick to Panda3D because I would need to do that with any engine?
Also, can I get some docs on the “collision with geometry” method mentioned in the “manual”?
Looking at the Physics example I see that those special collision geometry nodes can be inculded in the egg file(s). I looked at the egg files source. How do I know where to insert these tags? Is there an egg editor to help with this? The sceneEditor? Or do I need to hack the egg syntax directly?
I’m sorry if I came across a bit perturbed. It’s a bit overwhelming the amount of programming involved in collision dection with Panda3D and 3D in general.
Thanks for the advice and suggestions! Sorry for the long post.
The fundamental problem is that you need many more (many thousands more) polygons to create a model for viewing than you do for collisions.
Since the cost for collision detection against polygons is roughly linear with the number of polygons, you would much rather test for collisions against 100 polygons than against 10,000. This is true for any collision engine. However, you don’t want to look at a model that was made with 100 polygons.
This is the main reason why Panda recommends you create special collision geometry for this purpose. That being said, collision detection against polygons is reasonably fast, especially if you pay particular attention to modeling your scene with a good hierarchy that reflects the spatial distribution of your polygons (so that bounding volume tests can efficiently early-out large groups of polygons). But as fast as it can be against 10,000 polygons, it will be 100 times faster against 100 polygons, and it will be 10,000 times faster against a single sphere.
Short answer? Use collision tests against visible geometry first. Maybe it will be fast enough, and it will save you some modeling effort. But when you want to squeeze out every last drop of CPU energy, it will be a big win to create special collision geometry.
To create collision geometry in an egg file, you need support from your modeling package of choice. For instance, if you are modeling in Maya, you can use the melscript provided with Panda to tag nodes that are intended to represent collision geometry. Then maya2egg will recognize those tags and write the appropriate collision flags to the egg file.
I don’t know about other modeling packages. You might need to write the appropriate plugin for these yourself (or hand-edit the egg files if necessary).
I see. I understand the reasons now. This is what I feared in a way. I guess it’s real pick and shovel work. There’s not many short cuts here. Perhaps one method that will help me though is collision detection with bounding box. Is this possible? I’m thinking about this mainly for objects that the “player” can “collect”. For example: catch the falling money or similar. The exact geometry is not important because it will be discarded. Is that a good idea? I guess I could also write something that dynamically creates the “Collision Solids” from the size of the object itself and then use that for collision detection. Sounds like a plan. For most simple objects it should be fine no?
David, thanks for taking your time to answer even my ignorant questions. It’s much appreciated.
This will make a collision sphere that is guaranteed to contain the geometry, although depending on the model it may or may not be a very tight fit (it might be larger than it needs to be). To make a tighter bounds, you can use model.getTightBounds(), which returns the upper and lower corners of the object’s bounding box, and calculate the sphere’s center and radius yourself (or construct a box of six polygons), or you can hand-edit your egg file to put:
<ObjectType> { bubble }
within the outermost entry–this means to automatically put a “bubble” around the model represented by the group.
Ah yes. I remember reading about getBounds() and getTightBounds(). I couldn’t remember where.
I just want to confirm the egg idea.
All I need to do is put:
<ObjectType> { bubble }
in the outmost group entry of the certain object I want “wraped”.
I need to replace “bubble” with real 3D data, no? My colleagues all use Lightwave. So the Maya is not an option. Though editing the egg file is fine. - Shall I have them make a separate “bubble”, convert that to an egg file and put the “bubble” coords in place of “bubble”?
If the bubble is computed automaticaly, a plain sphere?
Also, I would still need to get the bubble node and assign that to be used as collision data. Correct? It looks to me that egg files can contain scenegraph hiearchy. If I make the real object beneath the bubble object in the scenegraph, the parenting would be set when I load the file. Correct?
If there is any docs on the egg format, I would be happy to study them. I am the only programmer working on this project. So as you can imagine, I want to keep my code minimal and reusable and let the artist work in the egg files and other external data as much as possible.
The { bubble } syntax is literal; you do not need to put coords in. It tells the egg loader to look at all of the vertices within the current group, and compute a CollisionSphere around them. That’s all you need to do; it will be used as collision data by default.
The syntax is actually replaced with more advanced egg syntax that can be specified in the Config.prc file. Specifically, object type “bubble” is replaced with " { Sphere keep descend }" which means to create a collision sphere, keep all of the existing geometry as visible geometry, and descend through nested groups to find all geometry.
The full egg syntax document can be found in panda/src/doc/eggSyntax.txt, which you can view in the SourceForge CVS repository.
I am new to Panda and first of all just wants to see collision detection in action. Is there any way to just use visible geometry for collision detection. In particular: How do you create a CollisionPolygon from one of the models already loaded in the scene? Is this possible or do you need a special egg file with collision geometry defined? I guess for “into” objects you dont need special collision geometry as you can test against all geometry as “into” objects. But for “from” objects you need some collision solid to add to a traverser…
Right, for “from” objects you need a CollisionSolid. Actually, you really need a CollisionSphere; most of the other kinds of CollisionSolids can’t be used as “from” objects anyway. So just create a CollisionSphere explicitly.
Yes, it is a little limiting. But it may or may not be too limiting, depending on your application. Many applications do just fine with spheres. If yours does not, you’ll need to look at using a different collision engine than the one supplied with Panda.
