ANCIENT THREAD! - Physics in Pure ECS

Those numbers are pretty interesting. I guess there is just the overhead of running it as an ECS which means it runs slower than physx up until a certain point where it becomes much faster?

What is the 'tip over' point?

 

It's really just my broadphase that's responsible for this. I'm sure its performance could be improved massively.

I think the tipping point happens because my broadphase is a poorly-implemented parallel algorithm right now, and sequential algorithms can perform better under a certain threshold. But that's just a theory

 

Just a side note, as a physics guy I really hope you will call "bounce" restitution instead . I know unity likes to rename these things so that "common devs" get them but this often makes it harder for people who have actually done more physics to understand what that thing does (good example of terrible physics naming convention in Unity is calling linear damping a drag as it leads people to believe they actually model that drag, like for air/fluids).

 

How come your system is that much faster?
Is it just because there are many features missing compared to what PhysX offers? And if so, what are those?

Surely the nvidia people have put in some massive effort over the years to make things as fast as they can be, no?

 

Maybe because of the burst optimiztations, as mentioned there:
https://forum.unity.com/threads/physics-in-pure-ecs.531716/#post-3504828

 

Not necessarily. One they have no real competition. I remember people saying how good the CLR was and how it was so optimized. Now that we have dotnet core to compare to, turns out it wasn't nearly as optimized as everyone thought it was.

Physix is old. It's had a number of major changes layered on top of older code. I would actually expect any new clean implementation by a good developer to beat it. Nvidia would likely beat it themselves by quite a bit if they started over from scratch.

 

