With the Unity Physics integration now available we would like to use this thread as a means of getting feedback, requirements, and having candid discussions about your physics needs. Please feel free to post any requests, concerns, or issues you have with the new DOTS-based physics system in this thread.
Thanks for posting this thread. Just curious â are you able to quantify the gain in performance between the old architecture and new with regard to Unity built-in physics? Not really looking for a fancy tech demonstration but an actual quantitative measurement of before vs. after.
DOTS physics is supposed to be deterministic?
In one of test scenes with 100 of physics bodies I have 5 fps, while with builtin physics I can have thousands. Why such difference?
Perhaps not related but the keynote mentioned ânetwork friendlyâ with the block talking about rollback capabilities - is there any bigger picture of the current plan/intention behind this network friendly, what to expect etc?
I thinking in particular on topics regarding determinism etc that have a heavy impact on the possible network architecture of a game.
Itâs something that weâre still crunching the numbers on. Obviously being in Preview, there are still things we need to implement and set up so a performance comparison right now seemed unfair. That said, are there any specifics youâre looking for performance comparison wise so I can ensure we get you the data youâre after?
For us to have complete determinism, we need to update a few things on the Burst Compiler which are in the works. As far as the performance goes, would you mind sharing the scene so I can take a look at it and see whatâs going on?
Unity Physics will be shipped as a C# Package so yes, you can open it up and modify, extend, or pour over the actual code as much as you like.
Yes, the new Unity Physics is only compatible with 2019.1 beta and forward.
In collectors structs, is there a reason about the way that most of the comparison of fraction between hits/old fraction are done as âinferiorâ and not âinferior and equalâ?
The only method where itâs âinferior and equalâ is ClosestHitCollector.AddHit(), others are not using the same comparators
So, for checking if my ray is hitting a box, Iâm obligated to add a small distance in MaxFraction (like 1.00001f instead of 1.0f).
var closestHitCollector = new ClosestHitCollector<RaycastHit>(1.000001f);
which feel like a hack.
But anyway, the new physics are awesome! (itâs awesome to use raycasting inside burst jobs!)
edit: oops, I meant âinferior and equalâ not âsuperior and equalâ
Whatâs going to happen with the current PhysX integration over time? Will it be completely replaced with Unity Physics?
Whatâs the price point for Havoc going to look like? Free? Free with Pro? One-time cost? Licence?
Whatâs the difference between Havoc and Unity Physics going to be? You said something in the keynote about the interface being the same, so does that mean that the difference is âonlyâ going to be in performance and behaviour?
Weâll continue to support and evaluate upgrades to the PhysX integration, no major changes there if youâre using it currently. Unity Physics and Havok Physics are targeted towards DOTS-based projects only so if youâre using DOTS in your project, these are your go-to solutions.
Still working out the details regarding the Havok Physics integration. Iâll be following up with info here and in another blog post once weâve locked down all the details.
Yes, so weâre using the exact same data layout in the Editor which means when you author a bunch of content youâre only building it once. For example, if I set up my environment with a bunch of physics components and I am using Unity Physics and then I decide to use Havok Physics, I donât have to redo every object to use a set of Havok components. Similarly, any game code or scripting logic youâve written to use Unity Physics will work just the same if you swap in the Havok Physics backend.
Regarding differences, theyâre both intended to be high-performance physics solutions, they just solve different production needs. Unity Physicsâ key points are the fact that itâs a C# package so you can easily get in there, look at the source code, and modify it to your heartâs content. Itâs also stateless, so instead of using caches, we rely on brute force optimizations to make it more compatible with things like network rollback architecture. Havok Physics is integrated using the Havok engine and uses caching so youâre able to squeeze more performance out of complex scenarios and get much more stable simulations for things like stacking, lots of rigid bodies, etc. Hopefully, that helps explain it a bit more but let me know if youâd like more details!
Technically the source code is shipped with the package and Unity Physics isnât super complex so you could probably just swap the floats to doubles manually right now. I do hope we get some toggle later on, that would just swap for example ârealâ types into float or doubles accordingly
There is one big downside on the doubles right now. As far as I know, Burst doesnât do anything special for them, so youâll lose a lot of automatic optimizations. For example to be able to do doubles four wide in SIMD, youâd need at least AVX support. Besides Unity not putting focus on double precision optimizations, Burst itself uses only SSE4 on windows for example.
Itâs definitely possible to use Unity Physics and have your physics simulations integrated via DOTS though it would require you to bridge the physics world with your GameObject world so you can get the events and everything passed back and forth properly. Ideally, and the way weâve approached this, is you would operate entirely in the DOTS/ECS world for gameplay and physics simulation purposes.
Noted your requirements and will sit down with the team to discuss these as part of our development cycle. A few questions I did have though:
For the v-hacd are you primarily after the ability to specify that you would like multiple convex hulls to be generated for a given mesh? And any thoughts on how you might want to define this or set it up?
For automatic networking and unity networking could you expand a bit more on your requirements or expectations here?
