Noticeable motion jerk when fps not at full speed about urho3d HOT 11 CLOSED

What operating system are you running on?

from urho3d.

I'm on windows 7

from urho3d.

Ok, then it's not the file watcher which has been known to cause framerate problems on OSX.

Your example scene has extreme fillrate consumption and consequently variance in framerate when one moves near all the shadowed pointlights in the center of the scene. A scene such as that can not be expected to run well.

Do you experience the same issue in more "balanced" scenes, like in the examples 07_BillBoards or 12_PhysicsStressTest? Also what happens if you turn on vsync (-v parameter)? If you turn on the profiler display (F2 key in the examples) are there any obvious constant or periodic time hotspots? And just to make it absolutely sure, are you running a release or relwithdebinfo build?

One possible cause is the lack of timestep smoothing. Basically Urho3D uses the elapsed time of previous frame to find out the timestep for the next frame, which leads to uneven motion when there are alternating "fast" and "slow" frames.

from urho3d.

Yes, it's not balanced, It was created just to reproduce the problem, which happens on my game scene (80 fps, 30k triangles, and camera is fixed to moving object, so the snap is even more visible)

I'm building on release.

The 07_BillBoards example runs fine, until frame rate drops down when I go near rotating smoke. Then I have about 45 fps and it is jerky again - about every second there is a snap (I see it looking at moving lights and rotating clouds). I believe that the snap always occurs, but it is more visible when frame rate is lower.
I tried various combinations with vsync and it doesn't have any influence.

I also tried to record the video with fraps but unfortunetaly when I record then it solves the issue :)
So I recorded a video by phone camera. Look closely at moving box and you will be able to see 3 or 4 snaps, one after the other every second(look very, very closely on the cube)
http://www.youtube.com/watch?v=KDKhv5cioOM

from urho3d.

Ok, I just printed timestep every update. here is the output:
https://docs.google.com/spreadsheet/ccc?key=0AuFH5cooowQpdHNlcFNwRTBYOWViNU1ndWgxR2pSZHc&usp=sharing
So, fps was about 86 so it happens every second as you see in this spreadsheet. Like you said, it was due to inconsistent timestep value. There is one longer update and than 3 very fast frames. What are possible fixes for that? Do you think that taking an average form last 10 time steps(or something like that) and sending it as next time step good enough?
And another question is why is that happening?

from urho3d.

Maybe you could use linear interpolation of the movement using a Lerp function:
http://en.wikipedia.org/wiki/Linear_interpolation

I have also found this Curve(newvalue,oldvalue,steps) to be quite useful to smooth irregular movement:

typedef double flt;
flt Curve(flt newvalue, flt oldvalue, flt increments)
{
    int sign;
    flt slip;
    sign=sgn(oldvalue-newvalue);
    slip=(oldvalue-newvalue)/increments;
    oldvalue-=slip;
    if(sign!=sgn(oldvalue-newvalue)) return(newvalue);
    return(oldvalue);
}

from urho3d.

Yes, flying close to the smoke billboards is a good way to reproduce the timestep issue.

There are two things interacting here:

• The lack of timestep smoothing
• The buffering of whole graphics frames by Direct3D. It has the ability to buffer all draw commands for up to 3 frames, which makes that frames "complete" very fast even though the GPU has not drawn everything, until the buffer becomes full and the Present() function will stall until drawing is complete.

I'll add at least configurable simple lowpass filter for the timestep. Basically, take some amount of the new timestep and some amount of the old.

I'll also see if a Direct3D query each frame to flush the GPU buffer should be re-introduced (that used to be in the Graphics subsystem.) It will also help to minimize input latency, but can decrease performance a little as the GPU will stay idle some part of the frame, so it can't be on by default.

Finally, I will check if there's a 1 second periodic task occurring in Urho3D, but there shouldn't be any. It could also be some background process on your system, which periodically consumes processing power.

from urho3d.

Thanks Lasse, it works great when I set timeStepSmoothing to 20. When it's 10 then the snap is barely visible. I had also problem with first frames when smoothing was enabled, the first frames were very fast and first half of second after running the program was like fast forward. So, I disabled smoothing until last timesteps vector is full and created pull request if you would like to accept my changes.

from urho3d.

I've merged the pull request, thanks! Still have to investigate whether it's worth it to bring back the GPU flush mechanism.

from urho3d.

Added back Graphics::SetFlushGPU() feature, which may help to smooth constant timestep jitter. As it potentially degrades performance, default off. Now I believe what can be done to fix this issue has been done.

from urho3d.

Nice work! With flushGPU enabled there is no snap visible. However, I will stay only with smoothing timestep, witch gives me about 1 ms performance boost per frame, compared to flushGPU solution. Thanks.

from urho3d.