Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

[Sources Available] Physics in Pure ECS

Discussion in 'Data Oriented Technology Stack' started by PhilSA, May 16, 2018.

  1. TigerFudo

    TigerFudo

    Joined:
    Nov 30, 2012
    Posts:
    19
    GPU phyics's performance is awesome,but maybe it is not perfect as a real physics solution. For those computing results on gpu and render directly,such as effects, it works like a framerate turbo.But if you wanna fetch compute result from GPU(for some ai logic on cpu), you should get the huge performance loss. This's maybe the main reason that why Nvidia's PhysX is not full based on GPU
     
  2. RisingMos

    RisingMos

    Joined:
    Aug 28, 2015
    Posts:
    17
    The GPU PhysX in version 3.4 is actually full GPU. They attempted this over the years and they never reached full GPU until 3.4.

    Regarding fetching, it doesn't have to occur in every frame. You can define a specific delta time that is bigger than the simulation delta time. Also, the GPU system can be implemented in a such a way to have some kind of hook to custom GPU calls if needed.
     
    Last edited: Jul 3, 2018
  3. Razmot

    Razmot

    Joined:
    Apr 27, 2013
    Posts:
    266
  4. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,149
  5. dreamerflyer

    dreamerflyer

    Joined:
    Jun 11, 2011
    Posts:
    904
  6. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    4,219
  7. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,194
  8. illinar

    illinar

    Joined:
    Apr 6, 2011
    Posts:
    621
    Is anyone making a deterministic ECS physics engine? I just started making one using only ints and precomputed int values (sin, cos, sqrt), but I want to know when the floating point determinism is estimated to arrive to see if it's worth restricting myself to only integers.

    It seems like your pure ECS CPU physics engines will be deterministic when Burst will make computations deterministic if you make sure that the "infrastructure" is deterministic already.
     
    Last edited: Jul 9, 2018
  9. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,844
    Bepu looks promising but as *far as I know* Unity said they have expressed interest in decomposing Physx to ECS at some indeterminable future. I would guess that to be a future far far away a long time to come though.

    Keeping an eye on this thread because its absolutely bloody brilliant.
     
  10. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,194
    Having followed Unity staff comments on the topic, I'd say there are two things that will/might happen regarding built-in physics and these new systems: Unity's PhysX integration will get more things exposed to the job system. Atm we only got RaycastCommand but I think they already mentioned that 2018.3 is exposing more queries to jobs. We also know that Unity plans exposing PhysX Immediate Mode which I'd expect them to jobify at some point too (it would make sense as it's totally separate system that runs physx solvers without physics scene so you don't have to care about race conditions with the scene itself).

    In addition to PhysX side, Unity has expressed they want to make simplified physics solver for ECS. By the looks of the comments on this, it seems this one hasn't even left the drawing board yet but it's pretty safe to assume at this point that whenever they do it, it will not be PhysX replacement for years to come nor are they (at least initially) targeting it as such.
     
    optimise and hippocoder like this.
  11. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,194
    They mentioned floating point determinism plans again at Unite Berlin:

    but there's no ETA for this afaik. If I had to guess, I'd expect first previews next year earliest.
     
    hippocoder likes this.
  12. illinar

    illinar

    Joined:
    Apr 6, 2011
    Posts:
    621
    Yes, thanks, @rizu. If it is indeed early next year, then I can focus on the rest of the project for now and by that time some people will probably already make some custom ECS physics engines that will probably be deterministic.

    I hope I will get hold of some devs that can give some ETA.

    Got a thread, no responses yet: https://forum.unity.com/threads/eta-of-floating-point-determinism.539534/
     
  13. Razmot

    Razmot

    Joined:
    Apr 27, 2013
    Posts:
    266
    It's so cool that so much of the ECS is open, reading the source of MeshInstanceRendererSystem and MeshFrustumCullingSystem has been an epiphany for me :

    the culling marks entities with the empty struct MeshCulledComponent , and the rendering filters out all entities which have this MeshCulledComponent component. So simple and neat.

    On the subject of physics, and the current lack of double precision in unity mathematics / burst :

    You could implement your own high precision Component with 2 floats { float3 High; float3 Low; } and work mostly on the high part, and only when needed on the low part. Could even be float High and half Low or whatever, and you would still benefit from burst.

    There are some research papers about that linked here https://stackoverflow.com/questions/6769881/emulate-double-using-2-floats, those are GPU oriented, which actually makes the idea even more interesting ! Unity may add doubles to unity mathematics, but nvidia and others won't manufacture double precision gpus any time soon !
     
  14. 00jknight

    00jknight

    Joined:
    Mar 28, 2014
    Posts:
    25
  15. uromastix87

    uromastix87

    Joined:
    Apr 9, 2013
    Posts:
    2
    Why not try Newton Dynamics? It's a C++ multithreaded physics engine which already has a plugin for Unity, but it's written for MonoBehaviour.

    I tried my hand at Jobifying. I thought I could start with the transform updates, but I couldn't process the data coming from Newton Dynamics since it wasn't blittable. I thought about using ISharedComponentData, but I couldn't get that to work either.

    It's a great engine and the current plugin works well. I'd love it for ECS though. If someone has some input that would be great.

    Plugin:
    https://github.com/svenberra/NewtonUnityPlugin

    Engine:
    https://github.com/MADEAPPS/newton-dynamics
     
  16. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,149
    That's the plan, yes. Once the project reaches a point where I feel the basic foundation is properly laid out, I'll make it available publicly

    I have no doubt this is a solid physics engine, but I still feel like a physics engine implemented directly in ECS is what would be the ideal thing if done well, whether it's for performance, readability or extensibility. It's also something I've personally been wanting to learn for a long time
     
    uromastix87, psuong and hippocoder like this.
  17. Kender

    Kender

    Joined:
    Nov 16, 2012
    Posts:
    165
    Will it be possible to have custom collision rooms? For instance, my game will have multiple rooms, that have inner collisions only. It would've been wasteful to check collisions between any rooms. You know, like if the rooms were in non-collidable layers
     
  18. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,149
    Multiple physics worlds will take care of that
     
  19. Kender

    Kender

    Joined:
    Nov 16, 2012
    Posts:
    165
    I wonder if the cost of a hundred rooms, for instance, is too high. Many-many isolated chunks
     
  20. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,149
    Massive milestone reached today: I've got a working constraints solver!

    I spent the last month mostly on studying math/physics, and not really on implementation. I'm very serious about this physics engine and I want to make sure I'm using modern, proven techniques. So my research for an implementation of a proper constraints solver lead me to two possible approaches: Projected Gauss Seidel, and Sequential Impulses

    A constraints solver is a system used by physics engines to express every possible constraint (collision, friction, joints, translation/rotation limits, etc...) as a bunch of numbers in matrices, and then an algorithm solves the entire system of matrices in order to find a set of forces to apply to all rigidbodies in the scene that will satisfy all constraints simultaneously as much as possible. The implementation of these constraint solvers isn't that hard in retrospect, but the books and online resources on the subject are quite poor in my opinion, so I had to take some time to piece it all together (and re-familiarize myself with derivatives and Jacobians, which I never thought I'd actually be using one day).

    In the end, I went with Sequential Impulses because I felt that its implementation was more natural/obvious than Projected Gauss Seidel for the ECS, and some sources claim it's more versatile and easier to extend.

    So now with this addition, my physics engine is ready to support joints, friction, and large stable stacks of objects that don't jitter. Constraints solvers and Broadphase algorithms are known to be by far the most technically difficult parts to implement in a physics engine, and both are mostly behind me now (aside from optimizations). Things should be going more smoothly from now on!

    The stuff I'm planning to work on next in the short term is:
    • More broadphase optimization (I've got some fresh new ideas)
    • Add friction and bounce/restitution to my constraints solver
    • Add box colliders and capsule colliders
    • add the notion of inertia tensors, angular velocity and torque (already partially supported in constraints solver)
    • Support multiple contact points per manifold
    • rigidbody sleep mecanism
    • Editor-only debug tools/systems
    And then after that:
    • GJK and EPA for mesh colliders
    • Physics queries (raycasts, overlaps, etc...)
    • Joints
    • Collision events system
    • Collision layers & filtering
    • Cloth
    _______________________________________

    PS: My struggle with finding proper learning resources on the subject, and my experience with implementing this constraint solver have made me want to start writing a complete series of articles on physics engine development. I will most likely start doing this as part of the eventual documentation effort when I release this publicly
     
    Last edited: Jul 19, 2018
  21. NelsonHurst

    NelsonHurst

    Joined:
    Dec 4, 2014
    Posts:
    10
    Wow, this is interesting. Just out of Curiosity, are you planning on keeping the same API naming as the physics currently used in Unity? Just seems like it would an easier/faster transition if everyone is already familiar with the API.

    Hypothetically, the user could completely remove the existing Physics Package and simple use the ECS Physics. :)
     
  22. 00jknight

    00jknight

    Joined:
    Mar 28, 2014
    Posts:
    25
    Dayum dude. You seem to be straight up killing this. I was planning on doing this type of project, and have also spent months researching math for physics simulations, but my GPU physics solver still doesnt show the results I want to see.

    I'm super impressed.

    I think I can be of good help to you when it comes to API design, performance optimization and compute shader usage. I'm interested in helping you clean up the system and giving you feedback even before you open source it.

    Basically:

    I want in.
     
    Last edited: Jul 20, 2018
  23. Craptastic

    Craptastic

    Joined:
    Dec 15, 2016
    Posts:
    8
    Unity, hire this man. Good hell.
     
    Beatshapers and FROS7 like this.
  24. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    6,251
    This is super exciting. But need to wait :(
    I really hope, Unity don't work in parallel on same solution, as there may be battle between and would be shame, to have only one winner :p

    Great effort indeed.
     
  25. LazyGameDevZA

    LazyGameDevZA

    Joined:
    Nov 10, 2016
    Posts:
    82
    Untiy is definitely going to be working on their own implementation of a physics engine. I don't think there will be only one winner though since we'll be spoiled for choice on the physics implementation we want to use. As far as I know this also isn't a 2D physics system, so if Unity ports their physics over to ECS at least we'll gain access to that as well.
     
  26. one_one

    one_one

    Joined:
    May 20, 2013
    Posts:
    496
    Do you have a source for that?
     
  27. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,194
    This thread at least (wanting and definitely going to are two different things tho):
     
  28. srinath49

    srinath49

    Joined:
    Jun 3, 2013
    Posts:
    2
    This is an awesome thread and you are doing a great job @PhilSA.
    Any updates? This has been silent for 2 weeks now. I would hate to see this die out.
     
  29. gilley033

    gilley033

    Joined:
    Jul 10, 2012
    Posts:
    763
    Can you provide implementation details on your manual update of sub systems? Do you just have a physics system that is updated in the Player Loop, and then that system manually calls all other sub system? I assume the sub systems are still created using CreateManager?

    I am trying to port a custom physics engine (a lot less complex than the one you are designing, as its geared for just my game) to ECS, and I want to be able to manually update systems in a loop, multiple times in a row in some cases.

    For example, in my system I move all objects forward by a fixed time step, and then check for collision against objects that can impact their movement direction/position (for instance, walls). I resolve the collision (time of collision, exact position of the collision, etc.), and that naturally leaves time left for the object to move, since the collision happened before the expiration of the fixed time step. So I need to simulate that object's movement again for the remaining time, and go through this process again.

    The normal process of ECS systems is just to run once though, but I'd like to be able to run these sub systems in a loop (in the example above, for instance, until all entities are simulated for the full fixed time step). Have you done something like this? If so, how did you do it?

    I'd really appreciate any wisdom you can give! Thanks!!
     
  30. deus0

    deus0

    Joined:
    May 12, 2015
    Posts:
    17
    I love what you've done PhilSA! I can't wait to get my hands on that ecs physics code! I have implemented a procedural generation systems using unity's ecs, jobs and the hybrid rendering components, but couldn't find physics.
    So does anyone know of any small examples of physic systems written for unity's ecs or unity's older systems? I don't really want to use game objects as they won't scale as well for the sizes I want. I can't wait for this to be released :)
     
    Last edited: Sep 5, 2018
  31. Vacummus

    Vacummus

    Joined:
    Dec 18, 2013
    Posts:
    98
    I would love to read you articles/documentation on this.
     
  32. gilley033

    gilley033

    Joined:
    Jul 10, 2012
    Posts:
    763
    I agree, as someone who has searched for days on end trying to implement a rudimentary physics simulation (and not having a ton of luck), I think a series of articles on this topic would be invaluable. I would not focus too much on the collision detection aspect, unless you feel it necessary to make sense of the series as a whole, since it is not terribly difficult to find information on detection.
     
  33. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    6,251
    Providing project is still alive. Fingers crossed ;)
     
  34. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,149
    Allright everyone, something totally unpredictable :rolleyes: happened: it has become very difficult to find enough free time to work on this lately. I have been too busy and haven't touched this in several weeks

    I still plan on continuing this at my own rhythm later, but in the meantime, I will simply release the full source code in its unfinished state. The project works, though. Here it is:
    https://github.com/PhilSA/ECSPhysics

    Temporary doc is available on the github page

    Keep in mind I can answer questions if you have them, but I am not yet ready to go in full-blown project management mode for this
     
    Last edited: Sep 6, 2018
    Rewaken, optimise, FROS7 and 5 others like this.
  35. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    6,251
    I haven't checked yet, but so far, you are amazing for what you have done.

    Could you briefly highlight, what requires to be done / what is missing?
     
  36. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,149
    thanks! There is a TODO list on the github page
     
    Antypodish likes this.
  37. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    6,251
    Ah I see now, sorry for dumb question.
    I should have checked first.
     
  38. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    6,251
    I just post description here as an archive, if not an issue.

    ECSPhysics
    (Under Construction) A physics engine made with Unity ECS

    Made on Unity 2018.2.5f1

    Forum discussion: https://forum.unity.com/threads/physics-in-pure-ecs.531716/

    Overview
    • "TestScene" is the main test scene. Press play to see the physics simulation happen. Modify the parameters under the "Init" GameObject in the scene (The "PhysxBenchmark" scene is for comparing with Unity's built-in physics)
    • There are some additional settings stored in "\PhysicsEngine\Data\Resources\DefaultPhysicsSettings" ScriptableObject. It's possible not everything in there actually works
    • Everything in the scene starts with "TestSceneInitializer", which spawns the physics objects
    • The physics simulation is all done through "PhysicsSystem". This is where the fixed update is called and all other systems are manually called from it:
      • GlobalGravitySystem: Modifies rigidbody velocities to simulate gravity
      • RigidBodySystem: handles moving rigidbodies based on their velocity
      • UpdateColliderPoseSystem: handles making colliders follow their parented rigidbody (this is still incomplete, might be replaced with new Transform System later)
      • ComputeColliderAABBSystem: computes an AABB for each collider
      • BroadphaseSystem: the goal of this system is to ultimately produce a list of "CollisionPairs", which are pairs of collider entities which are potentially overlapping. It does that in three main steps:
        • ComputeAndSortMortonCodes: sort colliders in order of morton codes (also known as z-order curve)
        • BuildBVH: Creates a BVH with all collider AABBs
        • BuildCollisionPairsParallel: finds overlapping AABBs and stores them as pairs
      • ContactsGenerationSystem: This system's jobs is to take all collision pairs from the previous step and do the actual collision test on them to generate "CollisionManifold"s
      • ConstraintSolverSystem: uses the CollisionManifolds and feeds them to a constraints solver that will compute a set of forces to apply to all rigidbodies in response to the constraints
    TODO (short-term)
    • Box colliders
    • Rotations/Angular velocity/Moment of Inertia
    • friction and coefficient of restitution
    • Fix Constraint Solver giving things too much friction (?)
    • Optimize broadphase's "BuildCollisionPairsParallel" job. This is by far the most costly thing right now, and I feel like there must be a way to make it much faster. Try simply commenting out the line where we do "CollisionPairsQueue.Enqueue(newPair);" and you'll see that the job is now 100X faster. Cache misses are probably to blame here (?)
    • Put debug tools in their own separated editor-only systems
    TODO (long-term)
    • Support multiple contact points per manifold
    • rigidbody sleep mecanism
    • Capsule colliders
    • GJK and EPA for mesh colliders
    • Physics queries (raycasts, overlaps, etc...)
    • Joints
    • Collision events system
    • Collision layers & filtering
    • Cloth
    TODO (always)
    • Design improvements
    • Optimization
    • Cleanup
     
  39. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    6,251
    You are stating box colliders to do. Do you mean OBB? Since you mentioned
    Or is the further mechanics missing?

    Can you elaborate a bit more?
     
  40. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,149
    The AABBs I mentioned are only for calculating the bounds of every collider type, and are later used in the broadphase. They are not a collider type. The only collider type present so far is sphere, so yes the Box Colliders would be OBB colliders
     
    Antypodish likes this.
  41. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,194
    Thank you for releasing the WIP, greatly appreciated! I'll take it for a spin and see if I can contribute to this myself :)

    Few really minor things I found while briefly looking over it:

    - Manifest had to be modified as package manager ui isn't in preview anymore and I couldn't download the old one (I'm guessing this isn't an issue for people who already have the preview on cache but Unity doesn't distribute it anymore via packages so had to just strip the -preview.1 from the manifest entry).

    - When opening in VS, I get ton of "missing xml comment for publicly visible type or member" due to the incremental compiler being used. There's really nothing one can do to fix this easily for all as the alternatives are to modify the Unity generated .csproj and add <NoWarn>1591</NoWarn> to relevant PropertyGroup's (but csproj gets overwritten by Unity all the time, so this isn't really that handy) or to add following on top of each cs file (this is also bit tedious and ugly):
    Code (CSharp):
    1. #pragma warning disable 1591
    if anyone has better solution for this, please tell as I'm really close to writing just a script that replaces </PropertyGroup> with <NoWarn>1591</NoWarn></PropertyGroup> on csproj :)

    - Then, little nitpicking on the use of word Drag :D I always found it confusing on Unity as they don't talk about things on their right terms. Regular drag in Unity is actually more like (linear/angular) damping. But when using the word drag, people often assume it's some sort of fluid/air drag which is calculated totally differently so I feel linear/angular damping would be more appropriate terms for this purpose :)

    So, nothing major, I'll keep examining this and learn more about ECS while doing it, thanks again!
     
    Last edited: Sep 6, 2018
    Antypodish likes this.
  42. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,194
    ok, I put this on OpenSolution.cmd at project root for now:
    Code (csharp):
    1. @powershell -Command "(gc Assembly-CSharp.csproj) -replace ' </PropertyGroup>', '<NoWarn>1591</NoWarn></PropertyGroup>' | Out-File Assembly-CSharp.csproj"
    2. @start ECSPhysics.sln
     
    Last edited: Sep 6, 2018
  43. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    4,219
    Can't you store to exclude a compiler warning in a mcs.rsp file?
     
  44. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,194
    how should one do this? I tried putting that pragma there but it will just throw bunch of errors in the editor :)
     
    Last edited: Sep 6, 2018
  45. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,149
    Ah, yes. Renaming this to damping is still my intention, I just haven't gotten around to it yet

    pushed the fix for this, thanks
     
    Antypodish likes this.
  46. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    4,219
    You add a compiler flag with the corresponding warning only, not the actual #pragma. I can check this on Monday when I'm back at work and post an example.
     
    rizu likes this.
  47. MostHated

    MostHated

    Joined:
    Nov 29, 2015
    Posts:
    878
    Hello there, I only just came across this today but read through all the posts. This seems fantastic and you have done some great work here. I know it is a long way off from being something that would probably be usable in a game but I was interested to know if something like this would end up fixing the OnCollissionEnter() and OnCollissionStay() issue that the current system has? A game I am currently working on makes fairly decent use of Pärtel's PuppetMaster and one of the things that causes the most issue is all the allocations that it causes. If a system like this would make PuppetMaster end up performing better then I am excited to see what ends up coming from this. : D

    --Edit : Would this system also help with/allow more active characters to be on screen at once while using something like PuppetMaster as well?

    Best of luck with it, and keep up the great work!
     
    Last edited: Sep 9, 2018
  48. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    6,251
    I am pretty sure, that anything what is currently in Asset Store wont work directly on Pure ECS, which is goal of ECS physics.
    Something like PuppetMaster would need explicit rework, to be compatible with Pure ECS, to gain heighest performance.

    I don't know what is a problem to be honest with OOP OnCollissionEnter and OnCollissionStay. You refer to OOP of course?

    The physics engine has been handed over to the community in its current state, which require further work.
     
  49. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,149
    ECS physics would definitely have zero GC allocs and would probably be more performant than regular physics, but like Antypodish said, Puppetmaster wouldn't be compatible with this. It would have to be remade from scratch
     
  50. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,844
    c# animation jobs would speed up puppetmaster quite a lot, and it's something you could look at porting the more critical parts of it to if you wanted: https://blogs.unity3d.com/2018/08/27/animation-c-jobs/
     
    hopeful likes this.