1 registered members (AndrewAMD),
718
guests, and 4
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Please submit bugs and omissions here
[Re: William]
#24612
04/27/04 09:59
04/27/04 09:59
|
Joined: Mar 2003
Posts: 5,377 USofA
fastlane69
Senior Expert
|
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
Yeah all my tests are on terrain (single terrain, ~300000 quants squared of area) and I'm telling you that this last entity theory does not pan out on my system. I have more than one entity with the Jitters and the last entity is just as stable as teh first. Further, with the jittering, there is not going through the terrain as you describe. It does not go through a third of the way like you say. It just "jitters".
|
|
|
Re: Please submit bugs and omissions here
[Re: fastlane69]
#24615
04/29/04 02:33
04/29/04 02:33
|
Joined: Jan 2003
Posts: 748 California
BHoltzman
Developer
|
Developer
Joined: Jan 2003
Posts: 748
California
|
Just a guess about the difference in behavior.
You may have different results with the same code on different systems because of the speed of the systems? Where the faster system is drawing more FPS so objects change position in smaller increments than with the slower system?
I'm not Mr Franklin but I am Benjamin. My avatar partly suites me.
|
|
|
Re: Please submit bugs and omissions here
[Re: BHoltzman]
#24616
04/29/04 05:39
04/29/04 05:39
|
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:
You may have different results with the same code on different systems because of the speed of the systems? Where the faster system is drawing more FPS so objects change position in smaller increments than with the slower system?
The physics system is using constant step sizes of 1.0 / PH_FPS_MAXLOCK seconds.
|
|
|
Re: Please submit bugs and omissions here
[Re: Marco_Grubert]
#24617
04/29/04 06:55
04/29/04 06:55
|
Joined: Mar 2003
Posts: 5,377 USofA
fastlane69
Senior Expert
|
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
Interesting. I had no idea that as I changed my fps_max, I also changed my physics stepsize. But they aren't really constant are they Marco? I can change fps_max and lock it through script after all. Let me run some numbers:
fps_max=20---------> 50ms stepsize fps_max=40--------->25ms stepsize
Both reasonable values.... but what about fps_max=240 as the default and fps_msz=400 as the maximum:
fps_max=240------------->4.2ms stepsize fps_max=400------------>2.5 ms stepsize.
These *seem* awefully small stepsizes....
Three conclusions I'm drawing:
a)This *could* explain alot of the divergent behaiviour we are seeing as a result of using diffrent fps_max rates or using a step size inadequate for our game/sim. For example, people who leave they fps_max at default will have 240 physics steps calculated each second....hence the heavy physics load alot of people have observed.
b) I think Bholtz is onto somthing: Your formula seems to suggest an attempt to lock the physics simulation to the framerate, thus hopefully acheiving one PE update each frame update. But wouldn't this lead to a de-synchronization if the system can't pump out frames that fast? For eg, at fps_lock=240, the PE is updating every 4ms. But on a slow system, wouldn't trying to keep up this framerate mean that a particular frame could last MORE than the 4ms that the PE is updating for?
c) I always thought the stepsize would somehow adjust for the CURRENT or AVERAGE framerate and not locking into a preset MAXIMUM value. If fps_max=100, but your system can only pump out an fps=20, then the PE is IMO making 5 times as many calculations than necessary and these superflous calculations also carry with them 5 times as many errors.
I'm off to test some of the hypothesis I posited above; specifically make a fps_max vs. PE stability analysis. Another interesting nugget Marco thanks!
|
|
|
|