Slow Collision Detection...?

jack_1313 · Post by **jack_1313** » Tue Jan 20, 2004 9:05 am

I have been deeply considering Irrlicht for a future project. However, after running some simple testing, I have come to the conclusion that collision detection used by the engine is extremely slow. For instance, if I open the ‘Collision’ example and replace the code used to create the three faeries with

Code: Select all

	if (faerie)
	{
		for(int i=0;i<30;i++)
		{
		node = smgr->addAnimatedMeshSceneNode(faerie);
		node->setPosition(core::vector3df(-150+rand()%300,0,-90));
		node->setMD2Animation(scene::EMAT_RUN);
		node->getMaterial(0) = material;

		anim = smgr->createCollisionResponseAnimator(
		selector, node, core::vector3df(30,50,30),
		core::vector3df(0,-100,0), 100.0f, 
		core::vector3df(0,50,0));
		node->addAnimator(anim);
		anim->drop();
		}
	}

the famerate drops from 70 fps (70 is my default refresh rate) to a mere 40 fps. The collision detection is causing the drop – I have tested with and without active collision detection. Furthermore, if I add another 18 faeries complete with collision response animators the frame rate levels at 27 fps. Obviously, this is unacceptable (I am running an Athlon 2200+). 48 was the maximum number of characters I would ever be dealing with, but that does not take into account such things as projectiles, and more importantly, line of sight (the “getCollisionPoint” function used to check a line with the world is also very costly. If I were to use, say, 20 bots in a multiplayer death match game, 10 per side, then this would require 10*10 (100) line of sight calculations – using getCollisionPoint my framerate drops to around 15 fps. And this doesn’t include line-of-sight tied in with A* path finding to generate ‘flanking’ paths.).
Is there a reason for this slow collision detection? Are there any plans to improve it? Have others faced this problem?
Now, I know that the Quake 3 engine is an expensive, professional piece of middleware, but those of you who have played Call of Duty might notice that at some points during play hundreds of characters exist in a level at one time. How does one deal with situations such as this?

niko · Post by **niko** » Tue Jan 20, 2004 9:43 am

Hm, I never tried a stress test with the collision detection system, so I didn't know that it is this slow. I'll check it, and will try to optimize it a little bit.

[dx/x]=HUNT3R · Post by **[dx/x]=HUNT3R** » Tue Jan 20, 2004 2:54 pm

Yeah I noticed the same thing. If I put say 20 or more planets in space and add collision detection for all of them then things start slowing down. And if the col det for each planet is by the mesh then things Really slow down, it's a little faster to just use bounding boxes, but not much. Thats why in Supa G I'm currently only using 9 planets so it'll run smooth with col det for all 9 planets and any enemies in the game.

keless · Post by **keless** » Tue Jan 20, 2004 2:59 pm

from what I understand the engine's own collision detection is not a good replacement for ODE

if you're really interested in CD, use ODE/Tokamek

saigumi · Post by **saigumi** » Tue Jan 20, 2004 3:19 pm

Hunter, since planets are just spheres, woulding it be faster for you to just generate a list of interactible objects instead of using the collision animator and say:

if (object.DistanceTo(Planet) < PlaneT.Radius) then HIT

Or are you doing gravity and such also?

[dx/x]=HUNT3R · Post by **[dx/x]=HUNT3R** » Tue Jan 20, 2004 3:52 pm

No, no gravity. And that's probably a good solution that I haven't tried and I could use Tokamak or something else too, but I've just been trying to stick with using Irrlicht's features for this project. It's not a big deal to me really b/c I plan to finish the project off soon and move to something else.

powerpop · Post by **powerpop** » Tue Jan 20, 2004 6:59 pm

i imagine that the collision detection is doing the testing in between every frame of rendering (??) - it might be better to tie the collision testing to a timer so that it always runs at a certain speed regardless of frame rate - and it would be nice if this were user settable!

it also might be good to make sure that collision testing only takes up x milliseconds in between each frame and then picks up where it left off during the next interval

other optimizations might be more pretesting of regions so that some collision are never tested because the bounding boxes are too far apart

just a couple ideas!

tstuefe · Post by **tstuefe** » Wed Jan 21, 2004 6:08 am

yes, spreading the workload for collision detection over multiple frames is definitly a good idea... There are several approaches to that. Multithreading (with microthreads, real treads are far too expensive), or dividing your workload into small chunks and using some taskhandler model for that. The latter model can get as sophisticated as you want, with prioritized taskqueues and whatnot..

jack_1313 · Post by **jack_1313** » Wed Jan 21, 2004 6:47 am

It is the whole Line Of Sight concept that is worrying me. For instance, I plan on a max of 24 bots on each of two sides (48 total). Each bot will need to calculate LOS with each bot on the opposing side - huge amounds of collision detection there. Then, even more worrying - I need to tie A* in with LOS in order to generate flanking paths (nodes in the LOS of a known enemy position have higher costs), which could mean hundreds of line/world collision tests at any one point in time.
How well does ODE/Tokamek function with Irrlicht? Could either provide this sort of functionality at an acceptable framerate?

jack_1313 · Post by **jack_1313** » Sun Jan 25, 2004 9:43 am

How did those tests go, if you don't mind my asking?