PhysX is actually rather well optimized, they do lots of SIMD math and cut many corners to gain the speed (but next PhysX version will have more accurate solver). PhysX queries are really fast too (it's important to remember that physics engine is usually more than just rigidbody solver).

One thing to note is that this is also way simpler system. PhysX does tons more, it has constraint etc solvers and it supports a lot more shapes. It's not hard to make a simple c++ solver that just handles bare minimum and beats every existing game physics engine on some simple benchmark. For example, I could run my naive single threaded solver using double precision at 10kHz for my vehicle physics, and it didn't even have many optimizations in it. That being said, comparing apples and oranges will not make people much wiser. It's good to keep track of the perf for your own solver to see where it's going, but comparing two totally different things will not give you the right data.

Of course, we often don't need everything fully featured physics engine has got to offer but we do pay some price for the convenience (that it can do everything we need it to do). Also worth noting that unless you do some mass simulations, your physics engine perf doesn't really matter that much, in many games physics queries (raycasts, sweeps) may be even more demanding on the overall physics system than the actual rigidbody simulation.

This project is looking very promising so far and it can definitely get best out of unitys new "performance by default" setup. I'm also not saying it can't be faster than PhysX if it someday gets comparable features but it's pretty far from that still so mainly trying to say it's not a fair to compare against it. I'd also love to check the project out myself and see if there are some additional optimizations to be made to make it even faster.

 

But since this engine is using ECS, we can simple disable some unneeded systems and boost performance a lot. In PhysX you get a lot of things that you don't necessarily need and you can't disable it.

 

A big part of it is probably that my system is still very simple, but here's some other possible reasons:

• As the profiler pics show, my system is much more multithreaded than Unity PhysX
• In my system, the game engine and the physics engine were made to understand eachother directly and operate on the exact same level. There's no additional cost of converting scene representations or sending the information back and forth between C# and C++
• PhysX is still very OOP, and was designed with the intention of being integrated in many different game engines. Surely there is some kind of performance tradeoff to allow this
• Most of the time in the Unity PhysX test is spent on "PhysX.psxMBP.updateWork". MBP stands for "multi-box pruning", which is PhysX's broadphase algorithm. Since nearly all time in both Unity PhysX and my system is spent on the broadphase, the performance comparison is essentially my broadphase against theirs. I'm guessing my broadphase is faster either because the algorithm is better-suited for those tests, or because it just makes much better use of multithreading

Note that it's important to make a distinction between "PhysX" and "Unity PhysX"

 

This guy gets the point.

This is why I love ECS, on top of superior performance we also get excellent modularity and scalability.

 

Thanks for the answers guys. That makes things more clear.

How far do you think you will take your own physics implementation?
Do you plan to add hinge/ball/... joints? And what about concave models?

 

Ideally, I'd like to reach feature parity with current physics in unity. That includes joints, cloth, and I'd even throw in softbody simulation and fracturing/destruction if I can. But it'll take a lot of time and a lot of work to get there. I don't think it's an impossible task, though

 

That sounds like something that will tickle asset store's fancy. You little businessman, you.

 

In my opinion, the core physics engine should definitely remain publicly available to all for free, but I do see a lot of potential for physics addons on the store. I'm sure plenty of people would be interested in developing amazing specialized addons like cloth, softbodies, buoyancy, vehicle physics, destruction, etc.... for this physics engine. Maybe even things we typically never see in physics engines, like simulated aerodynamics and deformable rigidbodies

This is another great advantage of having an open physics engine instead of a hidden built-in one, and the ECS design would make it very easy to add features like this without breaking anything

 

I would be surprised if a more context specific broadphase algorithm wouldn't beat BVH. BVH would be a nice general purpose works for all cases approach. But I've always been able to beat more general spatial partitioning algorithms with approaches that leverage the environment specifics.

Like at first glance spatial hashing or using square magnitude checks might not appear to be good tools. But a bit of creativity and applying it to your specific environment can change that. Most research papers and general purpose libraries have to solve for a much wider range of use cases.

For example partitions you know in advance, so you can do things like precompute square magnitude from center to edge on all of them. Then compare to the square magnitude of center to entity. It's very simple and quite performant. You would need special logic for filtering entities near the edge. You might have special logic for the Y axis. You can do similar approaches using spatial hashing, or even spatial hashing with square magnitude filtering.

BVH is fairly costly. Doing it on the gpu just makes it faster, it doesn't make it cost less. The advantage of BVH is it will just work. You won't be tweaking it as much for edge cases you didn't think of. That's basically the core trade off the way I see it. I'm very confident I could beat the performance of BVH by a fair margin, but I know I would likely be tweaking my own mixed approach more often and likely have more bugs in it initially.

 

Great man!

Now i cant even wait to see the moment you release the code to the wild so we can all play around and possibly contribute

 

I was alerted to this thread. I'm an engineer on the PhysX team. I did some benchmarking with PhysX 3.3 and PhysX 3.4 with scenes with 5000 spheres being dropped into a hollow box container. This configuration is more expensive than dropping into individual groups as the solver is forced to solve a single massive island in parallel, rather than solving individual smaller islands in parallel. I get at most 13ms per frame with PhysX 3.3, at most 10ms per frame with PhysX 3.4 and around 4ms per frame with PhysX 3.4 running on the GPU. In all cases using 4 threads on an i7-5930k. That's quite far off the 130ms reported here for what sounds like a similar, but potentially simpler case.

I also tested 20k spheres falling under gravity. I saw per-frame times of 21ms with PhysX 3.3, 13ms with PhysX 3.4 and 4ms with PhysX 3.4 using the GPU.

Based on the numbers I've seen from PhysX 3.3, your results seem to indicate numbers ~10x larger. Unity simulates with PhysX using fixed time-steps, running multiple steps per rendered frame if the engine is not able to keep up with real-time performance. For example, if it were configured to simulate at fixed frequency of 1/60 of a second, and you were running at 20FPS, it would run the PhysX simulation 3 times for each rendered frame. Is there any chance you're accidentally comparing the total simulation time for all PhysX substeps? Based on your results compared with mine, I suspect PhysX might be running 10 substeps.

Alternatively, could you please provide further details (ideally a PVD capture) so we can establish what's going on because this does not sound even remotely close to the kind of performance PhysX usually achieves.

 

How do I control in Physx, what is considered an island? I would like to chop up my static colliders or understand how islands work so I can optimise that. Thanks for any insights!

 

An island is anything that is connected (either directly or indirectly) through either a contact or joint. For example, a large pile of rigid bodies would be considered an island. In order to be part of the same island, there needs to be an unbroken chain of contacts or joints connecting a pair of bodies in the scene.

However, islands only contain dynamic bodies. Static or kinematic actors are special-case handled to not act as bridges to connect islands because they have only one-way physical interactions with the dynamic bodies as kinematics/statics are considered to have infinite mass. Therefore, there should not be a requirement to divide up your static colliders to break up islands.

 

You're absolutely right, this would explain the surprising results I've been getting. The profiler reveals that there are actually 6 iterations made during the PhysX test that I previously thought took 130ms. Can't believe I didn't think about this:



If we take only the "FixedUpdate.PhysicsFixedUpdate" into consideration, that would make 135 / 6 = 22.5ms per iteration.

I have also corrected the update cycle in my ECS solution since yesterday, and got some improvements on my side too. Here are the corrected numbers for the tests:

5000 colliders free-falling into the void
Physx: 6ms
ECS: 3.6ms

20000 colliders free-falling into the void
Physx: 40ms
ECS: 75ms

5000 colliders falling on the floor into stacks
Physx: 22.5ms
ECS: 7.2ms

My CPU is i5-4690K, and all these numbers are taking into account only the physics (no rendering)

Another important thing to note is that I can only compare the two solutions in-editor at the moment, since I cannot do a Burst build. We know Unity PhysX performs considerably better in builds, but we don't know if the ECS solution will be better in the same proportion too

 

Thanks. The numbers are still a bit on the high side (about 2x higher than I'd expect, especially the free-falling numbers) but I'll take your word that performance gets better in builds. This is at least not 10x off my expectations so at least some of the mystery has been explained

 

I will look into releasing the PhysX test project on here later today or during the weekend, if you're interested in playing around with it

 

Also worth noting that Unity defaults into 6 internal (position) solver iterations for PhysX for each physics step. I'd assume the six calls you are seeing are just a coincidence and not related to this directly though.

There are all kinds of funky things you'll start seeing with stock unity physics once you trigger the physics engine cpu starvation failsafe. By default on 2018.2 max physics deltatime is 0.1, meaning once you go past 100ms in frame updates, your physics will be capped to whatever iteration count happens inside that 100ms with fixed timesteps. If your frame takes longer, your physics will still only sim using that 100ms time and physics start to run slower than real time, making it harder to do proper comparisons.

To get more comparable numbers, I imagine you'd need to step physx yourself using same logic as your ECS physics stepping (instead of letting unity automatically update physx simulation steps) and setting both of the internal iterations on physics to 1 from project settings (or set them to same values as you use with your own custom solver). Idea behind the internal solver iterations (afaik) is to add more cheaper solver iterations position and velocity to gain more precision and on the other hand only solve collisions and more expensive operations only once per physics step.

All that being said, if keep using the stock physics stepping and you really hit 100ms frametimes, you can't just remove the starvation protection with fixed timesteps as things will soon explode. But you can try to see if you can set the max allowed timestep bigger than your measured frame time, just to make sure you are getting full physics stepping there.

Also since you are doing this in editor, it would be interesting to see physx 3.4 figures too (2018.2.0b6 with physx 3.4 in editor available here: https://forum.unity.com/threads/experimental-build-with-the-physx-3-4-1-upgrade.530270/ )

 

Adding my 2 cents, to me performance between the two is rather irrelevant, what is most important is usability, Physx currently is not compatible with ecs, you have to create additional layer to receive events and feed them into ecs, plus there is no clear way to architect such thing, how do you accommodate fixed update into ecs?
So the point to me is to make physics system that is architected to work with ecs from ground up.
Not saying performance isnt nice, but pretty sure majority of people will most of the time just react to npc colliders and do raycasts.

 

For the PhysX test, I've set this to only one iteration in order to make it a close as possible to mine

I've made my ECS physics run on the PlayerLoop's FixedUpdate, and it looks like it's using the same max fixedUpdate deltatime mecanism as the physics. In the 20k colliders ECS test, my system's simulation is shown to run for 6 iterations per frame too

But I will do some more proper comparisons in the future, with more varied test cases. And I think I'll make my own FixedUpdate loop too so that all the logic is exposed clearly and there are no surprises

___

I've also found out that I generally get better results with the sweep and prune broadphase than with the multibox pruning for those tests, especially for the one with colliders falling on the floor

5000 colliders free-falling into the void
Physx: varies between 5.5ms and 6.5ms
ECS: 3.6ms

20000 colliders free-falling into the void
Physx: 36ms
ECS: 75ms

5000 colliders falling on the floor into stacks
Physx: varies a between 11ms and 18ms
ECS: 7.2ms

 

I've given this some thought and I think I'll go with "Coefficient of Restitution" and "linear damping" instead of bounciness and drag

 

@PhilSA I'm wondering how do you represent collisions in your physics engine, is it entity per collision? If so, how much time does it take to create all the entities, do you have any tricks to speed up entity creation and initialization given that it cannot be done in jobs.

 

I don't create entities per collisions. I'd be curious to try it, but I think right now this approach is too unoptimal. Unity did mention that they plan on making it faster, though.

What I do instead is that I store everything in global arrays that are stored in my main "PhysicsSystem". So for example, I have an array of "CollisionManifolds", which contains all the collisions that happened this frame.

The issue with my arrays approach is that while it works perfectly for the general rigidbody simulation where we need to go through every collision event no matter what, it becomes difficult to efficiently see if a specific entity had any collisions. We don't want to have to search through that entire array for each entity to see if it had collision events this frame. So what I think I'll do is this:

• Keep the Collisions array because it is highly efficient for the rigidbody simulation
• Each rigidbody will have tick boxes to determine which kinds of collision events they should receive
• For rigidbodies that do receive events, components containing the events data will be added/removed to those entities

It's a really vague plan right now, and maybe I need to give it some more thought. But it'll probably be something along those lines

 

Thank you for detailed explanation, the one problem I see with your plan is that adding removing components also cannot be done asyncrounously and the other one is that if you will use component for collision instead of entity for collision you will be limited to one collision per object.

I want to it is nice to see someone trying big things with unity ecs, I think your feedback will help unity team to improve their framework.

 

Not sure if it makes sense in this context, but a common solution to such problem is to work with "handles", that are actually array indices.

The idea would be, in order to receive collision events, the object asks for a handle from the PhysicsSystem. The PhysicsSystem associates the object<>array-index and this doesn't change as long as the object doesn't return the handle to the PS. The handle acts as "collisionEventsEnabled property" for the object, so to speak.

The array-index would be stored in the object, which makes it then possible to lookup the value without search.

 

I made a new PhysX test project with the experimental PhysX3.4 build (available here), and I can see some huge improvements. Here are the latest results:

5000 colliders free-falling into the void
Physx: 4.5ms (previously 6ms)
ECS: 3.6ms

20000 colliders free-falling into the void
Physx: 20ms (previously 36ms)
ECS: 75ms (Still don't know what's happening here, but I suspect this could be greatly improved with a bit of tweaking of the broadphase)

5000 colliders falling on the floor into stacks
Physx: 10ms (previously 11ms - 18ms)
ECS: 7.2ms

I'm attaching the PhysX test project to this post. The three tests can be selected in the inspector of the "Init" object in the scene by setting the TestPreset dropdown: https://i.gyazo.com/c607fbc073ca8c71008b7671fb1e7429.png

 

Hey, you can look at the Bullet Physics for Unity's Source Code for reference.

 

I'm using a number of different physics engines as learning resources:

• Bullet (c++): https://github.com/bulletphysics/bullet3
• Nudge: https://github.com/rasmusbarr/nudge
• Cyclone: https://github.com/idmillington/cyclone-physics
• React3D: https://github.com/DanielChappuis/reactphysics3d?

 

Hi!

I have a question regarding the design of your collision system with the ECS. I did a very simple collision system do that basically does brute force collisions.
But there are 2 problems: Each shape I have is a separate IComponentData struct. And I have written one system for each possible pair of collision shapes. But I feel that this get hard to maintain if you have too many shapes. Is there a better way to do it? For example having more shapes but have a central ComponentSystem that issues different Jobs depending on the collisionPairs? I tried but the performance was really weak. The thing is: In regular ComponentSystems you will access the structs by value, which can result into a big overhead if you have many entities that hold data.

but when you have a JobComponent system that uses a IJobProcessComponentData job, the structs are accessed by reference. Currently I simple put my important collision objects into an array and pass a copy of them to the IJobProcessComponentData that handles a certain collision shape.

My other question is: How do you structure N:M collisions?
For my game, I have implemented a system that works for probably between 50 and 100 objects against n - objects of a certain shape, but performance will get very messy after that.

Kind regards

 

I plan on having one component per shape too, but I haven't yet tried implementing multiple shapes. I think I'll be doing one single system that issues different jobs for each possible pair type.

I do think physics engines typically have one specific collision solving function for each pair type, which means that if you have 5 primitives (sphere, box, capsule, convex mesh, generic mesh), you'll need 25 possible solvers. I think sticking to only these 5 is probably a good idea

As for performance, my collision solving represents just a tiny little portion of the total frame cost, so I haven't yet bothered much with optimizing it further. I'm using an IJobParallelFor that goes through two arrays of entities representing the pairs of entities that are potentially colliding together, and then I use several "ComponentDataFromEntity" arrays to retrieve collision information from those entities

It's all about finding a broadphase algorithm that doesn't become exponentially heavier with the quantity of objects it's dealing with. The technique I'm using currently is a pretty standard BVH. This article describes something that's similar to what I'm doing: http://www.bwfischer.com/oculusRayTracer.html

 

Thank you for the quick answer!
Well those 5 collider types will certainly be enough. It would be interesting though to have a compound collider support.
For my game, 2d collision is enough, So I plan to support circle collisions, line collisions and eventually polygon collisions. But I have trouble debugging code from the job system, so I still have a few bugs.

So you retrieve all entities and with ComponentDataFromEntity you retrieve the according collision shapes?
And after you have done your broad phase algorithm you use 2 NativeArrays to store the collision pairs? (1 array = 1 collider, the same index of the second array is the other collider of the pair?)

And then do you store your collision results in a [WriteOnly] NativeArray and apply the effects back in the ComponentSystem?

One other thing I noticed: ComponentSystems generally run on the main thread. So if you do the broadphase collision detection, schedule your jobs, execute them and apply the collision effects all in the same OnUpdate iteration in a ComponentSystem, don't you block the main thread while waiting on the async jobs to finish?
Is there a better way to do this? Maybe scheduling the jobs at the end of the frame and apply the results at the start of the next frame?

 

@PhilSA any ETA yet on when you might be releasing this to the public eye? My mouth is watering to see the cool stuffs.

 

@PhilSA I also would like to potentially get access to this as soon as possible, especially as I will likely develop tangentially to you and therefore would be potentially adding alternative / additional workflows to yourself (no point working on what you are already doing so well)

I understand that when adding a git repo its always stressful as you feel the need to clean code, but honestly noone will be judgmental here on such a research based project so don't let that hold you back if it is!

 

also @PhilSA it might also be a good idea to look at box2D. A lot of their methods are extremely clean and well thought out and can be uplifted for 3D very easily

https://github.com/erincatto/Box2D

 

I'm sure many would love to examine this project out, me included. I'm also sure this is kind of project that would attract pullrequests and could grow out to be a community project (but at the same time it's always hard to tell how much things get traction eventually). The risk in doing things all the way is if original dev loses interest and if community is not involved enough at this point, the project usually dies. Also, it's easy to go feature creep and always just keep adding things before you think it's done.

I don't try to pressure to release the project tho. Heh, I've done similar things myself I've never released so I'm not even in a position to ask such thing One reason why many are waiting to get their hands on something like this is because there are not that many good examples on how to use the new ECS for something useful. Having physics engine running on one would be pretty much first practical example on how to use it as I doubt majority will be doing fish boid simulations on their games

 

That's right, but the effects are applied in another job that follows the broadphase job

I'm not yet sure if this would be a possibility (maybe it is). I haven't taken enough time yet to think about whether or not it's a good idea to always be 1 frame late. Technically I'm sure this would work, but it might result in usability problems.

There surely are ways to improve my thread usage, though. Here's what it looks like now:

 

The repo is coming, but like I said I just want to release it once I've got something at least a little bit coherent. My task list before release is this:

• Fix contacts resolution issue that makes colliders bounce out of collisions when they shouldn't
• Add box colliders, because having more than one collision primitive will surely make me have to change the way things work
• Add rotation aspect to collision resolution, even if not final

I haven't found much time for the physics engine this week because I had to finish things for another project, but now that that's done I can finally go back to it

 

Update:

I don't have much new stuff to show yet, but I'd like to keep people here up to date with what I'm doing just so they know the project is still going strong.

For the past week I have been focusing on understanding the problem of why some of my spheres are bouncing off some collisions even though they have no bounce. The reason why this happens is simple, but the solution wasn't immediately obvious to me. It happens because when a sphere comes into contact with 2 or more colliders simultaneously, the impulse to solve the contact constraint and "cancel out" the velocity is applied multiple times, which is what propels the rigidbody upwards. Moreover, this problem is also the cause of jitter in large rigidbody stacks.

After studying the literature and GDC talks for a while, I've established that the solution to all this is to implement an LCP solver for my NarrowPhase. More precisely; the Projected Gauss-Seidel method. From what I understand, Bullet and Box2D both use similar LCP approaches in their contacts solvers, so I am fairly confident this is *the* way to go, at least for a start.

Implementing this solver looks like it's going to take time, though. So it's very possible that I'll postpone it until after I release the first version of the source code. But maybe it just sounds scarier than it really is, which is often how these things turn out to be. I'll re-evaluate this in a few days

PS: PhysX mentions that they want to move away from the performance focus and instead favor accuracy in the future. It's something I'll keep in mind and see if I want to go in that direction too

___________________

Some of the resources I've been studying, for those who are curious:

• http://box2d.org/files/GDC2013/Tonge_Richard_PhysicsForGame.pdf
  
• https://docs.google.com/presentatio...0z9LGz6nUBjfRGRWlhWfDHyf37s/edit#slide=id.p13
  
• https://www.cc.gatech.edu/~karenliu/RTQL8_files/lcp.pdf
  
• http://twvideo01.ubm-us.net/o1/vault/gdc09/slides/04-GDC09_Catto_Erin_Solver.pdf
  
• https://www.scss.tcd.ie/Michael.Manzke/CS7057/cs7057-1516-10-MultipleContacts-mm.pdf
  
• https://www.cc.gatech.edu/~karenliu/RTQL8_files/lcp.pdf
  
• https://en.wikipedia.org/wiki/Gauss–Seidel_method
  
• https://www.cs.ubc.ca/grads/resources/thesis/Nov02/Michael_Cline.pdf
  
• http://umit.cs.umu.se/modsimcomplmech/docs/papers/warm_start.pdf
  
• http://www-personal.umich.edu/~murty/books/linear_complementarity_webbook/lcp-complete.pdf
  
• https://www.diva-portal.org/smash/get/diva2:695410/FULLTEXT01.pdf

 

If you watch the GDC talk, it's not really about moving away from perf, their new more accurate solver is almost as fast as the old physx solver (they still care about perf).

This new solver isn't available yet, so it'll take a long time until we get it into Unity for example. Nvidia recently bumped latest PhysX version to 3.4.2 and it wasn't included.

 

how about wheelcollider,driving 1000 cars will be very cool!!

 

Wheel collider is just a custom suspension and tire sim part of vehicle physics. While many would use it, it's super specific to one use case. Technically if you got a physics engine, you can implement that kind of functionality manually (as everyone does for anything more serious as stock wheel colliders aren't that great if you need more control over them).

That being said, job system alone will help doing custom vehicle physics for many vehicles at once for sure, but IMO it's bit out of scope of generic physics solver and takes time away from more important features.

That's my (educated) opinion on this matter as a guy who's worked on vehicle physics for years. If there would be some simplified suspension component in the physics implementation, chances are that most people would still redo it as these are really specific to the game and handling you are after, if done properly (which is why wheel colliders aren't really used all that much on serious projects).

 

any study about wheel collider physics with ECS?Have possible to get?

 

It's just spring force at position.

 

Bullet is still very much alive (I'm main author), we currently focus on simulation for deep learning (AI) and robotics, through PyBullet Python bindings. It is very exciting to see the ECS/GPU physics development experiments going on here, we used to also implement GPU physics in 2009-2013 using CUDA and OpenCL. Good luck!

 

Awesome work. Just to give some context, yes this kind of improvements would be great for academia and research work. Here is one my projects using unity where we would generate 1000s of non spherical particles to give you an idea. The limit is about 10000 right now and performance starts to drop early on but is still a major leap over what people currently do in academia and research (most just generate spherical packs). When I present the work, i see excitment about the possibilities with Unity and of course healthy skepticism about accuracy. So stating clearly what equations used in white paper or a publication is another thing that is limiting the adaption. I hope this info helps.

https://github.com/MosGeo/ParticlePack

p.s. This is a relatively old project that I started when I got into Unity (although we just put it online recently). So the code is not the cleanest code in the world. I am thinking of rewriting it with ECS and new features if I have the time and depending on peoples usage.