[SOLVED] Jittery renders when render FPS is higher than phys

Gah, not enough space to explain it properly, but basically,

We want our game to render at the highest FPS possible, and we want the physics to remain stable and keep it untied from the FPS. In the past I had assumed that in any physics engine, a fixed timestep is a must. However, I note that in OgreNewt people have used varying timestep.

We are using the same code to update the physics as is used in Stunt Playground. (Sweet little game there by the way!)

the problem is that the objects jitter around like crazy! The camera is following its target flawlessly, but the physics objects are twitching forward and backwards and I don't really know how to explain the problem, but we have a video.

http://www.flow3d.org/AD/mazemonk.htm

If you watch you can see the robot is twitching because the background is shaking. (the camera is not physics enabled so follows its target fine with no twitching.)

How do you avoid this twitching of objects?

Let me know if you need any other information. I am at a loss as to what the cause could be so I dont know what to provide you with!

Thanks,

[edit]

http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=6522

Looks like this guy has something quite similar? (sorry, Did not notice the thread!) we cannot simply callupdate(60) however, this alone ties it to the render FPS which is what we are trying to avoid, does it not?

in your example would it not be possible to update every frame with m_World->update(currentfps); as long as its never lower than 60 it should work fine.

Well, we need to accomodate for the fact the app will not run at 60fps on everyone's computer, so we need it to keep up to speed even if rendering starts to lag. Thats why we need to keep the physics running at a constant speed and not have it coupled to the actual rendering FPS.

Has nobody else been having this issue? Locking the logic updates to the FPS is not an option here. (Unless it *has* to be done that way.)

no i meant in your frame update pass it the CURRENT fps and it should update based on that

AH, right, so you are saying World->update(CurrentFPS) not specifically (60)?

Hmm, Well, that will mess with gravity. IE percieved gravity at -9.8 will not be near realism.

Still, if this has gotten you smooth results then we can probably fudge the figure to get it to look right. I will give it a go. Thanks

unfortunately i cant see a better way (apart from the matrix blending method i mentioned in the other thread)

I guess one could just divide the FPS figure by 4.615 and use that. But then it would be using the same end figures as it does not.


No ide if it will work, but i sure wish I was at home now to find out lol.

Further thinking: Just passing the FPS to the function will not work simply because at 80fps it will do a larger physics jump than at 60fps. and we are basically already doing 1000/fps, and updating the physics as many times as necessary, just as Walaber does it.

personally I dont see the need to render faster than vsync but even that can change, and we need to be able to support it running smooth

No idea what Stunt Playground does, but have you tried an accumulator?


float physFreq = 1.0 / 60; // 60 FPS for the physics (btw, that's _seconds_)

void updatePhys(float deltaTime) {
static float accumulator = 0;
accumulator += deltaTime;
while(accumulator >= physFreq) {
updatePhysicsWorld(physFreq);
accumulator -= physFreq;
}
}

Crude example, but since I just wrote it, I didn't want to take too long . This can further be optimized by interpolating the physics state, but I haven't done that yet, so don't ask me for any implementation details .

That looks pretty accurate and close to the code that ourselves and Stunt Playground uses. Thanks though!

I have found the problem.

If you have a non-physics based object that moves freely, then if a physics doesnt update for two frames and then does, there is a transition. Now if your non-physics object is say, a camera, then when the physis suddenly updates the camera twitches to its new target.

I have updated my code and the problem is resolved.

Basically: improperly implemented Delta.

I have found the problem.

If you have a non-physics based object that moves freely, then if a physics doesnt update for two frames and then does, there is a transition. Now if your non-physics object is say, a camera, then when the physis suddenly updates the camera twitches to its new target.

I have updated my code and the problem is resolved.

Basically: improperly implemented Delta.
Makes sense, since I never experienced jittering even without the interpolating talked about with the accumulator approach. Basically, your physics objects updated at a different frame rate than your non physics objects, so one 1 was 1 step ahead, the other was 2 steps ahead (in example). And the reason that this worked so badly was since your camera followed the non-physics object (otherwise it wouldn't really be "visible").