|
|
Post by lerxst on Feb 12, 2015 17:48:56 GMT
Is it in the programming, or the small details on the machines? I've noticed that a slight sway of just .5 degrees left or right will totally change the outcome of a test... basically, that "wobble" when the test starts.
|
|
|
|
Post by AJW on Feb 12, 2015 18:24:08 GMT
Computed floating rounding errors should always give the same results - floating point rounds and truncates, but is required to so consistently (per the IEEE floating point spec). As soon as there are user inputs though, the exact timing adds a 'random' element. Is anyone getting inconsistent results without user input?
|
|
|
|
Post by moltenpoo69 on Feb 12, 2015 18:49:35 GMT
Personally I like the unpredictable results. I think of it as random factors and hidden variables: fluctuations in wind direction and strength, mechanical and material imperfections... that kind of thing. Trying to adapt to and build around the uncertainties, and often failing dramatically, is a big part of what makes the game (and real life) fun.
|
|
|
|
Post by AJW on Feb 12, 2015 19:12:37 GMT
I've just checked, and it seems that even without user input, there is some sort of initial random element. I agree with moltenpoo69 though that this is a good thing - it adds an uncertainty to designs, and makes the game more entertaining.
|
|
|
|
Post by derschmied on Feb 12, 2015 20:31:47 GMT
Hy guys! I don't know how the multi body dynamics are implemented, nor do i know the material law which is being used (Neo Hookian??). Lets take the old and common MD-ADAMS (please don't hur me 4 Copyright issues). It is using some rather Mature simplification on the standard setting, ignoring gyroscopic forces and there momentum of inertia. Actually, it is ignoring ALL THERMS of higher derivation in the Formulation of the "equations of Motion" (whatever you English guys call em). Furthermore a 3 dimensional, (rigid or elastic or whatever) Multi-body system is described (generally) by Differential algebraic equations (the descriptor system). This is made "solvable" by (twice) derivating the constraint equation (or a huge Matrix of Constraint equations). This is not happening analytically, therefore a discretisation is carried out. -> Here lies the fault for all your randomness! [ insert tons of Math here ] ...The newly created set of equations is, due to failure growth (constant failure (e.q 10^-6 mm²/s) of displacement means a quadratically growing failure of displacement) not sufficient by nature and has to be corrected (Predictor-corrector). Furthermore, your system is likely to start at random initial values, instead of equilibrium, of the constraints. I also do not know which method is implemented for Coordinate Transformation. Are there Euler Parameter (good) are there euler Angles (not good, can cause numerical troubles) or Rodriguez parameter (also not good)  In case of Euler Parameter, the Rotation Matrix, which determines the Angular Velocity Vector, is not unique, hence the system might create them different at every "placement" of your siege weapon. Please excuse the relay bad layout and grammar + style, its late at night here in Europe! Cee ya DerSchmied |
|
|
|
Post by pdcwolf on Feb 12, 2015 21:18:00 GMT
Is it in the programming, or the small details on the machines? I've noticed that a slight sway of just .5 degrees left or right will totally change the outcome of a test... basically, that "wobble" when the test starts. Computed floating rounding errors should always give the same results - floating point rounds and truncates, but is required to so consistently (per the IEEE floating point spec). As soon as there are user inputs though, the exact timing adds a 'random' element. Is anyone getting inconsistent results without user input? Not really. They probably would on a perfect world, given that rounding and truncating would always stays the same. When you load a machine there's a very small (or noticeable, depending on size and part number) hiccup, coming from the physicsless parts in edit mode entering the simulation and the engine loading physics for all of them at the same time. Keep that in mind, I'll return to this in the next paragraph. In the real world, speeds for disk reading, cpu clocks, gpu core and memory clocks and such vary all the time and so does the workload in your computer, even when playing the game. If all of this was constant and perfect then yes, there would be almost no variation, given each calculation is run on the exact same environment. Now let's bring the imperfections of real life into play: when you press space, the parts get loaded into the physics engine causing a hiccup. That first hiccup creates forces on your machine, most noticeable one is wobble. On a perfect world, those forces would always be the same, but in our real world they aren't because the processes are never executed 2 times at the same speed and under the exact same circumstances. Those initial variations then get carried around when you put your machine to work, this is what gets a flaming ball stuck, a bomb to explode when touched by a grabber, a part breaking or not under the same circumstances, etc. This also happens during the simulation, the physics update each frame, and if the framerate is not perfectly constant (protip: it isnt) then more variations are created and the rounding and truncating happens differently to supposedly compensate for said variations and keep the speed of the simulation as constant as possible or the simulation as coherent as possible without causing a meltdown on your cpu. |
|
|
|
Post by AJW on Feb 12, 2015 22:07:44 GMT
Does the physics engine start to simulate 'wobbles' etc before it has loaded all the parts? I'd assume not. You may well be right about variations in frame rate affecting repeatability though - I'd not though about that.
|
|
|
|
Post by pdcwolf on Feb 12, 2015 22:28:51 GMT
Does the physics engine start to simulate 'wobbles' etc before it has loaded all the parts? I'd assume not. You may well be right about variations in frame rate affecting repeatability though - I'd not though about that. wobble is not a simulation per se, is the consequence of using unity's stock "fixed" joints I believe; that are weak and connect stuff by a single point. |
|
warp
Peasant
Posts: 16 
|
Post by warp on Feb 13, 2015 12:28:27 GMT
First of all, floating point operations always yield the same result. It's just, that this is not necessarily the true result of the mathematical calculation, but still always the same.
The randomness is totally fine for me. If it's induced by random number generators.
However, ths speed-up problem mentioned is something different. Apparently the physics engine frame-rate is not adjusted. So one game second normally has ~60 physics steps, but when slowed down, 0.1ms have 60 physics steps. Thats more precise. IF that is how it is done. A better way to do this would be to reduce the physics engine to 6 fps and interpolate in between, if its slowed down to 10%. That would give the same results regardless of time scale. Also for speedup it needs to be set to 120fps then. It's not using the computation power perfectly, but gives that consistency and prevents "hacks" by slowing / speeding up game time.
I DON'T know, if it is different from that in the moment. But from the other comments, it seems to be.
|
|
|
|
Post by pdcwolf on Feb 13, 2015 17:14:21 GMT
First of all, floating point operations always yield the same result. It's just, that this is not necessarily the true result of the mathematical calculation, but still always the same. The randomness is totally fine for me. If it's induced by random number generators. However, ths speed-up problem mentioned is something different. Apparently the physics engine frame-rate is not adjusted. So one game second normally has ~60 physics steps, but when slowed down, 0.1ms have 60 physics steps. Thats more precise. IF that is how it is done. A better way to do this would be to reduce the physics engine to 6 fps and interpolate in between, if its slowed down to 10%. That would give the same results regardless of time scale. Also for speedup it needs to be set to 120fps then. It's not using the computation power perfectly, but gives that consistency and prevents "hacks" by slowing / speeding up game time. I DON'T know, if it is different from that in the moment. But from the other comments, it seems to be. I think this is getting a little confusing. Obviously doing 2.465747 + 1.354735 is going to give 3.820482 every single time. but what happens when you don't have the time to count all those decimals or you can't display them or you show them to someone who doesn't care about decimals (converting float to int for whatever reason) ? You need to round them. The amount of rounding and the precision it uses depends on how fast the calculation needs to get done (if you are low on fps, that's less time, less precision) and given framerate varies a lot, you are never going to get the same conversion and rounding twice, thus creating different results with the same initial point. I hope I made it clearer. |
|
warp
Peasant
Posts: 16
|
Post by warp on Feb 14, 2015 1:45:35 GMT
That's also wrong. Rounding always gives the same result, regardless of cpu load.
What you are talking about is, that the time-steps vary, because the frame-rate is not constant. However, while almost all graphics engines have a variable frame rate, physics engines can as well have fixed ones (which you don't see though). Might still be variable frame-rate in besiege. Then:
Basically, collision detection gets less precise, when the blocks pass longer distances before the next step / collision test. Also, most engines use euler integration for movement, that means:
At one point, you have a speed of 20, and an acceleration of 10 per timestep, now you want to have the speed after 2 timesteps: 20 + 10*2. That's euler integration. However, the acceleration can change (e.g., if you use a spring, the acceleration depends on the current position, so it really would be only 8 in the second step). The smaller the steps, the more precise the result is. Those two things make a difference when the physics frame-rate is changed. But that's NOT rounding!
Anyways, I suppose the randomness is kind of wanted. And if your machine breaks every now and then... Well, then you should build it more stable. ^^ The one point I CAN agree with, is, that it's annoying that those things happen directly when starting the game, just because your tank or whatever gets a little "shock" everytime it starts to simulate. A shock, which you would never receive in the actual game. But that's hard to fix. Especially since its the impact, and smaller timesteps don't really help there.
EDIT: A little background info as well: Every calculation is done as fast as possible, and the cpu doesn't actually care whether the FPS drop. Variable frame-lengths or frame-dropping is just a method somebody programmed into the game, so that the time doesn't slow down, when the cpu load is reached. If you by accidant know supreme commander: There the actual game slows down, if one player can't carry all the simulations. For exactly the reason, that the game needs to be completely deterministic. Graphics frames can still be dropped.
|
|
|
|
Post by pdcwolf on Feb 14, 2015 3:12:19 GMT
That's also wrong. Rounding always gives the same result, regardless of cpu load. What you are talking about is, that the time-steps vary, because the frame-rate is not constant. However, while almost all graphics engines have a variable frame rate, physics engines can as well have fixed ones (which you don't see though). Might still be variable frame-rate in besiege. Then: Basically, collision detection gets less precise, when the blocks pass longer distances before the next step / collision test. Also, most engines use euler integration for movement, that means: At one point, you have a speed of 20, and an acceleration of 10 per timestep, now you want to have the speed after 2 timesteps: 20 + 10*2. That's euler integration. However, the acceleration can change (e.g., if you use a spring, the acceleration depends on the current position, so it really would be only 8 in the second step). The smaller the steps, the more precise the result is. Those two things make a difference when the physics frame-rate is changed. But that's NOT rounding! Anyways, I suppose the randomness is kind of wanted. I wasn't trying to go that deep, it is, as you say, not directly tied to cpu load, what I wanted to say is that another of the things that creates that "randomness" is the simulation not having exactly the same resources available to run on every time (which means it is indirectly tied to system load although not THAT noticeable unless you run heavy stuff on the background). Also, you should read this en.wikipedia.org/wiki/Floating_point#Accuracy_problems which you probably know already since you know about integrators and such. As I said multiple times already, I don't have experience with the code of the physics engine itself, so I'm no pro at that, but I do have experience with the physics engine itself from other games and running it myself on my projects and I know its flaws (such as wobble and this kind of imprecision). You are right on the timesteps, that's how the engine actually works, but those timesteps still depend on framerate for the unity engine, some other engines have asynchronous physics calculations (especially those that support multithreading and don't run on a single core). A way to prove this is what is written in the image, slow down the timescale to get a constant framerate and you are more likely to get results closer between themselves, if you push the timescale up and run a big machine with a lot of parts (causing a bigger initial hiccup) your results will vary wildly. That's what causes the "randomness", not someone sticking RNGs in the physics engine. It was also proven multiple times that what causes the hiccups is all the parts going from physicsless (a property you can set on unity) to physics enabled, and the engine obviously processing them all at the same time. |
|
warp
Peasant
Posts: 16
|
Post by warp on Feb 14, 2015 3:32:28 GMT
I guess it's not the right place to discuss how floats work etc, I'd say I know. I was just a bit too correct about what the words actually meant, I guess. So yes, it seems like the variable frame rate is the problem then. I never worked with unity, but from what you wrote it's unlikely that it can simply be disabled. Maybe it's possible to adjust the time scale, if the cpu is at its limits, instead of changing frame rates.
Enabling a new object for physics also has the problem, that its not yet deformed, and no contact areas / forces are known to the engine yet (would be recycled form last frame otherwise, to make the calculation more precise and only adjust the forces). There's not really anything to be done about it though.
All in all, if it's not possible to fix this by just setting a different option for the unity engine, then I wouldn't care too much. It can be annoying, but it's not worth too much effort. Effort, which could be put into new blocks / levels / controls.
|
|
|
|
Post by pdcwolf on Feb 14, 2015 3:47:37 GMT
I guess it's not the right place to discuss how floats work etc, I'd say I know. I was just a bit too correct about what the words actually meant, I guess. So yes, it seems like the variable frame rate is the problem then. I never worked with unity, but from what you wrote it's unlikely that it can simply be disabled. Maybe it's possible to adjust the time scale, if the cpu is at its limits, instead of changing frame rates. Enabling a new object for physics also has the problem, that its not yet deformed, and no contact areas / forces are known to the engine yet (would be recycled form last frame otherwise, to make the calculation more precise and only adjust the forces). There's not really anything to be done about it though. All in all, if it's not possible to fix this by just setting a different option for the unity engine, then I wouldn't care too much. It can be annoying, but it's not worth too much effort. Effort, which could be put into new blocks / levels / controls. Wobble can be fixed a lot, but you actually need to "unbreak" unity's configurable joint and work with that instead of the fixed joint, not sure how easy it is and how it'll work in unity 5, which may have it fixed. Physics and framerate being synchronous (easy to prove by playing with the timescale and how it changes the framerate, thus affecting the timesteps) can't be "fixed" as far as I know. Obviously the priority of all of this depends on the dev. |
|
zalo
Peasant
Posts: 2
|
Post by zalo on Feb 14, 2015 20:38:03 GMT
Hey guys, So floating point rounding will make physics indeterminate across different machines (different CPU architectures round differently), but a lack of fixed timestep/variable timestep interpolation (accumulating varying floating point rounding errors) and random order of operations will cause indeterminism between different runs on the same machine. Someone figured out how to turn off Unity's variable timestep interpolation features here: answers.unity3d.com/questions/46724/deterministic-physics-same-platform.html (at the bottom) so physics seemed indeterminate in a limited window. However, once you start having scripts creating objects (where the order of execution of the scripts isn't controlled), then those objects will get added to the physics engine in varying orders, causing their collisions to be applied in varying orders. There were some contraption games in the past like Armadillo Run that were deterministic, but you couldn't interact with your contraptions (only set timers). With Besiege, it's pretty much worthless if your contraption relies on inconstant user input. Matthew W. of Fun-Motion wrote an interesting series of posts on this a few days ago: forum.unity3d.com/threads/unity-physics-and-making-it-deterministic.295949/ |
|
