You could have saved people a fair bit of reading Waterman by simply saying "I don't think that it is broken."
Ok. I rarely write long replies (actually i rarely write any replies these days) but here is clarification. You are free to ignore it.
Over the years i have seen many people having issues with duplicated physics. It's obvious that not many understand all the concerns affecting the whole. Hence i don't see a problem in discussing this?
"Broken" or "fixed" or "deterministic" aren't categoric terms. Newton physics tries to offer solution for a variety of needs, ranging from simple to complex. The behaviour that makes some people say it's "broken" may be a problem for a few users while yet the majority never experience it.
Still people tend to classify physics engines as deterministic or non-deterministic. But when placing that word in the context of physics it's meaning changes. By definition, the term "deterministic" gives little room for interpretion. Still i find it acceptable to use the word to describe characteristics of a sequence of calculations when put in the context of 3D physics simulation. The user or coder may experience the dynamics he/she simulates as deterministic if the visaulization of it is sufficiently repetitive. Thus, the word has a practical meaning and that meaning is not necessarily the same as it's theoretical meaning.
My original (and persisting) claim was that Newton dynamics is deterministic. It was a reaction against someone downclassifying it based on, what i believe, loose premises. Newton allows for sufficiently repetitive behaviour to be called deterministic...
...provided that you set up the scenario in a way that allows it to be deterministic in the first place.
This is where many users fail. The environment that "holds" the physics engine introduces dozens of potential pitfalls, that each increases the risk of losing the predictable/repetitive behaviour of the calculation. Even though the physics engine may be internally fully fit to be called deterministic, the environment can (and will) still be inaccurate. For example:
1) The time sample taken from hardware is not fully precise.
2) The frame rates on two parallel systems are not identical. Even though one uses fixed steps, the accumulation of time itself introduces inaccuracy. It's easy to prove the inaccuracy of accumulation. Calculate (in code) the sum of 1. The answer is 1 - highly predictable. Then calculate the sum of 0.1+0.1+...+0.1, that is a 10-cycle loop that accumulates the value 0.1. The answer is 1, of course. Now calculate the sum of 0.0001+0.0001+...+0.0001. The result is no longer 1. It's close to 1 though. Here are the results for 10^0...10^7 when using double precision in my system:
1 1 1.000000000000001 1.000000000000001 0.9999999999999068 0.9999999999980841 1.000000000007918 0.9999999997501702
Even if two computers run identical calculations, a 2000 FPS system may send a different number of calls to SimulateFixedstep 0.05 than a 23-FPS system, during a total time of for example n minutes. Naturally, having the CPU in 32-bit fp mode makes it much worse (and as some may know, DirectX sets the CPU to that mode by default).
3) Mistakes originating from users not understanding numerical space: Say that you develop a perfectly repetivite (a "deterministic") sequence of physics behaviour. A shooting fight with hit detection in a FPS. It works superiorly well when it performs at around world position (0,0,0). Then move the sequence to world position (0,0,10000) and see how it goes completely off.
4) Using multiple threads. At a critical point, which one kicks first? A hits B and kicks C or B hits C before being hit by A? If the physics calculation doesn't suffuciently manage the distribution of tasks, the execution order may deliver unexpected, non-deterministic results.
Etcetera etcetera. Deterministic is imo a bad word in this context. "Highly" or "poorly" deterministic would be more appropriate, "accuracy" probably best. As usual, the advice is:
1) Use doubles, set the CPU to full precision (TVEngine.SetFPUPrecision). 2009 is a good year to skip the 32-bit floats.
2) Do everything as close to (0,0,0) as possible.
3) Use short (in time) parallel & independent sequences if possible.
4) Use a master/slave solution for networked physics.
5) Don't expect 100% precision - you won't get it.
