Official Unity Physics Discussion

I confess I was expecting the physics API to be fully ECS because, it's only for ECS/DOTS. That's the rationale anyway. Is it slow because it isn't?

(edit: it is clarified below, so it is fully dots based)

 

It's quite difficult to do Physics in pure ECS, especially Unity's ECS where adding and removing entities brings the whole system to a halt. Physics just requires too much temporary data and benefits from using its own internal data structures that it can generate once and query multiple times much more cache-efficiently. I still believe that the internal state should be all wrapped up by a couple of ECS components (one for collision, one for dynamics, and maybe a couple for simulation parameters).

Now I haven't actually tested this and profiled it yet, but digging through the code, I can definitely see causes of performance issues. The job dependency management raises quite a few flags. There's Complete() calls scattered everywhere, often with comments about how they should be unnecessary. There's also a few places in the code where a function will receive an inputDeps as an argument and potentially return an empty JobHandle. I'm pretty sure that's why they are completing jobs they don't have to complete.

Also in personal experience I have never had as good of performance with a BVH for broadphase compared to other techniques when I have had direct control over memory layout. For individual queries the BVH was sometimes faster, but when batching queries I've always had better luck using the same algorithms as general collision detection. Then again, the developers have more experience than me and their BVH might have a few tricks buried in the code that make it fast. I'm just speculating as I haven't dug into it too deeply.

Edit: I did some investigation today and it seems there is one job in particular that is causing all the performance issues that I have encountered. Narrowphase.ProcessBodyPairsJob seems to struggle with several objects interacting with a concave mesh collider. I think all objects that interact with that collider are forced onto the same thread, because most of the time there is only one thread that is taking up most of the frame and it is that job. Occasionally I can get a second thread to have a substantial impact but overall it is a single-threaded process I can get to spike to over 100 ms.

 

So change the arrow of time and the components will revert to a previous time state from changes pushed by the existing systems?

 

I wouldn't believe so. They have no chance to know where the energy gone after a cube has fallen to revert it

 

You probably need to have a system that saves all the inputs if you want lockstep. If you rejoin a game you can brute-force by just replaying the sim at increased speed.

 

Will there be things like the destruction system of the newly announced chaos physics engine of unreal engine?

 

There are few things to consider here:

- You'd want states for destruction (of course you can brute force everything if you only need smaller scale things)
- Unity Physics isn't stable on 3+ objects stacked together which will immediately happen when you destruct objects

That being said I'd love to see destruction finally included on stock Unity (it's been included in Unreal for as long as I can remember).

 

Hi, sorry I'm joining this thread a bit late. We've been playing with Unity Physics and we're getting great results resetting the state of entities and re-simulating. So far it's been really nice, good work! I want to ask about about performance, mainly regarding how Unity Physics uses the job system.

• When we need to re-simulate several frames at once we call Update() on
  World.Active.GetOrCreateManager<SimulationSystemGroup>().Systems (like is talked about in this thread). However this takes time for a complicated scene. What would we need to do in order to have several simulations run on the job system without stalling the main thread so that the result is ready next frame?
• Looking deeper I noticed that most of the main thread syncing is needed by a few calls to Complete() from StepPhysicsWorld. One in particular that caught my eye is we're spending a lot of time in the CreateJoints job, even though the number of joints hasn't changed. Do you think I (or Unity) could change this so that it only runs the CreateJobs job if the number of joints has changed?

Thanks for your help, let me know if you need more details.

 

I doubt we'll see anything on that scale. Chaos from what I saw is using voxel based collision detection (their showcase talk showed they have voxel collision instead of mesh collision), which is part of how they get it to run so fast with hundreds of thousands of pieces of debris. I don't know any internal details but voxel sims are usually GPU accelerated as they are super good at parallelizing compared with normal physics solvers. It's also not just for their destruction, it's going to be replacing physX entirely for unreal. I'd love to see voxel collision from unity in future, since it scales way better than GJK (the algorithm for convex mesh collision) to complex scenes. Plus gpu acceleration is awesome X3

 

It seems like there's a single package for Unity Physics, but I can't get it working - the import ends up with the following errors:

