Physics engine update rate and display rate
 

Hello,
I'm programming a virtual racquetball experiment in Vizard. In my experiment, physics engine has to run at a much higher rate than visual display rate (60Hz). But it seems when I decrease the display rate the physics engine update rate goes down as well. So does anyone know how to solve this?
Any insight would be helpful,
Thanks in advance.

Can you explain why you need the physics engine to run at a faster rate? Physics updates occur in the main Vizard loop and will be in sync with the display rate.

Hi Jeff,
I need to do this because in our racquetball experiment, ball travels really fast so physics engine must be fast to allow collision detection (from my understanding), do you know any way to solve this problem?
Thanks!

Jeff, it is that in our experiment the ball moves really fast. I think I need physics engine to update fast to allow accurate collision detection.

Is the issue that the ball goes through the paddle? If that's the case you could make the collide shape thicker on the paddle. If you need to record the collision at a precision higher than the framerate I don't think that's possible.

Yes. I guess I can make the paddle thicker. But ball going through the paddle is not the major issue though. We use a phasespace system and need to stream data at 480Hz, is this also restricted by display rate? Is there any way to deal with this?
I appreciate your help, thanks!

You can reduce the step size, or the time between each physics calculations, by using the viz.phys.setStepSize command and set it to 1/480.0.

Hi Masaki, thanks. But when actually running the code physics engine is sync with display rate, which is 60Hz, how do I solve this problem?

Let me see if I can phrase the problem a little differently.

Given ball and racket velocities, 60Hz is too slow. There's a motion capture system (PhaseSpace) running at 480Hz providing the position of the racket. It seems like the physics engine should be running at the same rate to provide the most accurate gameplay. Making the paddle substantially thicker isn't really an option, as they can hit with either side of the paddle.

We had a working version of this written in C++, but are switching to Vizard for a variety of reasons. We have it mostly working in Vizard, but this issue has remained a problem. It seems like others should have bumped into these kinds of problems before as motion capture often runs at faster rates? Or is there a way to have the Vizard main loop run at a faster rate without attempting to render at that rate?

i would also like a solution, for similar reasons. It would be disastrous if the rate of data-polling was capped at the vertical sync rate of 60 hz. Eye-tracking, motion capture, and many other systems must run at rates >60 hz to be effective. I would be grateful if you could post your findings!

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.

related issues - physics dependent upon measurement?
 

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.

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?"