ANCIENT THREAD! - Physics in Pure ECS

EDIT: This is an old project from years ago, not relevant anymore. DOTS now has its own physics packages

Spoiler: Old post

ECSPhysics aims to be a complete publicly-available 3D physics engine made entirely in Pure ECS for Unity.

It is not currently ready for any sort of real usage. It's a work-in-progress

Here are some of its current features:

• Sphere colliders
• BVH-based broadphase
• Sequential-Impulses constraint solver

Useful Links:
Github
Handbook/Documentation
Trello

__________________________________________________

Spoiler: Original Post

I'm in the early stages of prototyping a complete 3D physics engine made specifically for Pure ECS and GPU compute. I think the performance potential of this could be greater than the current physics we have in Unity, and having access to the full source of the physics engine that we can modify to our liking would be an invaluable advantage

However, I'm just curious about one thing: does Unity already have a plan to do this in the relatively short term (let's say 1-2 years)? Will we eventually have a physics engine that:

• supports Pure ECS
• uses GPU compute as much as it should
• has full source available (based on my previous experience with making character controllers, I cannot stress the importance of this enough! I'd say this is even more important than the performance advantage)

I'd just like to know if my work would be pointless before I start

 

I would imagine yes to all but the source code, because it is PhysX and therefore owned by nvidia.

It would be silly not to be developing this for unity given they already support computepenetration

EDIT: P.S I am also starting to do this for an RTS and would like to maybe have a catch up on how you get on in a while!

 

I doubt it will be in the next two years, but at the moment it looks like they want to push everything to pure ecs. I seriously doubt any source would be available for that.

 

Awesome. I'll see what I can come up with and will post back in these forums

 

It's a start!

The system is monstruously inefficient right now because I basically have no broadphase (I compare every collider agaist every collider, which is terrible), but I've at least reached a point where I have some kind of decent foundation to start building on. Also, I'll stick to just sphere colliders (and maybe box colliders) for as long as I can, in case I end up doing massive architectural changes. I'll implement the remaining collision primitives once I'm fairly certain I've got something good

For those who are curious, here's how I've arranged things so far:

• RigidBodySystem: For each rigidbody, handle applying drag and angular drag, and then handle moving the rigidbody position/rotation based on its velocity/angularVelocity
  
• UpdateColliderPoseSystem: For each collider (colliders are separate entities from rigidbodies, but they all know which rigidbody "Entity" they belong to), calculate their new worldPos and worldRot based on their relativePos from their associated rigidbody
  
• ComputeColliderAABBSystem: For each collider, calculate the AABB (Min, Max, Centroid, etc...)
  
• BroadphaseSystem: For each collider, do an AABB test against all the other colliders, and output a NativeArray<CollisionPair> representing all the pairs of colliders that are potentially overlapping.
  In the near future, I intend on implementing this state-of-the-art BVH algorithm for the broadphase. It is a great fit for the job system or the GPU because it is highly parallelisable. Plus, it doesn't rely on incremental updates, so it seems fairly simple, safe, and straightforward. We have the popularity of RayTracing to thank for the recent increase of interest in this area of research
• ContactsGenerationSystem: The first part of the NarrowPhase. Here we take all of the CollisionPairs from the broadphase, and do the actual collision tests. The output of this system is a NativeArray<CollisionManifold> that stores all the collision infos such as contactPoint, collisionNormal, collisionImpulse, overlapDistance, etc, etc...
  
• ContactsResolutionSystem: Takes all the CollisionManifolds of the previous step, and actually solves the collisions by applying impulses and displacements to the rigidbodies

Additional notes:

Spoiler: Manual update of systems

all of those systems are [DisableAutoCreation]. I handle their creation and updating manually in a "PhysicsSimulationSystem". This is so that I will be able to do an equivalent of "Physics.Simulate" later on with this physics system. But I haven't really tested yet if this works well, and I'm still not 100% sure if updating systems manually like that breaks any secret optimizations for ECS/Jobs/Burst

Spoiler: Contacts generation and resolution done in two separate steps

There is a good reason why ContactsGenerationSystem and ContactsResolutionSystem are two separate steps; it's because we sometimes need to be able to do some logic after contact manifolds have been generated, but before the collision is actually solved. Think about a situation where you are making character controllers and want to have complete control over how the character decollides from colliders. A common case is when your character lands on a slope after a jump. Normally, it'll decollide diagonally because of the angle, so your character will "drift" down the slope a little bit. What you'd really want in that case is to solve collisions 100% vertically instead. You can now add a system between these two that will modify the contact manifolds of your character rigidbodies before they are actually processed and resolved. This is something that we cannot do in current unity physics!

Spoiler: Collision "Events" strategy

How will collision "events" work? The plan right now is to build a NativeMultiHashMap<Entity, CollisionManifold> as contacts are generated. Then, other user-made systems can go get this multiHashMap and use the rigidbody entity as key to see if any collisions occured. Another possibility is to store collision events and collisions count in a "CollisionInfos" component that lives alongside the rigidbody, but I'll need to wait for components to be able to contain fixed-size arrays for that

Spoiler: CPU and GPU

My plan right now is to do everything on the CPU for a start. It's only after having completed the physics engine on CPU that I will start looking into doing GPU compute conversions for parts of the system. The broadphase would be a great candidate for this. I'm having doubts about whether or not the cost of CPU-to-GPU data transfer will defeat the purpose of doing things on GPU in the first place, though. A physics engine isn't very useful if you can't even access rigidbody position or velocities because they're all just on the GPU. Having separate physics worlds (some CPU-only, and some GPU-only with limited data access) is a possibility I'm considering. We'll see when we get there

Spoiler: An object's physics representation and visual representation are two separate entities

The rigidbodies and the actual meshes are separate entities. Mesh entities simply have a system that makes them follow their associated rigidbody entity with interpolation. In my opinion, interpolation shouldn't be the responsibility of the rigidbody or the physics engine like it is in unity physics currently. It leads to innumerable headaches when you try to move a rigidbody position manually while still keeping interpolation. I'd much rather have visual object be completely separate from their physics representation. It makes everything so much simpler

Spoiler: How applying forces works

Forces and torques will be applied by modifying Velocity and AngularVelocity component values directly. Users can choose if they want to take into account mass or not, or if they want to take into account deltaTime or not (impulse vs addvelocity vs force vs acceleration). But there will be static physics math functions to help calculate the resulting additive vel/angVel of adding a force at a point, for example

Spoiler: Gravity is user-applied

Gravity is not some kind of built-in value/functionality in the physics engine. Users are given the responsibility of handling it by themselves with a system that executes right before RigidbodySystem and that applies the desired acceleration to all rigidbodies. I made this decision because there are several games where the gravity is not the same for all objects (think of games like Mario Galaxy, games in space, games with character controllers that have stronger gravity than regular objects so that their jumps feel better, or puzzle games that play with gravity), and in unity physics I've frequently had to set rigidbody gravity to 0 and just apply it myself in code instead. I think it's just much cleaner to apply it ourselves based on our specific needs. With that said.... there will probably still be a DefaultGravitySystem that you can choose to activate or not. Maybe it'll be part of example content instead of the core engine

Spoiler: Kinematic rigidbodies can move with velocity

Kinematic rigidbodies can actually be moved with velocity and angularVelocity. This is a nice feature because when you have characters standing on moving platforms, they need to know the velocity of the platform so they can add it to their own velocity. Being able to move kinematics directly with velocity saves you an extra step of having to store the platform's calculated velocity (or lastPosition) somewhere else. Not a crucial feature, but nice to have

 

If you make this open source, I would love to contribute. I'm pretty sure other people would as well.

 

This is something I'll definitely consider at some point. I'll wait for the project and the ECS itself to gain more maturity first, though

 

I second what @starikcetin said. I've once implemented a very rudimentary n-body 2D physics for a space shooter game, but I did have a lot of the physics engine take over on what I did. Looking at your design you haven't catered for the different possible layers yet?

 

yeah I don't have a notion of layers at this time, but it's definitely something I'll add soon. And we can finally have separate physics & rendering layers! And not be limited to 32 layers

I'll also have a look at what UE4 does with its collision layers for inspiration, because I think they offer more granular control than what we're used to

https://www.unrealengine.com/en-US/blog/collision-filtering

 

I am just about to start an AABB System for sprites. Did you role your own transform system or did you use the build in one that does not account for scale (or was this added?)

 

I'm using my own equivalent of a transform system for rigidbody and collider entities, but I'll see if it makes more sense to just use the built-in one everywhere

 

Nice work !
I didn't know we could already manually update systems without breaking things appart...
I would love what Unity's team has to say about that, if we should do it or not, or if they will add some API to support this in a good way.

 

Pretty nice start. There is gonna be a huge improvement by using a spatial partitioning (like the boid ECS sample) to only check nearby colliders but also a flag IsMoving to avoid looping on inactive colliders, ECS will be perfect for that use case.

I have dabbled with GPU colliders a few weeks ago, it produce some nice results. (Yep, I'm using your KCC demo scene, it's a pretty good playground )

I've got about 200k particles checking each 1k triangles, 40 capsule and 5 sphere colliders at 1.7ms.
I've got the same problem here, without partitioning it won't scale well and making that data structure on the GPU won't be trivial.

 

Gonna use octree for collision partitioning?

 

I'll use a BVH approach for this. It's a type of space partitioning that is based on grouping bounding boxes in a tree structure of pairs that are relatively close to eachother, rather than just subdividing the space like an octree

My research suggest that this approach usually beats octrees, bsp trees and kd trees in terms of total efficiency (construction + traversal), in the context of both physics engines and raytracing

 

I'm in the middle of implementing my BVH construction in the broadphase, and I came across a very interesting metric.

I wrote some algorithm for calculating the morton codes of all of my collider centers, and them sort them in ascending order using a radix sort. It's a rudimentary initial implementation, so still not optimized or parallelized at all. But here's what's interesting:

Literally the only thing that changes between these two tests is adding [ComputeJobOptimization] on the job

Conclusion: holy crap!

Edit: I actually just managed to split that cost nearly in half, but it affects both burst and non-burst so the speedup ratio is the same

 

We're in for a hell of a ride once all the burst technology gets stable and onto all the consoles / high-end mobiles.

 

@Joachim_Ante if this solution philSA is working on becomes a pretty stable and complete + tested by community ,would you consider using it as a base (even if just for "informing" of things to do / not to do) for an official GPU physics system? Really worried that if work is not being done on this yet, without help from community is is unlikely we would see this for 2+ years

 

@PhilSA have you thought of putting this on Github yet? I'm really keen to see what this looks like.

 

@PhilSA I would love to help out or even just use it for reseach. Could you look at putting it on github? You might get it to where you want faster with more developers pitching in, and you can still control its quality etc with the PR system on github

 

A public repo is definitely happening a some point soon enough. I just want to get a few things cleaned up and sorted out first

 

Thats understandable! Thanks very much

 

Looking forward to seeing that, quite impressive work so far!

Been thinking about playing with a crude physics implementation myself. I think with the ECS+Burst approach a realtime simple fluid system should be feasible.

It's funny though how often that "I just want to get a few things cleaned up" stop people from releasing code publicly, I myself am guilty of that so many times It can be quite scary to release code for public scrutiny.

 

All of this was magic to read

I mentioned GPU physics specifically because of @PhilSA mentioning in the OP about using GPU compute as much as possible.

The points you raise about GPU vs CPU physics are valid and interesting ones however!

I would not imagine a GPU system would be the "default go to", but would afford those projects that can/need to offset some of that to the GPU that ability

Honestly though, just a physics system that leverages ECS and Jobs would likely be enough for everyone.

Also a little side note: you say , mostly that kind of GPU system is good for reserach etc, but with ECS, C# jobs and SRP, its a real possibility that Unity will be used increasingly for research like this in institutions. So either way I think itll find good usage

Really excited about the PhysX 3.4 stuff, I would love to test an experimental build even if it only is useful for just for filing a few issues

 

I have made some developments in re-implementing NVidia Flex, which is a unified particles approach, using ComputeShaders and/or JobSystem with Burst. Got all the main algorithms working but not optimized well.

The whole engine seems rather compact in terms of code but the guys at NVidia sure did spent a lot of time to fine-tune it for the GPUs (async compute, data sorting for coherent memory accesses etc).

Here are some insights:
http://mmacklin.com/uppfrta_preprint.pdf

D3D Async Compute for Physics talk and presentation with comments
http://www.gdcvault.com/play/1024344/

https://developer.download.nvidia.c...0Nebkxege-Xfiqch73esDZk8_CZm9KiQMyFVsZzMXxeSw

 

I try to not derail this discussion further, just wanted to add note that PhysX 3.4 GPU mode is still limited to Nvidia GPUs (and only works on Kepler+). More info about it here: https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/GPURigidBodies.html or just watch the GDC talk here: http://www.gdcvault.com/play/1024345/. Sorry again for offtopic, just wanted to inform people about GPU vendor limitation which can be a deal breaker for many if planning to release a game using this tech. This also obviously limits the platforms to PC space as well.

 

Thanks for the info good to know!

 

I've just finished a version of the broadphase that I would consider "good enough for now". There's still a lot of room for improvement (the broadphase still accounts for more than 80% of the total frame cost), but I'll wait until we can all take a look at it collectively in the public release

And I've got some nice results as shown in this video!
(first part of the video is PhysX - second part is my solution)

I've made two test scenes where 5000 spheres are thrown into eachother and land on the static floor. The first one in the video is regular unity physics (PhysX), and the second one is my ECS physics engine. I've tried as much as possible to strip down the PhysX simulation to be as close as possible to mine and as performant as possible (zero friction/bounce, don't auto sync transforms, use multibox pruning, 1 solver iteration, no interpolation). As you can see, once the spheres are settling on the ground, PhysX takes around 130ms per frame. My physics engine, on the other hand, stays at around 32ms per frame during that part of the simulation. However, PhysX does beat my ecs solution when colliders are just free-falling without any collisions (not shown in video). In that situation, PhysX is 6ms per frame, and ECS is 12ms per frame. I'm sure my broadphase is to blame here, since it's taking almost all the time in the frame

Here are profiler comparisons for the simulation shown in the video:

PhysX:


ECS:


The difference in thread usage is pretty huge, and the ecs physics engine might even get better thread usage than this as it progresses. There's also a hidden benefit for the ECS version that we don't see in this test: not only will the simulation be multithreaded, but we will be able to interact with physics in a multithreaded way (apply velocities and forces, read/write rigidbody positions, do raycasts in jobs, etc....), which is something I don't think we can do with PhysX

Note 1: take those numbers with a huge grain of salt, because we don't actually know how much more PhysX does under the hood, compared to my solution. We never know how much performance might decrease as we add more features to the ECS physics engine. But at least these results are telling me that I'm not totally off the track

Note 2: You might notice some spheres are bouncing really high in my simulation. That's just a bug I need to solve. It's probably because collision impulses are sometimes incorrectly applied multiple times or something

Note 3: My specs are:
CPU: Core i5-4690K (4 cores)
GPU: GTX 970 x2 (doesn't really matter for those tests, as I often disable the camera to compare performance)

And finally, I have a few more unrelated notes concerning the engine in general :

Spoiler: Physics queries inside jobs

I think we'll be able to do physics queries (raycasts, overlaps, etc...) from inside jobs. Unless I'm mistaken, all we need to do to allow this is that whenever we want to do queries inside jobs, we just have to pass to that job the various NativeArrays containing the physics world information (such as the BVH nodes array, the colliders arrays, etc...). This is different from the RaycastCommand already available in Unity, because RaycastCommand is an independant job, and can't actually be used inside another job.

Raycasting directly in jobs makes things much simpler in situations where you want to do raycasts in loops that break out when a certain condition is met

Spoiler: Physics for very large worlds

I am starting to think about what it would take to properly support physics for very large worlds where floating point errors would eventually end up breaking everything. I'll definitely take a closer look at this video to see how the team behind Kerbas Space Program handled that problem. I'm thinking about a built-in origin shift system, but if you guys have other insights concerning this, I'd like to hear them

Spoiler: No collider scaling

At the moment, I'm thinking I won't allow scaling colliders. This is because scaling colliders is always avoidable by making the collider proportions bigger directly. Scaling support just seems like it would result in plenty of wasted calculations

 

I can understand this concern. I'll write down a list of things I want to get done before releasing publicly so that people get an idea of what to expect:

• Add box colliders: Having more than one primitive type might reveal some flaws in my current architecture, and I want to get this sorted out before releasing publicly
  
  
• A rough raycast example: Again, I'd like to have this just in case it ends up revealing flaws in my architecture

• Finalize physics components design: I'm having several interrogations concerning my components. For example: should my rigidbody velocity component be called "Velocity", or should it be called "RigidbodyVelocity"? "Velocity" sounds like it could be used anywhere we need a velocity of some sorts, but it might lead to some systems operating on Velocity to accidentally modify rigidbody velocities, which is something we don't want. I think I'll go with "RigidbodyX" for everything. I also don't know if absolutely all components should be single-value (like the Position and Rotation components of the transform system). It might have a performance advantage due to resulting in structures of arrays instead of arrays of structures (?). For something as performance-critical as a physics engine, it would be worth it

• Stabilize collision resolution and friction a little bit

• Documentation: Just something quick to get people started. The system is fairly simple, so it shouldn't take long
  
  
• Make a Trello: To help guide development and contributions once this is released, I'll make a trello where the major todo tasks are listed

 

Nice work. Hopefully this gets some traction. I hate using third party libraries when it's a one of a kind type thing, because you never really know how good or bad it is until it actually gets some real competition. There were some competitors like Bullet/Havoc, but I think they are mostly dead now as far as any real new work into them.

 

A couple words regarding RigidbodyVelocity. It seems like Velocity will be just fine if your systems query Rigidbody and Velocity components, while users exclude Rigidbody component from their system queries (when needed). Also, look at how Unity added a component that forces their systems to ignore every entity that has it. I feel like Velocity, Torque etc will fit the best

 

If you don't need to simulate thousands of rigidbodies at once (consider implementing sleep functionality), I still think running physics in double precision is the way to go, this is also what KSP did for bigger scale things.

The upsides for using doubles for all physics is that it eliminates single precision floating point accuracy issues while keeping the solvers simple. You don't need to keep shifting every rigidbody/collider around on the physics side, you simply do same things as before and only shift the unity side of things (handle origin rebasing for unity's visuals and transforms alone but physics system itself wouldn't need to be aware of it at all).

Additionally, you can't easily do large scale multiplayer with floating point shifting approach for physics as your server will need to simulate the physics on the whole world at once (unless you really can limit all the players into small segment of the world at once). I can think of some approaches where you could solve the server issue on floats (divide the whole world in chunks and let server sim each chunk independently and then sync and somehow deal with the inconsistencies on the tile borders) but it all adds complexity and does compromises for the simulation quality (in my example, you'd want to keep the chunks/tiles as big as possible, which leads to lower accuracy near the tile border).

The downside from using doubles is that you get weaker SIMD gains (with SSE2, you can only do double math 2-wide where in floats you can do 4, with AVX you can do doubles 4-wide but floats could go 8-wide. I don't know if Burst really puts much 8-wide, so if the target can do AVX, the perf loss from SIMD probably wouldn't be that bad, although doubles SIMD instruction counts are probably tad higher as well). Other downside is that you'll get twice the data in cache so you are more prone to get cache misses.

But the main issue with doubles approach atm is that Unity's new math lib simply doesn't support doubles for anything, not for basic math, not for vectors not for quaternions. Since Burst relies heavily on that math lib, you are likely to lose most of the SIMD gains right away. If Math lib/Burst had full double support, I probably would have already done my own jobified physics solver in Unity (I've done simple double precision solver for Unreal in past). Unity has listed lack of doubles as a known issue on Math libs readme so there are chances that they'll add it some day but it's not a huge priority to them.

edit/disclaimer: everything I wrote was only with PC platform in mind, I have zero clue what kind of SIMD operations are available for mobiles / I've never done any mobile dev.

 

Dividing the world into chunks is relatively straight forward. I actually prefer to do it in small chunks, like 1k units wide.

I actually encapsulate the entire thing right into my equivalents of Vector3/Vector2. So ToPoint3D is an extension that takes a cell id. Plus another extension method that doesn't and pulls the current cell id from a static when using it client side. So on both sides translation is completely transparent to feature code.

And how many games are there that have huge open worlds that are FPS type games that even benefit from synchronized physics movement? I don't' know of any major mmo that uses synchronized physics for movement. And even in that case, latency means some of your clients are just seeing the wrong thing anyways. Fudging for coordinate translation precision loss I don't think would be a big hurdle.

 

@PhilSA,

Wow! You've achieved so much so quickly. I was expecting many weeks before hearing about progress like this!

A few quick questions. Will your physics engine...:

• Have a similar concept to isKinematic?
• Have cast/overlap checks?
• Allow non-axis aligned box colliders?
• Allow box colliders without uniform scale?

If / once all of the above are true, it could very well serve all of my needs for my current project.
Even if it does not, I can't wait to begin experimenting with it!

Also, reading over prior comments and considering the ECS approach, I'm wondering if it wouldn't be (relatively) simple to make features toggleable. For example, as @rizu mentioned, double precision would be fantastic for those who could afford the performance cost. I'd also be ecstatic to see a choice of friction models.

I'd also love to add additional collision primitives to my wish list. The lack of a cylinder collider in Unity's PhysX implementation has often challenged me. I'm certain that a Cone collider would also be put to great use!

As always, thank you for your amazing efforts, Phil!
- S.

 

I do have Kinematic rigidbodies right now (the dark ground spheres are kinematic). My current plan is to arrange things like this:

• KineticRigidbody: A regular rigidbody that has a mass, reacts to forces, and de-collides from other rigidbodies
• KinematicRigidbody: Rigidbodies that count as collidable things, but don't react physically to anything. However, they can be moved manually and kinetic bodies will properly react to the movement (if a kinetic box is sitting on top of a kinematic platform that moves, friction will be properly applied)
• StaticRigidbody: Rigidbodies that are similar to Kinematic rigidbodies, but will be fully optimized under the assumption that they can never be moved
• TriggerVolume: A set of colliders that only acts as a volume to detect overlap events (triggers). Other rigidbodies go right through it

Maybe they'll be 4 separate component types; and maybe they'll just be an enum on a general-purpose rigidbody component. Unlike current unity physics, colliders that are just sitting around with no rigidbody or trigger component attached will be completely useless.

I have no physics queries at the moment, but a raycast should be available when this gets released. Box colliders will also be added relatively soon

Double precision mode would be a very interesting feature to add. I don't think Unity.Mathematics has any notion of a double right now, though. I'll have to investigate further. Maybe it's possible to prototype it with regular doubles

A cylinder primitive is something I'm considering, but I'm not sure yet. From what I've read, mathematically-correct cylinder collisions sometimes end up being more expensive than convex mesh collider cylinder collisions. I'll keep it on my list for sure, though

 

Unfortunately, there's no support for doubles on the Math lib itself, so you'd have to basically copy/paste the existing math libs needed parts into double format or modify the stock math lib (but this wouldn't be easy to ship in github). Obvious downside of this is that you'll lose almost all Burst optimizations right away, so I can imagine this will not be a thing you'd want to have today but more of thing in the future if Unity will support double types (they are not that slow if Unity adds Math lib, Burst and AVX support for them as you can then do doubles 4-wide). It would work even now without Burst optimizations if you handle the double math yourself (or copy stuff from math lib and mod it to use doubles) but perf difference will be noticeable.

 

It is a shame they did not consider determinism with the new mathematics library.

 

I'm pretty sure they did. What makes you say that?

 

It's a bit fuzzy now but I know there is a thread around here somewhere where they addressed that specifically.

 

Doesn't the new mathammathe library use floats? If PhilSA wanted to make his engine deterministic wouldn't he have to use his own math library and such?

 

I'm using floats, yes. However Unity did mention they want to allow floating point determinism with Burst

 

They have considered determinism and they're aiming for it:

https://forum.unity.com/threads/burst-compiler-deterministic-floats.522856/#post-3493121

 

@PhilSA: This sounds fantastic!

Alas, I have no thoughts on multiple components versus a general component for the different types of Rigidbodies. I'll be interested in seeing your decision, and hearing your logic (if you're willing to share).

Including double variants of relevant components and systems would be excellent. I imagine it would be a fairly simple conversion, perhaps switching between double/single precision variants via a preprocessor condition? Of course, that’s of less importance than establishing the primary features, and if it really is that easy, it shouldn’t be difficult for users to implement themselves.

Regarding double precision support in the Unity.Mathematics library—Unity has stated that double precision is on their roadmap. For the meantime, I've attached scripts that add double support to Unity.Mathematics. To use it, simply extract, then copy and paste the scripts into the relevant packages folder (eg: C:\Users\[USERNAME]\AppData\Local\Unity\cache\packages\staging-packages.unity.com\com.unity.mathematics@0.0.12-preview.5).

Quick disclaimed about the attached scripts
The double scripts are modified versions of Unity.Mathematics scripts. I replaced types and literals with doubles where applicable, and updated constant values to take advantage of the increased precision. While reasonable care was taken while modifying them, but there's no guarantee that a few float values didn't slip through. Additionally, I made what I hope was a reasonable guess as to an appropriate value for "epsilon_normalD" in d_mathextended.cs, but I'm not certain, as I wasn’t able to determine exactly why they decided on the equivalent value in the original script.

Regarding calculation of cylinder primitives, I'm surprised to hear that it's so expensive. Is it more difficult than simulating a box with an additional axis distance check on two axes? Or is that in and of itself an expensive proposition?

Of course, I realize that nearly all tasks are more challenging than they first appear. Please realize that I only inquire because I'm interested, not in an attempt to affect your focus/approach in any way.

As always, thank you! Be well!
- S.

 

Nice, I'll check it out

Seems to me like this is all it would take, yes. In any case, I'll most likely end up testing it in the future and see what's what

 

How add physics to ECS Entity ? var playerArchetype = entityManager.CreateArchetype(typeof(Rigidbody)); Don't work(

 

While working on implementing friction and bounce, I discovered something pretty cool: my system is actually 2x more performant than I thought it was... because all of my systems were actually running twice per frame by mistake!

¯\_(ツ)_/¯

So I've got some new performance numbers:

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

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

5000 colliders falling on the floor into stacks
Physx: 130ms
ECS: 12ms