2bit, is your faulty collision with terrain also include the "jitters"? In my applications, which are approximatly 100 single entity physics without any constraints, I have zero percent problem with fall though at any gravity setting (from 0g to ~200g) and within what I consider resonable velocities (less than or on the order of 1000q/s), but I have a big "jittering" problem where my entity jitters like popcorn on the gound and doesnt just lay there as it should. Marco had commented that this may have to do with the number and/or handling of the contact points.

As to your observation, I have a networked physics application where the client is registered with the PE upon login. Hence, the last client logged on is guaranteed to be the last player registered with the PE. I have observed no diffrent behaiviour from last registered to any registered...all my physics entities "jitter" seemingly at random.

Did you do your tests on terrain? Since everything works fine on block geometry. About the jittering, yes I've observed it many times, and it needs to be fixed. This isn't jittering though, since the last physics entity enabled actually intersects the terrain and goes down about 1/3rd then pops back up - only to repeat itself agian. Of course, I guess I can just apply the physics engine to some rock out in the middle of nowhere last, that way it will have the faulty collision and everything else will be good.

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

Perhaps you need a vehicle with 4 wheel constriants to re-produce my problem. Since that is the only way I have tested it. I dont understand why it's not showing up for you like it is for me.

I've notcied since day one that most of the PE problems revolve around the constraint system, I bet you thats why we have diffrent results as I don't use constraints.

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?

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!

FPS_MAX has nothing to do with PH_FPS_MAXLOCK!

Jebus H. Krist your right!!!

From the FAQ section (THE FAQ! geesh)...

Quote:

---

By default PH_FPS_MAX_LOCK is set to 70 fps. If FPS_LOCK is enabled and FPS_MAX is also set to 70 fps the simulation time will be synchronized. Setting FPS_MAX to, say, 35 will make the objects move at half their speed instead.

---

Which means I'm going right now and locking my framerate at 70!!! This explains why my objects seemed to fall so slow!

However, Point 3 is still valid; The PE has a static stepsize. Assuming the PE is doing some sort of ODE integration, every Physics simulation I have ever programmed takes an ADAPTIVE stepsize in order to better integrate the physics behaiviour and reduce error. For eg, (straight from "Numerical REcipies in C") 4th order static stepsize Runge-kutta has a error O(h^5). A naive adaptive routine, say Runge-Kutta-Felberg method have errors of O(h^6) and this error can be imporved upon further by more intelligent adaptive procedures (Richardson Extrapolation for eg). In my experience, a locked-in stepsize is asking for trouble no matter what stepsize you choose