ok, so for our upcoming multiplayer fps we're choosing to use physics for alot of elements, now, ode is stable in alot of cases but the following error is really unaceptable, now we've done everything in terms of tweaking physics variables and hull properties so am thinking now it as alot more to do with the core engine and am wondering if theres any minor tweaks you guys can do to it to help the situation.

the errors are visible in this video at 0:25 and 0:52 seconds:
[video:youtube]http://www.youtube.com/watch?v=I6ks5utejU0[/video]

now, the obvious work around is to recode the grenade using c_move but this really removes alot of functionality from what we have planned and would be a 'last resort' so i dont know if theres anything you guys can/willing to do

have you tried making an invisible shell to move it in that has better collsion detection, but would look similar in its bouncing nature. I realize thats less than ideal but it might be worth looking into.

How high was the FPS when recoring that? Could be
related to the inaccuracy in low framecounts.

Also try to use a bigger and simpler shape for the grenade hull.
This might help.

ok thanks guys, i have a solid understanding of the error now, would also like to apologize for making the thread so early before fully investigating the problem, atleast it once again proves that alot of errors can be solved by users rather than blaming the engine, experience:

-as stated in the manual, larger models work best, so i used 2 vertices to increase the size of the grenade hull
-i dont think using a less complex model would help, since its only using a box/circle for the hull despite the models shape
-ph_fps_max_lock is our friend and so is ph_check_distance

maybe i'll take the video down, not sure atm since i didnt wanna show any part of the game dev as yet, also, since am already here i'll ask a question i've had for a while:

i know that the following can be used to manipulate joints and such but there really isnt enough information as to what parameters do what, am referring to:

phcon_setparams1(constraint1, my.x, nullvector, nullvector);
phcon_setparams2(constraint1, my.x, nullvector, nullvector);

i hear they can be used for joint softness/hardness and such but dont have alot of information on it, i take it parameters 4 and 6 arent available for hinge joints?

and can i tried using phent_setmotor for HINGE joints and saw no movement at all.. so some info would be nice

-

I am not sure what you mean with box/circle hull - use either a box hull, or a sphere hull. The size also does matter. Experiment with it. You have to live with the ODE physics as we aren't going to fix or improve ODE, so you must tweak the parameters when you get physics problems. Alternatively, you can use the PhysX plugin by Chris3D. It uses the same functions as the native physics, so the conversion should be pretty simple.

I think it would help to seperate the physics framerate from the renderer.
The problem is that for some cases physics need to be updated very often, but it is not possbile to keep the same frame rate for rendering.

physics frame rate already is separated from the renderer.
it is well known though that ODE has weaknesses/bugs in collision detection.

So how can I set the rate for ODE in A7?
I had the very same problems with Newton, by using a rate of 200 FPS it now works perfectly fine.

with other physics engines you can either turn on continuous collision detection or use higher frame rates. ODE doesn't really support continuous collision detection.

ph_fps_max_lock

Ah, now I finally understand what this variable is supposed to do. Thanks
Too late though, I've switched to Newton now and I'm quite happy with it. But event there I have to use a framerate of 200 for the physics engine, as contiinuous collision mode was not capable of fixing the problem. (Very fast rotating hinge colliding with fast moving object)