Dependence velocity of objects at count of collisions! :(

maxwave

06-05-2006 17:46:12

When I load in scene many collisions, the behaviour of physics of objects is not natural. When I compile Debug, all Objects moving very slowly (gravity and other forces), but when I compile Release, all objects moving very very fastest! (FPS is normal) I set velocity in Debug and in Release, but it's very verious in both cases.Debug - very slow, Release-very fast. Why???

walaber

06-05-2006 18:24:42

how are you calling OgreNewt::World::update() ?

maxwave

06-05-2006 19:40:04

Where I should call this method and what parameter a should pass?

walaber

06-05-2006 22:46:02

you need to call it every frame (inside a frame listener if you have one, otherwise somewhere in your mail loop), and the simplest thing to do is pass the amount of time elapsed since the last update (frame) in seconds.

a better way is to determine a desired phyics update frequency (for example 100 times / second), and update in your loop as many times as necessary to maintain that frequency.

maxwave

07-05-2006 09:31:05

I make it in my frameStarted:
cPhys->update (evt.timeSinceLastFrame );
My function:
void cPhysics::update (Real sec)
{
m_World->update(sec);
}

and there are no changes. I shoot simply ball in scene, and on screen very many objects (FPS is ok). When I take up camera and count of objects is decreased (FPS increased), the ball velocity become fastest. What I should to do for call WORLD::UPDATE() right??

maxwave

07-05-2006 10:49:26

Hm, I don't understand. In my program I use OgreNewt::BasicFrameListener, which already use world::update() method. Why I should use world::update() in my frameListenet?

maxwave

07-05-2006 12:23:43

2walaber

I understand, the code of basicFrameListener is not correct. It is chuck of code:

else
{
if (m_elapsed < (m_update))
{
// not enough time has passed this loop, so ignore for now.
}
else
{
m_World->update( m_elapsed );
m_elapsed=0;//<------this line was not exist
count++;
}
}

After adding line m_elapsed=0; the bug hided. Please fix this bug in your sources.

walaber

07-05-2006 18:51:55

you are right. without that line, if the frame rate < physics update, it can get "eternally behind" and you end up with worse and worse framerates.

it has been fixed on CVS.