[SOLVED] Is OgreNewt (or Newton) framerate-dependent?

Hi, I got another question bugging me...

This one is related to the 'framerate' parameter of BasicFrameListener's constructor. If I got it right, this parameter states how many times Newton system will be updated per second. The standard value is 60, meaning it will be updated 60 times per second. Sounds fine, but if I change it for, let's say, 30 times per second, the whole physics system visibly slows down!

I'm quite confused about this behavior... If my object is intended to move 10 meters in a second as a result of forces applied on it, shouldn't it move 10 meters, independently of the physics system's frame rate? With 60 updates per second it should translate approx. 0.17 meters per frame, and with 30 updates per second it should translate about 0.33 meter per frame, right?

Well, the behavior I'm getting here (speed slowing with lower framerates) sounds quite weird to me... Is it really intended?

Any answer would be really appreciated...

Thanks in advance!
Edgard

I was wondering this myself. Didn't notice it until I moved from 1.32 vehicle (180 fps) to 1.5 (60 fps) and I barely moved

I also notice that at low physics fps that the graphical parts update at that rate. So even if I'm getting 100fps, if my physics are 30fps then they the graphics update at 30fps. Which I guess does make sense and would be hard to overcome depending on how newton is implemented.
I always imagined each physics frame calculation would do all the physics/collision and set a vector to increment each visible mesh based on the real framerate. So even though the physics isn't calculating the visible mesh is still moving. That's just off the top of my head and is probably the job of the application programmer, not the physics gimp

Rigid bodies in Newton defualt to a linear damping value of 0.1. This means that every time you call update() on the world, free-moving bodies will have their velocity decreased by 10%. the problem is that this damping is directly dependant on the frame rate. so if you are running at 100 fps, you have more updates per second, so the body will slow down faster than if you only update at 60 frames per second.

This damping is necessary to maintain a stable simulation, because of floating point errors in computers. however, the author of Newton has agreed that 0.1 is bigger than neccesary, and so you can now set the damping to lower values manually, but the default value has been kept the same to maintain code compatibility.

if you want less frame-rate dependant behavior, use setLinearDamping( 0.001f ) and setAngularDamping( Ogre::Vector3(0.001f, 0.001f, 0.001f) ).

but this damping is unaviodable, which is why updating with a different timestep does not result in deterministic behaviour.

if you want the exact same results every time, you must update with the same timestep.... this is just a fact of life, due to floating point errors.

*Edited for clarity*
Is there any way to make Newton run at a framerate-independent timestep?

We're looking to do arrows and other physically simulated server-client physics, and run the rest (ragdolls, other non-essentials), on each player's client. From what I've been researching, it seems that decoupling the framerate/renderer with the physics timesteps is best? Any insight on the issue Walaber?

couldn't the amount of damping be scaled by the evt.timeBetweenFrame time? Or like that article 'fix your timestep' http://www.gaffer.org/articles/Timestep.html

This is interesting,
I am also thinking of having a server handle the main physics & player movement & the client only handle the rag dolls & other non-essentials btw.

Limiting the server FPS/Ticrate should be ok for server calculation stability & im not to concerned if the clients rag dolls fall a bit faster/slower due to there FPS.
Any easy way to limit the clients fps like setting a MaxFPS btw?

Rigid bodies in Newton defualt to a linear damping value of 0.1. This means that every time you call update() on the world, free-moving bodies will have their velocity decreased by 10%. the problem is that this damping is directly dependant on the frame rate. so if you are running at 100 fps, you have more updates per second, so the body will slow down faster than if you only update at 60 frames per second.

Actually, my problem is quite the opposite... When I run the system at 60fps, everything seems to be ok. But, when I change it for, say, 10fps, the system is updated in slow motion!

The problem I'm facing is more visible on free-falling objects. I modified the linear and angular damping values to 0.001f and indeed, when my objects collide with the ground, the simulation runs more realistically than before. But the simulation as a whole continues veeeeery slow when I test it with 10fps...

I'm really confused about it. Studying the source code, I found this line of code inside BasicFrameListener's constructor:

m_update = (Ogre::Real)(1.0f / (Ogre::Real)desired_framerate);

If I've understood it right, m_update increases when desired_framerate decreases - which, to me, seems to be the correct behavior. At 60fps, m_update will be approx. 0.017 second and, at 10fps, it will jump to 0.1 second. If that's right, what could be wrong?

Any ideas on it?

Thanks in advance,
Edgard

the only way to get deterministic ( = same results every time) is to use a specific timestep EVERY loop.

my OgreNewt::BasicFrameListener() class does this. if you pass it a value of 60 for the update, the physics will update 60 times per second, no matter what the visual framerate is.

this is pretty easy to do. just make a timer, and subtract the elapsed from the last frame, and (possibly) update once or more than once per loop.

this is especially important for networked games I think, to get accurate prediction on each side.


as for things moving slowly at 10fps, that is because internally Newton limits the value you can pass for OgreNewt::World::update() to values between 1/60 and 1/600 (aka 60-600fps). so if you pass it 1/10, internally it is adjusted to 1/60. this means that the pyhsics are updating as if only 1/60th of a second has passed, when actually 1/10th of a second has passed.

so if your game it running at 10fps, you will need to update the physics 6 times per loop (1\60 * 6) to get "realtime" 10fps behavior.

Ok, guess I got it, now.

Many thanks for your support, walaber!

my OgreNewt::BasicFrameListener() class does this. if you pass it a value of 60 for the update, the physics will update 60 times per second, no matter what the visual framerate is.

I'm using a slightly modified version of your code. In fact, it's just the same but I added a couple of calls before and after the updates:

bool PhysiscsFrameListener::frameStarted(const Ogre::FrameEvent &evt)
{
m_elapsed += evt.timeSinceLastFrame;

if ((m_elapsed > m_update) && (m_elapsed < (1.0f)) )
{
Level::getSingleton()._beforePhysicsUpdate();

while (m_elapsed > m_update)
{
g_world->update( m_update );
m_elapsed -= m_update;
}

Level::getSingleton()._afterPhysicsUpdate();
}
else
{
if (m_elapsed < (m_update))
{
// not enough time has passed this loop, so ignore for now.
}
else
{
Level::getSingleton()._beforePhysicsUpdate();

g_world->update( m_elapsed );
m_elapsed = 0.0f; // reset the elapsed time so we don't become "eternally behind".

Level::getSingleton()._afterPhysicsUpdate();
}
}

return true;
}

However, I still get slower movement with smaller time steps. Why?