Official 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: https://docs.unity3d.com/Packages/com.unity.physics@0.0/manual/design.html

And you can watch our GDC 2019 Keynote announcement here:

Thanks!

 

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.

 

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?

 

https://github.com/Unity-Technologies/EntityComponentSystemSamples has been updated to include UnityPhysicsExamples

 

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

 

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.

 

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:

 

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

 

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

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).

Code (CSharp):

1. 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?

 

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

 

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.

 

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!

 

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!

 

If anything I REALLY hope Unity doesn't do this. This was everything that was wrong about Unity before 5.0. Please don't put actual game engine features behind a paywall that limits people coming to the engine.

 

Not quite because with indie/pro before, you *couldn't* use the service on free no matter how hard you tried. You couldn't add render textures.

Here you still could use free but license havok / other. that's a big difference, actually.But I agree. I cannot afford havok for my team members and it looks more like an AAA option.

It would also screw up various licenses.

So currently I can only have one pro seat so it's not super democratic, I agree with you.

 

I disagree, if Havok is going to be the future stable and more performant physics option for Unity, it's considered to be game engine feature, not a service But it's too early to speculate. I however hope that if they can't offer Havok for all engine users without extra cost, they would at least make it a separate offering.

 

Ideally we treat it just like a single convex collider - invisible behind the scenes. After all, the reason for using this is purely a) dynamic rigidbodies with complex "mesh" colliders and b) improved performance for casts, queries, or even just general optimisation because convex -> convex is always better than convex -> mesh weird thing.

I guess the mesh collider could take care of it by chopping up a mesh to convex behind the scenes with a slider for precision between 0 and 1.

Really, we just want a lot better perf for anything convex or query -> mesh.

I'd expect something similar to gaffer on games's tests - a ton of things bouncing around that don't really need any traffic or attention to be in sync. Also I would expect if I am controlling a rigidbody with forces, to see it just replicated on other machines.

It seems to me one of the major points of having networked physics, is you know much more about what is being sent over the network, and you can guarantee the maths will be deterministic, so I felt I wouldn't need to worry about latency, prediction, transform or anything really, so long as I stay inside the HPC# or Havok API.

Thanks

 

Who is responsible for future development of Unity Physics? Is there currently a team behind it?

From keynote I got impression that Havok developers were in charge but when you read the blog post, it makes it sound like it was internal Unity development. What is the reality here?

I'm asking this so one can set realistic expectations on how quickly it will evolve from experimental thing into something that will be production ready.

 

Out of preview with what features? I don't expect cloth or joints, but would expect strong Unity networking support out of the box and strong mesh decomposition tools for collider performance, nothing exotic - just enough capability.

 

Joints are already there

 

I assume you are referring to the line

Assert.IsTrue(hit.Fraction <= MaxFraction);

in Collector.cs. If I'm being honest it was because a test hit the case where hit.Fraction == MaxFraction == 0 and asserted when it shouldn't! Thanks for highlighting the inconsistency.

 

I haven't specifically used v-hacd myself, however I would highlight that you can have a compound collider. An example setup in the editor would be the Compound Dynamic Monkey in demo 2a2, where the Physics Body component is on the root object and there are a number of Physics Shape components on the children.

 

I see, a classic compound approach. But the problem is it's rather difficult for my limited resources to be handling the generation, so I am submitting my request for built in decomposition tooling

If I am not mistaken @yant has a HPC# codebase for it, so I was hoping it would be for HPC# physics and havok as well as Physx.

 

Getting V-HACD for this would be great, for the same reasons that hippo mentioned

 

Is there a easy/quick way to make the UnityPhysics (or the whole SimulationGroup) run on FixedUpdate right now? I know it'll be fixedUpdate by default in the future but I just wanna see if this fixes stability isues: https://forum.unity.com/threads/dot...on-other-dynamic-objects.646939/#post-4336603

...and it would definitely make the samples more useable too. Right now character/vehicle samples are in super fast-forward because my framerate is high. It would be a good thing to inform people that things aren't supposed to be like this before they pass judgement

 

I think VHACD plugin for Blender would be good inpiration for this (nevermind the UE4 part of the video):

 

Is there any plan on getting Unity Physics on github btw? It would help people who want to do custom forks. Who knows what kind of development that could encourage

 

