Hi guys!
I’ve started using this game engine and am really glad about it. But now I have some problem with collisions. I put CollisionHandlerFloor and CollisionHandlerPusher’s in Roaming ralph and it was great… but when I put 10 pandas, each of it with pusher /collision sphere/ the fps went to 7,8 which is too slow.So I am thinking is it really not recommended to put too many ‘fromObjects’ in the scene.
I need control of NPC’s such as walking on an uneven terrain, but the only idea was to make them with collisions - via CollisionHandlerFloor. But now I’m not sure this is the correct way.
I’ve seen most of you are making your own games and probably are already encountered such problems. So please say some idea about pass over this issue.
Thanks alot
this is less a problem of collision handler floor. than your collision mesh.
can you describe your meshes, what you use for collision.
i assume you use visible geometry as into object. and spheres or simmilar as from.
if so. visible geometry is by its very nature VERY unsuited for collision and treeforms egg-octree script might help you a lot.
also take a look at pstats. it allows you to find and fix bottlenecks more easily.
I didn’t think about the environment. I really made my models with Spheres, but didn’t add CollisionSolids to the terrain. So I suppose it took by default its visible geometry. (Obviously that’s way when I used my own model for world the game just blocked and couldn’t render anything)
I’ll see the measurement tools, it was my mistake I didn’t used them before for such info 
.
Thanks for directions
well using collisionSperes for your from objects is perfectly fine. spheres are robust and fast. (using classical “solids” for the terrain such as spheres or tubes wont work anyway so the geometry is fine, its more about the internal structure)
your problem is the terrain. visible geometry is (or should be) optimized for the rendering process. which requires them to be a few, big chunks of data.
unfortunately, testing collisions requres the exact opposite to be most efficient. means well-structured geometry which ends in thousands or even more tiny chunks of data.
collision tests work against each and every triangle in your geometry.
assuming you have a terrain with 20000 triangles(visible geometry). this requires 20000 calculations test and maybe 5 to 10 actual collision-calculations for triangles in question.
this makes abit more than 20k calculations for a single from object. with 6 from objects you already have 120k.
if you split the mesh into an octree structure (using the egg octree script) panda can sort out most of the data with just a few steps of calculation.
imagine a single test sorts out 75% of the data remaining. means after ~5 tests you already have only about 20 triangles left which have the potential to collide with your sphere. then you only need 20 more tests to do the actual collision tests. means instead of 20000 tests. you run only 25. for 6 spheres this would be the difference between 120.000 and 125 tests.
of course thats a very simplified example. but thats basically how it works. this difference is quite significant for huge meshes with tons and tons of triangles, such as terrian.
usualy you solve that problem by having the visible geometry you display. and a invisible copy with octree structure.
if you use geomipterrain you can directly get the elevation using a method provided by geomipterrian itself. this is even faster since there are no intersection tests involved. fast enough to have quite a nice number of objects moving around.