Unity will update PhysX to the latest version in Nov, there are some rumors about nVidia said it’s deterministic. Is that means PhysX component like rigidbody can be used in Server authoritative game? Anyone know further info?
I am not a developer of PhysX, but I am quite sure the PhysX won’t ever be universally deterministic. There are just too many things that will cause issues in that.
Currently you can get quite similar results between runs if you run your game in one machine and you do not instantiate new physics objects during runtime.
What I really need is to step physics manually, like what you can do in Bullet. But Unity handles rigidbodies automatically, which is fine in most cases but makes physics itself impossible to be networked.
1 Like
Even if it was deterministic “soon” you’d be looking at a long time before it might be available in Unity. As it’s merely rumour, I would say no.
The forum post indicates you would basically need to reload the scene each time you want the same results in Unity, which makes it useless for deterministic networking.
1 Like
I find real difficult to believe that a time-integrated physics package ,even worse ,running on non identical hardware can ever be deterministic.
three ball collision problem comes to mind …
As least some form of physics can certainly be deterministic, given that’s how the old Myth games loaded saved games. That is, save files were a recording of the game actions, and loading saves merely re-played the game at high speed.
–Eric
1 Like
and it will be , as long as the saved game is run by the same computer. But if using another cpu , the results area gonna be different. I am ready to bet a beer that if I run
float a = 3.7897495f;
for (int i =0; i < 10000; i++)
{
a = Mathf.Sin(a + a * 3.23781379f )
}
we got different results of ‘a’ unless we happen to have the same computer.
0.5721989 Mac
0.5721993 PC1
0.5722451 PC2
I think the only way to achieve deterministic physics would be running those in a standarised deterministic virtual machine , that would be horrendously slow.
-JC
Not with Myth, no. Saved games from years ago on a different computer work fine on a modern computer. I expect they didn’t use floating-point math.
–Eric
1 Like
IMO float won’t be a horrible problem unless we caculate it too many times or network situation is rather bad. Basically, what we need is a resimulatable system to do predicted movement.
Since I’m not a math expert, @SpaceSimulator 's bet surprised me. I read a doc about float losing and it shows how binary convertion make that changes step by step. So I thought it should be hardware independent.
I was under the impression that floating point math was standardized (IEEE.754) and produces the exact same results whether it’s done on a Mac, PC, XBox, Raspberry PI or other device. So far this assumption seemed to hold up for me (PC, Xbox 360, Utilite (ARM Cortex-A9)).
Afaik the main issue here is fixed time stepping (in contrast to delta time stepping). You can set the minimum and maximum time step in Unity’s Physics Settings, if you set both to the same number Unity should be doing fixed time steps for physics (i.e. if 1 second passes, it could do 10 steps of 0.1 seconds instead of one step of 1.0 second).
On some platforms (x86/x64 namely), FPUs can be switched to different modes. According to MSDN, x86 FPUs have “strict”, “precise” and “fast” modes where “precise”, if I remember right, internally uses 80 bit registers on the FPU to store floating point values (see visual c++ compiler option). But so long as there’s a common mode that matches other platforms it shouldn’t be an issue.
Some words on floating point math standards:
As far as time, that’s not how it works. The first settings is fixed timestep, which is the physics framerate, with the default .02 (seconds) meaning 50fps, so the physics is updated at 50fps regardless of the actual framerate. The other setting is maximum allowed timestep, which is basically a throttle on the display framerate if the time spent on physics exceeds the specified amount. That is, the game will slow everything down to allow enough CPU time for physics rather than making the fps really choppy, the idea being that a slowdown is less visibly bad than a poor framerate. Although ideally you would avoid both, so a better idea might be to increase the fixed timestep instead (lower the physics framerate), and use interpolation/extrapolation to visually smooth out objects moving via physics. In any case the “fixed” timestep is no longer fixed if maximum allowed timestep kicks in, since you’d be getting less than 50 physics frames per second.
–Eric