+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Softbody (https://obi.virtualmethodstudio.com/forum/forum-12.html)
+--- Thread: Randomness in solvers (/thread-4378.html)
Randomness in solvers - aivenhoe - 26-09-2024
dear obi community and obi experts
I have a question: we are trying to synchronize two softbody actors over network, as suggested on this thread.
As a start we made two identical obi softbody setups running in the same unity application.
One setup involves:
- one obi solver
- two actors (spheres) with slightly different properties.
- obi colliders as a bounding box
We copied the setup within the unity hierarchy and placed it next to the original setup, in PlayMode we noticed that the two setups behave differently after already a few seconds.
The image attached shows the problematic. The setups run side by side with the same parameter values but already differ after a few seconds. Where is the randomness?
According to my understanding the softbody physiscs engine should be deterministic and therefore should behave identical when an identical copy is running on the same machine. Am I wrong?
thank you
RE: Randomness in solvers - josemendez - 26-09-2024
(26-09-2024, 10:55 AM)aivenhoe Wrote: According to my understanding the softbody physiscs engine should be deterministic
Hi,
Most existing physics engines are not deterministic, this includes both Obi and Unity's own engine (PhysX).
The only way to get cross-platform determinism required for networked games (in the same machine and between machines with potentially different architectures as well) is to emulate floating point math - using fixed point or emulating it in software. This comes at a performance cost and often requires the engine to be written with this requirement in mind from the beginning.
For instance, you can find versions of Unity's DOTS physics engine that use software-emulated floating point numbers to achieve determinism.
The reason is that hardware-based floating point math can give slightly different results on different processor architectures. Furthermore, within the same machine multithreading may also yield non-deterministic results as the order in which threads are scheduled change order of operations and hence, floating point accuracy may change results.
This is why physics usually need to be synchronized over the network. Otherwise you'd be good just by making sure world state at time = 0 is the same for server/clients, and then let all devices run the simulation without any synchronization.
kind regards,
RE: Randomness in solvers - aivenhoe - 30-09-2024
hi jose,
thanks for your response!
when syncing the state from a server to the client, is it possible to disable the solver logic on the clients and just render the softbody using the particles recieved from the server (+ some custom interpolation to cover the time between recieving new data)?
We found that setting "Max Steps Per Frame" to 0 stops the simulation, is this the intended way?
Also our thought was to only sync the particle positions and not all the associated other data like velocity, torque etc and instead use the saved bandwidth to sync the position more often and then interpolate between the recieved data. does this sound like a reasonable approach to you?
Thank you!
RE: Randomness in solvers - josemendez - 07-10-2024
(30-09-2024, 04:01 PM)aivenhoe Wrote: hi jose,
thanks for your response!
when syncing the state from a server to the client, is it possible to disable the solver logic on the clients and just render the softbody using the particles recieved from the server (+ some custom interpolation to cover the time between recieving new data)?
We found that setting "Max Steps Per Frame" to 0 stops the simulation, is this the intended way?
Yes, just set the solver's "max steps per frame" to zero. This will keep rendering but stop performing any physics updates.
(30-09-2024, 04:01 PM)aivenhoe Wrote: Also our thought was to only sync the particle positions and not all the associated other data like velocity, torque etc and instead use the saved bandwidth to sync the position more often and then interpolate between the recieved data. does this sound like a reasonable approach to you?
Yes, but you might want to use dead reckoning/extrapolation instead. Interpolating data means your interpolated position will always be behind the latest received data, which may be detrimental to gameplay.
kind regards,