|
1 registered members (TedMar),
1,420
guests, and 3
spiders. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Bug note
[Re: Marco_Grubert]
#28003
05/27/04 08:16
05/27/04 08:16
|
Joined: Mar 2003
Posts: 5,377
USofA
fastlane69
Senior Expert
|
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
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!
|
|
|
Re: Bug note
[Re: fastlane69]
#28004
05/27/04 09:18
05/27/04 09:18
|
Joined: Sep 2003
Posts: 3,236
San Diego, CA
Marco_Grubert
OP
Expert
|
OP
Expert
Joined: Sep 2003
Posts: 3,236
San Diego, CA
|
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.
|
|
|
|
