hi
has anyone implemented ODEJava physics and collisions in a game? I tried to add my ODE code to the Quake3 Level loader example from xith.org. I replaced the xith collsion system with ode and my P4 3000 was working really hard on it but just got 3 fps.
Is there another solution on it or can someone show me optiimized ode code? Or should I be stick with xith collsys? Or is there another common way to implement collisionsystems in games?
Qudus
I have, it works fine. 25fps, and this is unoptimised with no LOD yet. The actual odejava code takes about 1ms to execute from memory.
How have you modelled your ODE geoms?
Will.
The Quake3-loader builds xith-shapes. I extract the geometry from them and build ODE GeomTriMeshs from it’s vertices. Those are added to ODE.
Using the example level supplied with Quake3-loader this results in 3704 Ode GeomTriMeshs. Is this too much for ODE ? Or do i have to tune my
code somewhere ?
Qudus
This are pretty much, but ODE actually should be able to handle them, or how big are you’re GeomTriMesh?. - You haven’t encapsulated them in Bodies have you?
I don’t know if my solution works (or if it is even possible to implement), but you could try to check collisions only with the Geoms that are close to your bodies.
Most of the GeomTriMeshs are actually very small, around 5 vertices. I didn’t encapsulate them in bodies, since i need them only as static geoms. The Quake-Level-loader example uses the Switch-class of xith to activate / deactivate visible / invisible ColliderNodes in the collision system delivered with xith. At the moment i am trying to apply the same mechanism to my ode-nodes, by enabling only the visible ones. Perhaps your idea of enabling only the nodes in a certain radius around my “avatar” is more efficient, but this would mean that the player could see things moving differently depending on his distance to them. If the radius is set higher than the visible range, the Switch-system should get the faster one i suppose.
If you’ve already got a switch system this is ofcourse better - and it has actually the same idea behind than my idea 
It is not yet working and it needs at least the enhancement to assure that the level parts immediately under/above the player are
working with enabled physics, regardless of their visibiliy. At the moment i’m falling …
But my first problem of performance is still one. Could some tell me how many ODE objects he is working with ? Or is my try
doomed, to get a working xith-quake-engine with ODE physics ?
Thanks in advance,
qudus
Cannot you just merge the tiny trimeshes in one big trimesh ?
In my experience it’s a lot faster.
(I had a trimesh splitting function, and when having 300 trimesh, it’s REALLY slow…)
Thanks for the tip, i will try that. I thought it would be the other way around, that it’s easier to process lots of different objects, than one big one. I thought, if there is only one big mesh, the collision system has to test every vertice and can’t easily cast out objects, whose ( e.g. ) bounding boxes are out of reach.
Yeah I would think that way, too. But ODEJava always tests all Geoms - but when you make a good algorithm to only test Geoms in reach you might get faster with your method
You’re right.
I think it’s probably a compromise of the two. Small enough so ODE can optimise, but large enough so that there arn’t heaps of extra objects in the space that ODE has to worry about.
Don’t forget when you do this, that Quake3 is a specialised engine which just does quake, where as Xith3D and Odejava are general solutions – so I don’t know if you will be able to match Quake3’s performance. I would think you could get satisfactory speeds however.
Will.
Q3 uses a BSP wich makes it perfect for collision detection. It allows you to trace a ray, sphere or box with very little overhead by traversing only part of the tree. If you wan’t optimal performance it is best to roll your own collision detection. There are tutorials that shows you how to do it.
But I bet ODE is easier to use and is a more general solution.