Unity Physics Discussion

Hi everyone,

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.

You can read about the design philosophy and structure of Unity Physics here: Unity Physics | Package Manager UI website

And you can watch our GDC 2019 Keynote announcement here:

Thanks!

5 Likes

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.

3 Likes

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.

2 Likes

Where can i try this? i don’t see it in the package manager (unity 2018.3). Is it only available in the 2019.1 beta?

GitHub - Unity-Technologies/EntityComponentSystemSamples has been updated to include UnityPhysicsExamples

3 Likes

The gamasutra article mentions the new physics system “Unity Physics” will be open-source.
Is this correct? Is the source available already?

Just get the package, source code is there :slight_smile:

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.

5 Likes

One of samples. All checks are disabled, burst is enabled. No performance differences when testing in build.

Ah, there’s a discussion thread already. From another thread:

2 Likes

Will the system support large worlds, e.g. any origin shifting API calls or 64 bit float support?

2 Likes

That being said, the whole idea of Burst and determinism is that it will work crossplatform, deterministically. It’s just not there yet.

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 :confused:

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”

1 Like

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?

9 Likes

Is there any chance of a 64-bit version, since the mathematics library supports doubles?

2 Likes

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!

12 Likes

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 :slight_smile:

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.

1 Like

Can I benefit from the new physics without my game written in ECS or do I need to specifically write my code in ECS to take advantage?

Things I need:

  • convex colliders, including toolchain for v-hacd
  • raycast and spherecast
  • way higher performance than physx
  • automatic networking with unity networking
  • allocation-free API for responding to stay events
  • good strong controls for optimisation
  • Havok “free” with unity pro license? Hope so.

Finally, can we have benchmarks please!

10 Likes

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?

Thanks!

5 Likes