Spoiler: Console

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Collision\Queries\Overlap.cs(146,21): error CS1666: You cannot use fixed size buffers contained in unfixed expressions. Try using the fixed statement.

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(125,54): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(109,53): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(90,53): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(78,51): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(67,47): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(60,51): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(41,51): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(31,42): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(21,63): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\PhysicsWorldExtensions.cs(10,50): error CS8339: The parameter modifier 'in' cannot be used after the modifier 'this'

Does anyone face the same issue? Using Unity 2019.2.0a8, 2019.2.a9


Edit:
Fixed by removing Incremental Compiler package

 

What features of havok physics engine will be integrated in unity ? I'm concerned about this because many of features of physx engine are missing till date in unity ,i hope that's not the case

 

Hi All
Sorry for my ignorance but I am starting with DOTS and I am devloping with VR projects for Oculus and HTC Vive. Since that all these topics are new for me. Is Unity Physics package (and Havok) VR Ready.?
Thanks for your time
Alejandro

 

I suggest watch GDC PhysX Unity Physics and Havok part of iscussion (3rd vid, few min)

As for ECS in general, consider that all is "NOT for production ready". Meaning, features may simply don't exists yet, or be not fully functional.

 

Just to avoid confusion: there is no PhysX on keynote talk, only new Unity Physics package (ECS) and Havok.

 

Hi Antypodish, First thanks to answer me. On the other hand I know that DOTS be in preview but I am trying to learn more about this topics.
Best Regards
Alejandro

 

Yep, Joachim Ante just mentions Unity Physics as preview package, at the end of physics vid section, but not addressing it as PhysX.

I may educate myself here, but how different is mentioned Unity Physics from PhysX? Is it complete new system, specifically designed for ECS, or is a derived form PhysX?

 

It's a new system

 

Thx

I just re-read first post.

 

,new 10 pics trunks, the performance is not good..

 

Yeah, many of demos have little optimization at the demo level. Performance in this demo is particularly bad as more bodies are added. Each vehicle and wheel calculation is handled sequentially and the whole thing need jobified.

 

Some of the demos don't really work either, as I believe they are waiting on somethings for a new version. Either of Burst or Physics.

 

This is definitely a work in progress, but I love the direction that this is headed.
I would personally prioritize performance over determinism, but this seems like a sacred cow to many people so I can see why you've put it up as a pillar.
I was kind of surprised to see a Gauss-Seidel style monolithic solver in there. But hey - you have to start somewhere.
I would say that the best way to make this successful would be to open source it on Github and to try to persuade the many great physics programmers to optimize and extend it.

You might want different branches with different solvers, different ways of dealing with degrees of freedom (generalized coordinates vs rigid bodies) and different broad phase collision techniques as there is no one optimal solution for all games.

 

Determinism is important for networking. Performance with useless falling boxes is something any physic engine can do and is totally useless for networked games.

 

It can't or it would have worse performances than a standard implementation ?

 

Quick question:
The slogan is "performance by default" but it seems there are quite a few things that you have to keep in mind when designing code in a data oriented way.

Will there be (more) static analysis tools later on that make it so new users will not fall into the same performance traps as it seems is happening here?

Semantics...

 

Probably the fact, that developing in ECS paradigm, is already massive performance improvement, in comparison to OOP. And that is, without even putting pressure on very atomic level, to gain further performance.

 

Anyone else getting this? Entity preview.30 seem out of sync with Unity Physics preview.1?
Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\Extensions\World\ComponentExtensions.cs(12,35): error CS0311: The type 'Unity.Entities.EntityManager' cannot be used as type parameter 'T' in the generic type or method 'World.GetOrCreateSystem<T>()'. There is no implicit reference conversion from 'Unity.Entities.EntityManager' to 'Unity.Entities.ComponentSystemBase'.

 

There are some breaking API renames. If you bring physics in manually you can fix it yourself.

 

@Joachim_Ante Thanks for clarification.

 

I am also stuck with Unity Physics 0.0.1 not up to date with Entities preview.30 latest API change.

 

The New Unity Physics is not compatible with the new ECS version and it's API deprications.

 

I've noticed the Chaos destruction system from Unreal Engine.

@Joachim_Ante
I think it would be very very easy to extend the functionality of Unity's physics engine to incorporate realistic fracturing.
All it would need is super-simple voxel-based Rigidbodies, Voronoi decomposition, and VFX Graph smoke/debris. The underlying technology with burst compiler/VFX graph is already there.

 

