I’m having some problems with collisions. I have a level geometry which is made up of different models (terrain, trees, rocks, etc) modelled in blender.
If I export it as static geometry and i enable collisions with it i’m able to know which part of the geomtry is involved in the collision (whether it’s the terrain, a tree or a rock), but as geometry is not optimized for collisions it is extremely slow. So i tried to export the entire geometry enabling “Make Octree” and “Collision Octree” in Chiken export, and collisions are much faster, but i can’t understand which part of the geometry is involved. There’s a way to have fast collisions with control over geometry parts?
I think this is used in Roaming Ralph, but I don’t know how that geometry has been optimized.
AFAIK, having individual octrees for different objects in a Blender file is not supported by Chicken.
My tests show that when you perform a collision octree export in Chicken, it generates one single collisionnode hierarchy for your Blender geometric scene, organized as an octree. So, if you’re expecting your trees collision geometry to be accessed separately as individual pandanodes, then this is impossible as all individual Blender object information is discarded when partitioned into a singular octree data structure.
There are several ways to around this that I know of…
You can separate the collision geometry into multiple passes, exporting each as its own octreefied .egg. So, all of your trees would be exported in a single layer octreefied collisionnode.
Or you can use simpler individual representations of your different collision objects. In other words, all trees will be represented by simpler collision solids and so on. There’s no need to octree this, since they already exist as singular nodes that can be culled individually. You can then flag them individually in the Blender scene as trees, bridges, etc. in case you need specialized behavior for each.
The first method seems the least efficient method to me, as you’re forcing Panda to duplicate work that it would already be performing. (In the case of individualized collision solids in the second method being culled as part of a sparse scenegraph.) You really should only be octreefying objects that are very large continuous pieces of geometry.
Method two is the one I am experimenting with now; It’s pretty easy to build simplified collision versions of in-world objects and then set them as descended shapes. You want to descend them as otherwise Panda will try to cram them all into collision node in an optimization pass. You can also use polysets in case simple representations don’t cut it, but with obvious hit to performance.
IIRC, Ralph uses polyset keep, so the geometry is used for both the visual and collision detection phases. I really wouldn’t do this for a game of any decent complexity. You want to keep the number of triangles sent through your collision system to the minimum.
Hi! Thanks for your explanatory reply. The second method is probably the best one indeed. An octree should be used only for large terrain and I would wrap the other objects with planes and spheres collision solids.