#How does Unity physics achieve full determinism?
1 messages · Page 1 of 1 (latest)
hi Greco! Unity Physics is single-architecture deterministic, meaning that under the same CPU architecture it will produce the same results, always that your gameplay code is also deterministic in that architecture. Conversely, this mean that we don't guarantee you will get the same result in different architectures (i.e. PC and PS5)
Cross-platform determinism is a burst compiler problem to solve, and while the team is interested in working on that, we don't have any plan for now.
Hello,
For the purposes of this determinism question, is restricting to Windows 64bits PCs enough to guarantee a single CPU architecture and therefore determinism? And what about other PC platforms such as Linux and MacOS?
Sadly not, there might be small differences between AMD and Intel x64 CPUs for example, making those architectures to produce different results. The same can happen in other platforms.
🤔 Any reason why Unity Physics not removing all the float and fully embrance integer to implement fully deterministic physics without needing to rely on burst compiler? Is using float for performance reason?
Integers by themselves are not enough to create a physics system. While fixed types could be simulated with integers, its performance would be extremely bad.
Do you have any specific requierement of your project that require deterministism behaviour? there might be other possible solutions.
For my part, we are starting work on a multiplayer deterministic lockstep game, so having the whole ECS world deterministic would be the best. Is there any chance that the cross platform determinism would be available within the next year?
Oh that's why fixed type physics is only using for very simple physics like at rts game that just use for collision detection.
@potent cape sadly not, we don't have any ETA for cross-platform determinism, so plan ahead your project without counting on it 😦
I would to record and playback match replay deterministically and also implement kill cam like overwatch
exactly, out physics systems are designed to cover a wide range of use cases, but not all of them. Its always a good a idea to use a custom/basic physics system for such specific cases.
how long are your matches? how many actors need to be replayed? im wondering if a mix of snapshot interpolation techniques, mixed with good compression algorithms might be enough if the game is simple enough.
Maybe 10+min with 8 players competitive game. By snapshot I guess u mean record all the data that has been changed?
yes, i am thinking about recording the compressed players transform every X amount of ms, just the axes that you need, and using several compression techniques, like delta compression. Also, quaternions can be compressed into a single float using certain compression techniques. then in the recorded timeline you can create custom events to spawn/destroy objects. up to 32 booleans like firing/jumping/reloading could be fit in a single int (or 8 in a byte). most of the cosmetics like sounds and animations can be inferred from that info without needing to record that info.
From what u say, I guess today is not possible to come out with a cross platform fully deterministic physics heavy networking game like party animal until burst compiler address floating point problem?
here you have a great article on delta compression https://gafferongames.com/post/snapshot_compression/
that depends on your game requirements, actually the snapshot compression article i sent you address that issue by simulating the physics on the server, and the rest just interpolates towards them. This introduces the problem of the client input responding slowly, or needing to predict the player and recoincile with the server when the player prediction fails, but its possible and used in several commercial games.
Btw since I'm using dots netcode is that possible to make it just work since dots netcode has snapshot with delta compression if I remember correctly that I can just save dots netcode snapshot and playback at client?
im not sure if the APIs expose all that info, but should be possible. you might need to recreate some of the playback code of the netcode package, but im not sure right now
btw, this is how netcode for entities work
@potent cape slightly crazy suggestion, but have you looked into running some or all of your simulation inside WASM (web assembly)? WASM is deterministic, so you could compile an external physics engine to it and achieve determinism that way (I suspect marshalling data in and out of wasm would kill performance, but it might be worth investigating).
This is an interesting idea, thanks a lot!
I would like to stick to the DOTS tooling as much as possible so using integers/softfloats seems like the way to go though I will definitely take a look at WASM 😄
Assuming the exact same hardware does burst guarantee determinism in such a case? (With deterministic code of course)
any floating point operations should be deterministic in the same hardware, as you said, given our code is also deterministic
Ok I'm asking because I've heard that for example syscalls might change floating point flags or something like that, so I'm not sure if that would affect burst code at all
How does burst handle the rounding mode? For example x86 CVTPS2DQ rounds according to the MXCSR register, does burst set that register or would I need to handle that myself?