Hmm, I know we've turned on vsync in the project Quality settings as a quick workaround:

edit: actually that probably won't help you with your high framerate

 

I would like to know:

• Will separately support 2D physics?
  
• Will it be possible to use a part of physics, for example, only AABB or 2D (for increase speed)
  
• There are some approximate terms of determinism(without rollback). For example in the next six months?

 

It is stated that the new Unity.Physics supports time rewinding by way of setting the movement components of objects to their historical values. (i.e. the simulation can step from any initial state, and the initial state is determined by your current component values) Given this, is there a mechanism to simulate multiple rewound states concurrently? Say you'd like to simulate a player's movement on a server against their local view on a client; on the server, you would have a different initial state for every player for every player (duplication intended) due to the varying latencies. It appears to me that to evaluate various initial states on the same server tick, you would either have to have a separate simulation per player entirely, OR step the simulation sequentially per-player, resetting the positions before processing each player. Is this the case, or is it possible to run identical-logic steps with different initial states in parallel?

edit: oh the pool example is pretty interesting...what's the cost of cloning a physics world?

 

What is the plan for particle system physics?

What is the plan for Physx job based api's? Are the current raycasting api's going to be deprecated at some point?

 

okay this works:

Spoiler: PhysicsRunner.cs

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using Unity.Entities;
4. using Unity.Physics.Systems;
5. using UnityEngine;
6.  
7. public class PhysicsRunner : MonoBehaviour
8. {
9.     private IEnumerable<ComponentSystemBase> simSystems;
10.  
11.     void Start()
12.     {
13.         World.Active.GetOrCreateManager<SimulationSystemGroup>().Enabled = false;
14.         simSystems = World.Active.GetOrCreateManager<SimulationSystemGroup>().Systems;
15.     }
16.  
17.     void FixedUpdate()
18.     {
19.         foreach(var sys in simSystems)
20.         {
21.             sys.Update();
22.         }
23.     }
24. }

put that monobehaviour on a gameobject in your scene and it'll take care of simulating everything on FixedUpdate. Unfortunately it does not solve rigidbody stack stability issues completely

Also, performance seems suspicious (stack of 300 cubes brings my framerate to its knees, even when not using FixedUpdate), but I'll blame the early experimental status of the package for that

 

I think is worth attach relative direct video links to Unity at GDC Keynote 2019 talks.

Data-Oriented Technology Stack

DOT and Megacity

PhysX Unity Physics and Havok

According to talk, Havok is coming around summer 2019. Probably more like toward Q3.

Edit:
Fixed timeline.

 

What are the limits of the convex collider? (255 tris, something else?)

 

I am guessing that the stack stability issues are perhaps an inevitable downside of having a "stateless/deterministic" physics engine. It would make sense afterall. If you make it a rule that you can't preserve information from frame-to-frame, then you can't track how much your rigidbody has drifted and you can't try to correct it.

I definitely see the benefits of a stateless engine for networked games, and I'm glad Unity made this decision, but I have some questions:

• Does this mean that the only solution for devs working with DOTS projects and who want stable rigidbody stacks would be to pay for Havok?
• Could we expect a "non-deterministic" option for UnityPhysics in the future? (for improved stability/quality/performance). Basically just a toggle that enables Baumgarte Stabilization / Contact caching / etc. Time 0:00 to 0:28 is with contact caching, 0:30 to 0:45 is without

 

I haven't checked, but I would expect to be int. There is no reason these days, to limit into 256 tris, if someone wants to use more.

 

I know its too early to judge, but some people seem to be hoping for Havok to be available at a cost that seems incredibly unrealistic to me. Perhaps Havok will make some adjustment to their business model when the Unity integration is available, but its clearly spoken of as an integration, I really doubt it will become the standard Unity physics without additional cost, and Havok will rightly want to retain revenue streams and premiums. Thats part of the reason why Unity Physics is its own thing, and Unity Physics is the only thing I expect to get for my Unity subscription fee.

 

Will Unity Physics provide Job/Burst friendly collision checking API without simulation? like ray/sphere/capsule/box collision. I wrote my own collision methods using Unity.Mathematics, but if Unity provides it officially, I'll replace it for robustness and API stability.

 

I suggest watch third video I posted earlier, to get some idea, where Unity is heading with physics.