Search Unity

Unity Physics Discussion

Discussion in 'Data Oriented Technology Stack' started by smcclelland, Mar 18, 2019.

  1. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,346
    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)
     
    Last edited: Apr 6, 2019
    Kender likes this.
  2. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    371
    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.
     
    Last edited: Mar 23, 2019
  3. The-Exceptional-Bruce

    The-Exceptional-Bruce

    Joined:
    May 10, 2015
    Posts:
    27
    So change the arrow of time and the components will revert to a previous time state from changes pushed by the existing systems?
     
  4. Kender

    Kender

    Joined:
    Nov 16, 2012
    Posts:
    144
    I wouldn't believe so. They have no chance to know where the energy gone after a cube has fallen to revert it
     
  5. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    82
    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.
     
  6. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    84
    Will there be things like the destruction system of the newly announced chaos physics engine of unreal engine?:)
     
  7. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,077
    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).
     
    Alverik and Jick87 like this.
  8. Brian-FJ

    Brian-FJ

    Joined:
    Apr 23, 2013
    Posts:
    9
    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.
     
    Arkade, Squize, Piefayth and 2 others like this.
  9. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,635
    We are aware of all the sync points, which make it run slower. We are planning to get all of them cleared out soon.
     
    Arkade, drhodor, Brian-FJ and 9 others like this.
  10. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    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
     
    Arkade, Alverik, Jick87 and 1 other person like this.
  11. Kender

    Kender

    Joined:
    Nov 16, 2012
    Posts:
    144
    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:
    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
     
    Last edited: Mar 31, 2019
  12. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    84
    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
     
    Alverik likes this.
  13. castana1962

    castana1962

    Joined:
    Apr 10, 2013
    Posts:
    362
    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
     
  14. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,189
    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.
     
    Last edited: Apr 2, 2019
    steveeHavok, Alverik and castana1962 like this.
  15. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,077
    Just to avoid confusion: there is no PhysX on keynote talk, only new Unity Physics package (ECS) and Havok.
     
    Alverik and Antypodish like this.
  16. castana1962

    castana1962

    Joined:
    Apr 10, 2013
    Posts:
    362
    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
     
    Antypodish likes this.
  17. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,189
    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?
     
    Alverik likes this.
  18. Kender

    Kender

    Joined:
    Nov 16, 2012
    Posts:
    144
    It's a new system
     
    Alverik and Antypodish like this.
  19. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,189
    Thx

    I just re-read first post.

     
  20. dreamerflyer

    dreamerflyer

    Joined:
    Jun 11, 2011
    Posts:
    901
    physics.png ,new 10 pics trunks, the performance is not good..
     
    Cynicat and steveeHavok like this.
  21. steveeHavok

    steveeHavok

    Joined:
    Mar 19, 2019
    Posts:
    107
    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.
     
    hippocoder likes this.
  22. Soaryn

    Soaryn

    Joined:
    Apr 17, 2015
    Posts:
    198
    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.
     
  23. DavidSWu

    DavidSWu

    Joined:
    Jun 20, 2016
    Posts:
    114
    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.
     
    Last edited: Apr 4, 2019
    Arkade, Alverik, GliderGuy and 8 others like this.
  24. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    82
    Determinism is important for networking. Performance with useless falling boxes is something any physic engine can do and is totally useless for networked games.
     
  25. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,635
    What does Fully ECS mean? All the data is on components in a tightly packed way. Shared resources like collision meshes are in immutable blob data.

    Collision detection is inherently random access and going through entity chunk lookups is not the optimal way to do that.
    Keeping a copy of the physics simulation state in native arrays is useful for that. The important part is that it's stateless in terms of all data that gets changed gets copied back and forth between the tighly picked single array and the chunk based layout.

    Systems keeping caches / duplicating the data is not "wrong"... It's the right way to do things depending on how the data is accessed.

    Remember boid simulation code. Copying the positions of all boids into a hashmap makes things faster. How would you find nearby objects in there without a copy of the data maintained by one of the systems?

    A BVH tree can't be represented with Entity / component / Chunks.

    ECS is quite useful in this setup of course. Copying the data from jobs. Copying only what has changed (Not implemented yet) and efficiently copying that data as opposed to a cloud of function calls to set some parameters.

    And lastly the way the caches are designed is that they can be deterministically be recreated, to ensure deterministic simulation and rollback.
     
  26. dzamani

    dzamani

    Joined:
    Feb 25, 2014
    Posts:
    85
    It can't or it would have worse performances than a standard implementation ?
     
  27. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    787
    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...
     
    Peter77 likes this.
  28. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,189
    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.
     
  29. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,635
    In theory you could do it by having an Entity ref. But that goes through two indirections to and a search for the component data. An array is clearly the better choice for perf here.

    Every data representation makes tradeoffs. ECS is optimized for table processing. Its the 90% case of game code.

    The approach also lends itself very well to keeping other caches in systems up to date. Performance by default doesn't mean mind blindly always doing only one thing. It means that the default is already a good first level approximation of optimal.
    It is straightforward to evolve the something optimal measured against the theoretical limit.
     
    Alverik, Kender, hippocoder and 6 others like this.
  30. The-Exceptional-Bruce

    The-Exceptional-Bruce

    Joined:
    May 10, 2015
    Posts:
    27
    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'.
     
  31. recursive

    recursive

    Joined:
    Jul 12, 2012
    Posts:
    583
    There are some breaking API renames. If you bring physics in manually you can fix it yourself.
     
    The-Exceptional-Bruce likes this.
  32. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,346
  33. Init33

    Init33

    Joined:
    Aug 30, 2017
    Posts:
    56
    I am also stuck with Unity Physics 0.0.1 not up to date with Entities preview.30 latest API change.
     
  34. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,635
    We recommend not upgrading to Unity entities preview 30 until we resolve it.
     
  35. davidv_unity

    davidv_unity

    Unity Technologies

    Joined:
    Nov 14, 2018
    Posts:
    14
    We released a new preview version of Entities (preview.30) which introduces breaking API changes and is therefore not compatible with the already released Unity.Physics 0.0.1 preview package. Therefore you can not mix Unity.Physics preview version 0.0.1 with Entities preview version 30.
    We will be releasing a new version of the Unity.Physics package next week when all features are completed (which will of course be compatible with Entities preview.30).

    Most importantly we realised that this caused some strong pain points and we are very sorry for that. To address this we decided that whenever we will release a package that requires breaking api changes, we will also release a compatible version of all our packages depending on it at the same time.
     
    Arkade, echeg, Bas-Smit and 9 others like this.
  36. Opeth001

    Opeth001

    Joined:
    Jan 28, 2017
    Posts:
    231
    The New Unity Physics is not compatible with the new ECS version and it's API deprications.
     
  37. Mr-Mechanical

    Mr-Mechanical

    Joined:
    May 31, 2015
    Posts:
    191
    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.
     
    Last edited: Apr 6, 2019
    keeponshading and Alverik like this.
  38. The-Exceptional-Bruce

    The-Exceptional-Bruce

    Joined:
    May 10, 2015
    Posts:
    27
    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?
     
    Last edited: Apr 6, 2019
  39. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    84
    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 :(
     
    Alverik, Kender, Cynicat and 2 others like this.
  40. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,189
    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.
     
    Kender and dzamani like this.
  41. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    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. =<
     
    keeponshading and Alverik like this.
  42. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,189
    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.
     
    Last edited: Apr 7, 2019
    Alverik likes this.
  43. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    3,899
    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. :)
     
    Last edited: Apr 7, 2019
  44. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    1,367
    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
     
    Last edited: Apr 7, 2019
    DMeville, Micz84 and Antypodish like this.
  45. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,077
    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.
     
  46. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,189
    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.
     
  47. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,077
    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.
     
    Last edited: Apr 7, 2019
    Alverik and Cynicat like this.
  48. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    5,189
    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.
     
    Alverik likes this.
  49. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    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
     
  50. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,346
    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.