Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Future of Unity Physics

Discussion in 'Physics for ECS' started by Iron-Warrior, Nov 30, 2021.

  1. Iron-Warrior

    Iron-Warrior

    Joined:
    Nov 3, 2009
    Posts:
    838
    Looking through all of the demos available in the EntityComponentSystemSamples physics demos, Unity Physics seems like an ambitious and well put together setup, especially for use cases like networking where consistency between clients is important. Looking at the package manager the last update was done in January about 10 months ago, making me wonder if there is something like a roadmap showing what the future plans are for it. Right now it seems to be bound to DOTS-land which has a somewhat muddled future (discussed in very large detail elsewhere on this forum).

    Are there plans to continue developing it and have future releases? Something I thought would make it much more valuable to the community as a whole would be a full game object/MB wrapper for the engine (similar to how Unity itself is essentially wrapping PhysX), opening up the possibility for developers working with MB-only projects to make use of it (especially with MB based networking packages like Fusion upcoming, where stateless physics would fit in nicely). My project is currently using PhysX with networking, which is workable with some hacks here and there, but a lack of source access + PhysX being stateful adds some limits. Looking to explore other networking ready engines for future projects.

    Not looking for any specific asks here, but Unity Physics seems like a really strong foundation, so hopefully there are plans for the future.

    EDIT: As an aside, Unity Physics itself deterministic, a property that is very useful for networking. I wrote a topic here about determinism in Unity and its applications for anyone interested in how Unity Physics relates to it.
     
    Last edited: Jan 13, 2022
  2. Iron-Warrior

    Iron-Warrior

    Joined:
    Nov 3, 2009
    Posts:
    838
    Had fun and made a Game Object/MB wrapper for Unity Physics.

    Ultra proof of concept, just has boxes/simple fixed timestep, nothing fancy. Was a bit finnicky to initially get set up, but would be pretty straightforward to expand on...but whether it's worthwhile or not I suppose depends where Unity is heading with the package.

    (aside: Unity Physics really badly needs a new name to distinguish it from PhysX/Box2D, since if you search for anything with "Unity Physics" it's just gonna be the legacy 3D/2D systems.)
     
    iDerp69, Saniell, SenseEater and 3 others like this.
  3. alex_bendover

    alex_bendover

    Joined:
    Sep 7, 2018
    Posts:
    1
    Come on Unity, give us a bone.
     
  4. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    I think this would be great to have. Network-related issues aren't the only problem with the old PhysX integration; there's also all of the limitations I've described here:
    https://forum.unity.com/threads/dot...i-had-in-monobehaviour-physics-physx.1057004/

    Having the same physics engine for Monobehaviour and DOTS would have all these benefits:
    • Less of a learning curve when people transition to DOTS
    • Monobehaviour projects can use the much more versatile/powerful/performant physics query APIs of DOTS physics
    • More flexibility for doing queries in jobs in a monobehaviour project (the current batch raycast APIs are pretty limited). Physics queries tend to represent a big chunk of the frame time in a lot of projects. This would be an obvious performance win for monobehaviour, and a way to make more of the community benefit from DOTS efforts
    • For Unity, it would be less different techs to maintain
    Even just the way (stateful) collision events work in DOTS physics is much better than in monobehaviour physics. Mono physics coll events are limited to being only accessible via a callback, which makes it tedious in cases where you need to "find the best hit" among all hits this frame (you have to store tmp data in the class, reset it every fixedUpdate, etc....). In DOTS physics, the events are naturally given to you in an array, which makes this easier
     
    Last edited: Jan 11, 2022
    iDerp69, Kirsche, bb8_1 and 3 others like this.
  5. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I agree, if we are going with hybrid solutions and want people to be able to go to asset store and buy one solution that works even if people aren't using ECS/Dots then that would be a win for Unity, asset store and devs.

    The existing Physics and Physics2D are actually great as they are, and not conflicting with DOTS Physics because Unity's DOTS Physics offer very good use cases those do not and vice-versa.
     
  6. koirat

    koirat

    Joined:
    Jul 7, 2012
    Posts:
    2,068
    If I may ask, I could not find this info anywhere, but does Unity Physics supports Continuous Collision Detection ?
     
    phreezie likes this.
  7. John_Leorid

    John_Leorid

    Joined:
    Nov 5, 2012
    Posts:
    646
    When Unreal started switching to their own physics engine instead of PhysX, the performance went down with every update (source: someone I follow on twitter who did benchmarks and works for Nvidia, but .. I don't think he lied in his posts because it's not a marketing channel).
    That's because there is a company focused on providing a realtime physics engine and they make money, because their product is good. They improve it constantly with a dedicated team maintaining the codebase and squeezing out every bit of performance.

    The unity physics engine was written by three guys (as far as I can tell from the forum posts, I think one of them even said that, back when they released the first preview version). Even with the help of the havoc team and even when the team grows a lot in the future, they will lack years long experience with their system and when adding things like cloth, softbodies or other features, it might lose stability and performance.

    I wrote a physics engine for a very special case (physics in buildings / stress calculations for destructible buildings).
    Not an expert at those things at all, but I know something about these things - they are damn complicated.

    IDK if it's a good idea to switch with something as essential as physics to a custom, non-battle-tested solution. The benefits are obvious, while the risk isn't.

    Just my two cents.
     
  8. Iron-Warrior

    Iron-Warrior

    Joined:
    Nov 3, 2009
    Posts:
    838
    I definitely agree with the above, in that the main drawbacks to U Physics is that it is new and untested...and like the topic of this thread says, it's not certain what its future is. I don't personally mind a limited feature set, since for my purposes it's the engine being designed for stateless simulation that is the big appeal, along with being source available. As well, some parts of the API can just be made to work more smoothly than Unity's PhysX one, like iteration over collision info etc.

    I don't think I'd be comfortable starting a new project with Unity Physics without knowing at least where it's heading, and whether it's being actively worked on.