Frame Tweening/Delta timing in physics wrappers
Blitz3D Forums/Blitz3D Userlibs/Frame Tweening/Delta timing in physics wrappers
| ||
| I thought I'd run this as a seperate topic as the officail JV-ODE is filling up, plus this is something worth keeping seperate I think. Following from Wayne's timer based updates of the breakable ragdoll demo, I've been thinking about keeping smooth animations. That demo updated at the same rate but had jitters as things weren't sync'd nicely to the screen refresh. Standard Blitz has options for delta timing or tweening, but ODE and other engines AFAIK don't. To get smooth frame rates using JV-ODE and other wrappers we need some alternative. A bit of experimenting has me precalculate a QuickStep (physics step) amount based on the monitor refresh, calculate from an average of multiple VWait durations. This particular code in easy-to-read format is ; Multiple refresh sampling to get monitor framerate For n=0 To 10 VWait T=MilliSecs() VWait T=MilliSecs()-T Total_Time=Total_Time+T num_samples=num_samples+1 Next ; Calculate Refresh Rate, determine step size Refresh_rate#=Float(Total_Time)/num_samples Sixty_hertz#=16.6666667 Step_Size#=0.07 Step_Size=step_size*(Refresh_rate/Sixty_hertz) In the case of ODE call dQuickStep(world,Step_Size) . Alternative physics engines can do the same. The inital step size (0.07) is that for a 60 Hz standard. A full demo applied to Wayne's Ragdoll-Abuse engine is... This works very well on my system where I can test at 60 Hz and 72 Hz. I'm not sure that this is a total solution for integrating physics engines and Blitz3D though. It can't accomodate dropped frames on slower computers as delta timing can, and only really works when the physics can be calculated within a frame period. Can people comment on where they see potential problems keeping a smooth fraerate with physics engines and what their solutions can be? I think people expect PC games to be jittery but I hate that and want to find ways to avoid it! |
| ||
| Hi Shifty, I'll check out what you did and see what can be learned. I took the code from my last example and removed the fps lock to let it run wide open, also allowed the mouse to do the same. Tell me if you think it's smooth. |
| ||
| I demo'd your changes shifty and was surprised how well everything ran. I measured the physics time, render time, frame time and all ran well at 85hz refresh. The demo ran very smooth and compares well to the last example I posted. The changes you made were clean and simple. The calculation of the step size was interesting. Which method is better? I really don't know but your examples give me yet another tool to consider in the render loop. I'm a huge follower of timers, and delta time and will give all this more thought as we proceed. Thanks, and nice job! |
| ||
| Both of the demos run smooth here at 85fps, there's a slight jitter every ~1sec. It's very subtle though, not really noticable with the ragdoll demo. It might be better to use a demo where the whole render area is updated, like the car demo? May be easier to spot timing jitters then. Anyway, just a suggestion ;) Shifty, here's some data for you from your demo: Total Time:134 Num Samples:11 Refresh Rate:12.1818 Step Size:0.0511636 |
| ||
| Well, this is frustrating. In my editor I run the same scene at 60 and 72 Hz, and it runs at the same speed. There's a chain of interactions causing some dominoes to land on a sphere and stop it in it's tracks. But in my main program, using the same library and same frame advancement function, the results for running at different framerates is different. Very frustrating. :( |
| ||
| I'm assuming you're referring to the Frame Tweening method above, it's extremely difficult to get pin point simulation accuracy when changing the step size each frame. The only way to get a consistant simulation is by using a fixed step size, regardless of which timing method you use. You could try locking the step size and use some method of activating/de-activating the whole quickstep process depending on how much frame time is available. |
| ||
| False alarm! Yes, I do lock the step size for the whole simulation. There's a pre-program check on monitor refresh to determine step size. My actualy problem was that the vertical slider I was using to set the Sphere's Weight was setting a float mount that I wasn't displaying. So when the control showed a weight of 8, it's actual weight varied from 8.0 to 8.5. When I text outputted the real float value, and set it to 8.7, the value in the editor, everything was hunky dorey :) <--- Big grin! |
| ||
| Hehe, nice one :) Have you had a chance to look at the new joint feedback stuff yet? |
| ||
| Nope. And I'm not going to either! The current JV-ODE wrapper is working fine, I'm near the end of my current project, and though I don't think I'll make this Friday's deadline now, the end of next week should see the project done. I'm capping features and development and finalising the software. After that, I've an idea on my next project which'll use ODE (everything'll use ODE! I can't get enough of dem fyziks!) but I doubt I'll have need for joints in it. So unless I get curious and give them a nose, joint interaction isn't on my radar. |
| ||
| Look forward to checking it out :) Can you give any details about it or are you waiting until the big launch day? |
| ||
| I'm waiting until it's out there. It's not going to be very interesting for most here I imagine as it's a niche product, but I think I've managed to pull it off as well as possible. I'm pleased with what I've been able to do. I just hope all this effort pays off! |
| ||
| Can someone give me a hand in understanding this method of locking fps with ode. I am new to ode and find that confusing enough. But when I try and run the sample at the top, it just doesnt seem to tween at all... Is there some configuring needed? Or am i just not understanding how it works? Thanks in advance, Ian |
| ||
| You need to lock the physics timing to a constant frame rate (30-60 fps), regardless of the logic/graphics timing. The example above doesn't lock the physics timing. There's some useful ODE timing info discussed in more detail here... JV-ODE Physics Thread 6 ;) |
| ||
| This is the system I finally developed : Fetch the time elapsed between frames. Accumlate this time. If the time is over 20 ms (50 Hz), perform physics and capture the scene. Reset the frame timer. For each frame, calculate a tween value. Render with Tween. Here's the code : Here's an example of doctoring the JV-ODE Box Demo : The 50 Hz is hard coded as the value 20 in the above. You could use a CONST and set that to something else. 50 Hz was used as it divides nicely into the limited 1000 ms resolution of the timer. 60 Hz doesn't, and I think it'll give rounding errors. Using a period less than 1/60th of a frame will have no effect if you lock to the vertical refresh. If you lose the vertical lock (Flip False) you could get a higher framerate than the screen update, but at a cost of introducing tearing. This method has been tested to provide the same physics update rate at 60 Hz and 72 Hz, including custom forces (just apply all forces in the 'If update_time' section Update) where my previous time-based Step-size didn't. |
| ||
| He shifty, Not sure what the actuall refresh/running speed is on your system (although it should be the same as mine, right), but don't you think the boxes fall way too 'slooow' to be realistic? Especially since you've got the gravity set to a proper value of -0.98.....?! Cheers, Danny |
| ||
| That's the ODE Step size. This example is just a hack of the JV-ODE "Demo-Cubes.bb" file that is slow itself. In my proper program I use a step size of 0.1 and call the ODE functions (dSpaceCollide, dWorldQuickStep and dJointGroupEmpty) three times per update with gravity = -0.981 The tweening method accomodates all the changes you can make normally, but also keeps them constant across different machines, so you can set the speed to whatever you want. If you drop to 50 Hz you'll need to up step size a bit to match the speeds you were getting before. |
   |