Physics engine update rate and display rate

[masaki]

Again, you can set the step size of the physics calculation to anything you want e.g. 1/480. It is *not* locked to your frame rate.

[performlabrit]

Masaki, the issue is not yet resolved. Currently, it seems to me that Vizard can not be used for high-fidelity immersive simulations in which there is a restriction on V-SYnc. The issue is that, although one can update the physics engine rate faster than the V-Sync, this is done independently of any other updates, which may only occur at V-sync (60 hz, in many cases). This is going to be a huge obstacle if one wants physics to be dependent upon a high-rate data-stream, such as motion capture.

Take, for example, my own work, in which I am developing an immersive virtual environment in which the user hits a moving ball using a real-world racquet that is motion-tracked and represented in the virtual world. Because of restrictions placed upon the main loop, the sensed location of the racquet can only be refreshed at 60 hz - a rate that is VERY slow when tracking extremely fast, yet extremely spatially precise human movements. If racquet location is updated at only 60 hz, movement of the racquet will be heavily aliased, no matter the speed at which the physics engine updates. Swings will be inaccurate, and ball-to-racquet interactions even more-so.

You might suggest that movement of the racquet between frames could be predicted using the physics engine. I've tried this before, and have found it to be very inaccurate.

The ideal situation is one in which subroutines could be run at different rates, or the main-loop could be run at a rate faster than vertical sync.

[performlabrit]

Guys, because our focus has shifted a bit, I have decided to move the last post to a new thread:

"Vsync prevents using fresh motion capture data in physics simulations?"