Bug note

Bug note - 05/27/04 07:22

I just realized that there is a bug in applying forces/torques to bodies. When phent_addcentralforce() or a similar function is called, the force will only be applied for one physics frame (usually running at 70Hz, i.e. force will last for 1/70th of a second). If the rendering framerate is less than 70Hz additional physics frames will be executed for each rendering frame. E.g. if running at 35 frames render speed for every "wait(1)" two physics frames will be calculated, the first one has user-specified forces/torques, the second one only has gravity and constraint forces.
On slower systems this means that forces appear to have less of an impact on a body's motion. I will change this behavior so that user forces are applied throughout the entire time of a "wait()" statement. Please note that this is likely to break existing code if you explicitely set forces/torques in your script.

Posted By: fastlane69

Re: Bug note - 05/27/04 08:16

So if I read you correctly, the PE stepsize wasn't tied into the Graphics stepsize hence the problem.
Thus, the Physics Simulation was taking steps at 70Hz irregardless of the simulation clock (render clock), allowing multiple PE steps for every one Graphics step or vice versa, too few Physics steps for every one graphics step (if fps_max=140 for example). Something like this?

If this is the case, is this bug related to our stepsize discussion from before?

Quote:

I will change this behavior so that user forces are applied throughout the entire time of a "wait()" statement.

I would be interested in hearing more details of the solution once the above problem is more fully understood by us "out here".

If the above is the problem, I would suggest a scheme that explicitly ties in the Physics and Graphics clock in discrete intervals. For example, so you can set the PE clock to run twice as fast as teh Graphics clock when accuracy is desired or half as fast if your simulation values performance over accuracy.

Quote:

Please note that this is likely to break existing code if you explicitely set forces/torques in your script.

Marco, I'm guessing that would be EVERYONE using the PE?

Here's looking forward to THAT!

Posted By: Marco_Grubert

Re: Bug note - 05/27/04 09:18

Quote:

Please note that this is likely to break existing code if you explicitely set forces/torques in your script.
-----------------
Marco, I'm guessing that would be EVERYONE using the PE?

Not necessarily; my car script only used gravity and constraints and thus is frame rate independent. (It's when I added jumping to that script that I noticed the bug). So if you only rely on constraints you're fine.

Here's how the system works:
every force/torque manually applied to bodies gets stored in an accumulator to later be executed. Once all current functions have been executed (i.e. terminated or reached a wait() statement) the physics engine is taking over and has as its input the time expired since last update (e.g. 1/35th of a second). It then splits this time into slices of 1/70th seconds (2 in this example). The simulator then applies the stored forces/torques, gravity and calculated constraint forces for each time slice, polygons get rendered and control is returned to C-Script.

Notes: Physics time is sliced to increase stability, and should not be tied to render time. The size of the timeslices is controlled by the variable PH_FPS_MAX_LOCK and defaults to 70 (Hz). Higher values means more stability and CPU time, lower values equals less stability and less CPU usage. In the current A6 release the user force accumulators would get reset to 0 after the first time slice (that's the bug), which means that when your rendering frame rate is 70 Hz or higher you won't notice any problems. If it is less than that, for each render frame multiple physics frames will be executed, but only the first of these has your custom forces, whereas all of them have gravity and constraint forces. In my jump example on a slow system the car would jump up for one frame and then fall down for two. The next A6 release will have custom forces applied throughout the interval, during each time slice as it was meant to be.

Quote:

If the above is the problem, I would suggest a scheme that explicitly ties in the Physics and Graphics clock in discrete intervals. For example, so you can set the PE clock to run twice as fast as teh Graphics clock when accuracy is desired or half as fast if your simulation values performance over accuracy.

You can do that and it has always been like that. Just change PH_FPS_MAX_LOCK. However, when using custom forces the results may be off until the mentioned bugfix has been added.

Posted By: fastlane69

Re: Bug note - 05/27/04 10:21

I see now. You were resetting the user forces prematurely then. This closer to the truth?
Well at least it's an easy fix on your end.

Quote:

You can do that and it has always been like that. Just change PH_FPS_MAX_LOCK

Dang forgot about that! Out of the manual, out of sight.