ANCIENT THREAD! - Physics in Pure ECS

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

 

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.

 

I stumbled upon that today, you might find it interesting: https://github.com/bellicapax/bepu-physics-for-unity-ecs

 

I'll definitely keep an eye on this, looks very promising

 

can not run?

 

Report problem there: https://github.com/bellicapax/bepu-physics-for-unity-ecs/issues

 

Seems like it's still WIP:
https://forum.bepuentertainment.com/viewtopic.php?f=9&t=2527

 

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.

 

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.

 

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.

 

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.

 

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/

 

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 !

 

Are you going to open source this? I can help.

I am working on a GPU based rigid body solution:

https://github.com/jknightdoeswork/gpu-physics-unity

 

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

 

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

 

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

 

Multiple physics worlds will take care of that

 

I wonder if the cost of a hundred rooms, for instance, is too high. Many-many isolated chunks

 

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

 

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.

 

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.

 

Unity, hire this man. Good hell.

 

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

Great effort indeed.

 

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.

 

Do you have a source for that?

 

This thread at least (wanting and definitely going to are two different things tho):

 

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.

 

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!!

 

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

 

I would love to read you articles/documentation on this.

 

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.

 

Providing project is still alive. Fingers crossed

 

Allright everyone, something totally unpredictable 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

 

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?

 

thanks! There is a TODO list on the github page

 

Ah I see now, sorry for dumb question.
I should have checked first.

 

I just post description here as an archive, if not an issue.

Spoiler

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

 

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?

 

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

 

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 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!

 

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

 

Can't you store to exclude a compiler warning in a mcs.rsp file?

 

how should one do this? I tried putting that pragma there but it will just throw bunch of errors in the editor

 

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

 

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.

 

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!

 

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.

 

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

 

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/