I'm so excited about how ECS will work to do the meta-physics(magic) system I am developing. Mine is based on Laws (Systems), Properties (Components), and Things(Entities). I have wanted to do this for a decade, but it wasn't possible at an acceptable fidelity until ECS came along.

Does anyone know if effectors are on the raodmap or will we need to implement them? An effector shouldn't be too hard. It would need a system to check the colliders and apply the forces to the components, right?

 

I really wish unity people make this an feature in unity because it can be integrated in unity right now in the development phase of unity physics, otherwise over time unreal engine will once again be ahead of the curve than unity

 

I think Unity Physics and Unreal Chaos serve completely different purpose. Since Unity Physics is Open source, if anyone will think similar feature can be feasible as Chaos does, surely someone will do it. Even as an asset. But I would rather want Unity, to focus on their main goal and performance with determinism, rather implementing voxelise destruction mechanics.

 

I think your misinterpreting what Chaos is. There's no realtime fracture in it. The big improvement is it's GPU based. It's voxel based because that maps much better onto GPU hardware. Their fracture system is just very well implemented graph based structural representation basically. Rigidbodies are enabled/swapped when they lose connection to the ground. You can't really extend that onto unity physics sadly. It would have to be part of the design from the ground up. =<

 

I understand general differences, therefore, I know discussed two physics engines serves different purposes. Whats does not stops anyone, as I said, to build up similar system if feasible. Weather is feasible, or not, is not me to judge and is different story, as I have no deep expertise in this area.

Edit:
What I am not really fan of, regarding Chaos approach, It looks like destruction system can have separate hanging voxels, as left overs after destruction. Unless explicitly hit that "button" to allow collapse floating part of structure. So in the result, destruction system can look weird. Just like cutting tree on the bottom in minecraft, and rest of tree will still float.

Not sure if chaos engine can detect such separate floating voxels. At least this is not clear from the Unreal demo.

 

In order to catch up with the competition, Unity Technologies is probably going to provide a destruction system eventually. It might take a few years, but they'll get there.

Being able to destroy buildings in MegaCity would be quite a show. Who knows, perhaps that's the next big thing the demo team is working on.

 

Every one can implement something similar without any problems in current and DOTS approach. This things is not “built-in” required, cause Unity should spent time to more general and core features which helps achieve determinism and gives all required for building your own extensions.
BTW implementation on graph from some guy:
https://twitter.com/elasticsea/status/1113877870399709186?s=21

 

Worth noting that afaik Unreal's Chaos physics also relies on Nvidia Blast for the fracturing (it's just general purpose fracuring framework, Blast has no physics simulation at all on itself so you can couple it with any physics engine you like).

So technically, one could couple Unity Physics with Blast as well but I could see unstable stacking being a huge issue on Unity Physics if you do destruction with it.

 

Unreal Chaos don't stack either really. Their colliders seams just to be general approximations and far from being "ideal". At least, from what I see.

I love that showcase.

 

Their collision shapes and stacking are totally different things.

What I mean by stacking now is having multiple physics bodies stacked either on top of each other or touching sideways. They clearly do it on Chaos like seen at this timestamp but it's also not super stable there either right now (you can see some bodies being too alive on the piles which is kinda similar issue with Unity Physics right now.

 

I was watching exactly same time stamp previously multiple times. I see they collide between each other, but also, I can see meshes clip through floor and through some other meshes. But to notice, need put vid on slow motion
Not that this is much important, for destruction game play. It looks fun however.

 

That looks to me like not enough iterations, not a collision shape issue. They're probably only using 1 iteration for physics so they can have as much running as possible. =3

 

The chaos thing is just normally what AAA developers usually do, there is no magic, nothing special. Some of it is baked. Some of it is replaced with spawned debris. It is several solutions and I argue the physics aspect is the weakest part of the chaos demo.

It's engine virtue signalling instead of something hands-on that benefits a broad amount of developers like awesome networking, realtime gi, strong rollback physics, dots etc - unity is doing the real solutions. Only surprise for me is the 3 year plan. I would expect replacing the entire engine to be longer than 3 years!

And that is why I am with Unity.