[With Project Sample] ECS / JS + Bullet Physics. Is it feasible?

Hi again.

I was thinking, since many of us is, or will be looking for physics engine solutions with ECS / JS, I was wondering, if anybody thought about marrying ECS with Bullet Physics?

Is this something feasible?
Rendering still could be done on Pure ECS side.

There if few possible candidates, but I looked specifically at
[RELEASED] Bullet Physics For Unity
https://forum.unity.com/threads/released-bullet-physics-for-unity.408154/

I have briefly initiated topic on mentioned forum

Edit:

I would like to say many thanks to julian-moschuering, for sharing project, with working example of BuletSharp (2.x) with ECS. See post #27

 

Just include BulletSharp directly. The Plugin only adds additional stuff for usage with GameObjects. Current BulletSharp has pretty good Multithreading support which is still missing in the Plugin.

I did a quick test a few weeks ago. Having a single JobComponentSystem that updates/fetches data from Bullet. Bullet doesn't care which thread accesses it but it may only accessed by one at a time so this worked very well.
It is slower than PhysX thought but gives your alot of additional control which you don't get when using PhysX through Unity. Forget GPU acceleration of PhysX, still nVidia only and thus unusable.

I will probably use this for the time being as it's simple to use. Switching to a later ECS solution by Unity shouldn't be that hard.

 

Yep, I am not too concerned about Nvidia GPU - PhysX acceleration. So the solution would suits me.

Further down the line I run a test, and commented on Bullet Physics thread

Basically I came to conclusion, during simulation of colliding and falling 2880 blocks, what you have just mentioned. That Bullet Physics plugin uses single core, outputting 3 FPS. While PhysX used all 8 cores, with much higher FPS of average 25 FPS on my rig.

What you say regarding Bullet itself, is interesting, as I was loosing hope.
Would you call me greedy, if I ask to share part of the test project, where you have an integrated Bullet? I am not specialist on that part, but probably I can figure out how after some tries. However, I did spent quiet a bit of time, scouting around bullet physics and Bullet3, Couldn't find clear solution. Probably I will try directly BulletSharp. I guess that what you meant?

I think other could find is useful as reference, if you don't mind of share course?

Also, I reads somewhere, but can not find back references that bullet sharp may not be ported (at least not any time soon), to Bullet3. There was something mentioned about GPU etc. But I would need find correct citation.

 

I'd be very hesitant to go that route. I mean it would have to be an incredibly strong use case and one I had no other option for. I'd be much more tempted to simply write what I needed from scratch, since it's going to be very context specific anyways.

Like I already have poor man's versions of box/sphere colliders based on using a combination of bounds checking and raycasting in jobs. I have spatial structures that are context specific that provide a type of broad phase detection. I limit my use of Physx to where I actually need it.

Projectiles I use a lot of custom stuff like this to manage hundreds in flight. I have a lot of ships on water where I use custom physics because it's all very specific and I need performance but I don't need the correctness/accuracy. Like boat buoyancy I don't really need physics. Collisions I just need a very basic penetration test and depenetration I wanted more control anyways to get the exact feel I wanted.

And I'm pretty sure I spent less time on writing this myself then I would have if I went with a integrate custom physics engine approach. Plus I know it's all job friendly and I don't have to deal with two entirely different threading models, which you really want to avoid if at all possible.

 

snacktime, normally I would agree with you. But unfortunately, I am not that strong in physics, to create box collision of OBB detection for none-axis-aligned constraint.

Yesterday I did raycasting using job system, which takes into none-axis-aligned constraint. But in fact I fires ray on axis-aligned constraint OBB, by applying equivalent of Separating Axis Theorem. I am happy with that, as it will reduce lot of physics calculations.

I can do and I probably will Space Partitioning. While Detecting Intersection of meshes, become beyond my scope of knowledge, or expertise. Not to mention, making it salable. + on top of that, I need figure out acting forces in between meshes. Probably wont be that hard.

If I had that, I would be super happy. Therefore, I am looking for some alternatives. In this case Physics engine I could apply. If I don't find satisfactory solution, I will back on mesh collision study. But I know, it will take me far more than one night. And surely I am not only one in similar basket.

I will need buoyancy as well, but this is much easier for me, than meshes intersection.

 

Slightly off topic, but http://www.realtimerendering.com/intersections.html basically has all the algorithms you need to do your own collisions on AABB or OBB objects

Just a very useful resource if you're looking at doing this type of thing.

 

Oh yes, that is supper cool references.
Only my hearth says, Oh no, that supper lot of math
I will see, if I can digest through that.

Thx.

 

I wouldn't really trust much of a person who claims Unity's PhysX is GPU accelerated or somehow faster on nvidia gpu's: it's not. It's purely CPU implementation on both Unity, UE4, and probably on all major game engines you can get access to.

This misinformation has been spreading for countless years and seems like there's no end for it.

 

No one here really claimed that Unity's PhysX is GPU accelerated. It was mentioned, to not bother about it.

 

Calm down guys, maybe I was misled by the benchmark result I made and it showed that PhysX was really good.

I'm trying to make an engine-agnostic architecture for 3D shooters. BPE is easy to use, but to me, it's hard to implement a math lib because I'm more familiar with Mathf. The whole solution is feasible, using different ECS framework though.

 

Personally I am not much familiar with Bulet Physics Engine math. Briefly looked at it and that is it. Surly differences in between different engine classes (i.e. math), don't make easier
I did indeed looked briefly into
Entitas (presuming you refereeing to)
https://assetstore.unity.com/packages/templates/systems/entitas-87638
but I have not installed it, since I think it is better to stick with Unity Entity system. Therefore, I have queried here on Bullet solutions with ECS.

I think latest PhysX is really good with latest Unity. But wee look at squeezing even more performance, where possible. In my case
Bullet Sharp For Unity3D
https://github.com/Phong13/BulletSharpUnity3d
didn't met my expectations, realizing is running on single core only.

Yet at the same time, as suggested, I look into the math, on implementing individual methods, like OBB collision detection etc. In fact I know I will be using for that reason SAT, which I have pretty much figured out, but not yet coded.
Among many github sources, web pages and papers that I have looked upon, I found this interesting interactive tutorial.
N Tutorial A - Collision Detection and Response
http://www.metanetsoftware.com/technique/tutorialA.html

Problem I found, researching this topic, is that mostly all discussion are about 2D collisions. Relatively few about 3D.

Never the less, I still think that solution for Unity ECS with
Bullet Sharp
http://andrestraks.github.io/BulletSharp/
is worth a shot, to be provided, by anyone that is keen to do so. At least for benchmarking purposes, if not anything else. I tried import briefly libraries of Bullet Sharp myself, but failed initial attempts. However, I need to admit, I haven't spent too much time on it, to figure out, what is wrong.

 

Entitas and Unity ECS shares the same concept, so layered architecture could be shared. The official one is much more promising, it's still in the early stage though.

The Bullet-family are just wrappers so there should be good. I use BulletSharp on the server-side(pure c#) and it works well. BulletSharpForUnity3D has lots of scripts to let us use it at ease, such as shape, rigid body, extended math, Unity-specific assertion. FYI, Rocket League dev made a great talk about Bullet at GDC, check it out:

If you're looking for an alternative to PhysX, you may see that only a few options are available/ production ready: Havok, Bullet, Newton.

https://github.com/mattleibow/jitterphysics
Jitter is another open source physics engine in C#. Photon integrated it, but customers said its performance was not good. I guess it's still a good start point for study purpose.

 

Actually it was directly mentioned on the quote you posted hence my response but I'll not go on about it, my goal was to just make the record straight so that misinformation wouldn't spread further.

Anyway, back to the topic, if you are after raw perf, PhysX 3.4 will beat Bullet any day for that (PhysX 3.4 will be in Unity 2018.3), even 3.3 is faster in most cases. Core reason for people to pick Bullet over PhysX is never the performance though. Bullet has more permissive license (this isn't issue if you use PhysX integrated on Unity, only if you implement PhysX support yourself), Bullet also supports doubles and cylinder colliders and afaik has more accurate solvers for certain things where PhysX cuts the corners to gain that brute for speed. Bullets source code is also human readable where PhysX sources require you to make lots of notes before even basic things start to make sense, which makes Bullet usually a better alternative for people who want to modify the physics engine internals.

What goes to that Rocket League Bullet talk, Bullet was obvious choice to those devs, but times have changed since on UE side (they used UE3), back then PhysX source code wasn't available so they had to find alternative, the core reasons wasn't that Bullet would have been somehow more superior physics engine, in fact PhysX 3 perf we have today would have helped that game tun run better on weaker platforms.

As additional note, Bullet is a good pick for Unity as you can integrate it yourself for all platforms and you get to modify it. Unity's built-in physics integration is on closed source engine side and you can't change it at all which is core reason I'm currently using Bullet myself with Unity atm. I'm aware I'll lose performance because of this but in my case that's acceptable compromise as I gain additional flexibility and control over things.

 

Thx zhuchun.

Good one.
The Rocket Leage video is very interesting. Haven't seen full from 0 to last minute, since is over 1 hour long, but picked up few moments. The discussion is referring to interesting challenges. Some of them I had already partially solved, other I have never thought about yet.

Havok was something I looked at some point, but there was some reason, I didn't want to pick it up. Newton Ihave seen somewhere, but not investigated it. I looked other c++ light way engines as well, similar to proposed .Net jitterphysics. But mainly to check the source code. One of them was so "light", it only considered box collisions.


rizu,

I am happy for PhysX to get better and better, specially for Unity3D. Specially in recent testing, I found it can run on all 8 of my cores.

Just to refactor reason, why looking for an alternative physics engine, is to find out, if ECS linked with other physics engine, can be more performant than Hybrid ECS with Unity collision system. Which isn't light weight from my understanding, since it introduces many additional features. These are good for OOP of course and Unity approach. But no so for ECS.

Doubles is something, I am highly interested. And maybe others as well. Thx for mentioning it.

In current case, I have built some form scaled down system and multiple parallel worlds with voxel-ish objects, which all worlds are in origin 0 and never move, nor rotate. Also for OOP static collision performance reasons. With tricks of multiple cameras, I can see each world moving from selected world (standing point). Just like looking at planets in solar system. With doubles, I would not need to look into such tricks. Considering, I want run every world at the same time, while keeping at distance. Also, in my case avoiding Unity masks, is something mostly anticipated, since all worlds, have independent collisions. So should not interact. It works on my OOP approach. But wanting to convert it to ECS, when and what I can and is feasible.

Having doubles, I would remove number of such issues, even ECS supports nativelly multi worlds. I could equally now stay with ints and 0 origin for multiple worlds. Mind, I don't need to use Floating Point Origin, since I wanted avoid it from the start.

So having engine with supports doubles including custom in ECS, that is something looking definitely forward.

This gave me some extra thoughts.


At this point, I will try custom approach on Pure ECS and see where I can end up. Then I can consider other alternatives.


The topic is definitely good one.
Thx for contribution.

 

Yes, same here. We need to use physics on the server-side but the Unity solution is closed source, so Bullet becomes our best shot.

I'm also interested in Pure ECS Physics, good luck Antypodish!

 

if you do it yourself using Unity's ECS, job system and Burst, be aware that Burst nor the new Math lib do not support doubles atm. Someone already added double support for the math lib manually a while ago but obviously that wouldn't do any good with Burst optimizations unless Unity makes that happen on their end. So basically you will not get as crazy perf benefits if you write your own custom solvers with new Unity systems if you need to support double precision atm.

You may also want to read through https://forum.unity.com/threads/physics-in-pure-ecs.531716/ (edit: noticed you already replied on the thread earlier so you've been there already)

 

I also read about that post, the dev of Kinematic Character Controller released some promising results. However you may also notice that he has spent YEARS on this field, so it takes time

 

Ah yes, nice one, I haven't seen that character controller before. Probably because I haven't needed. But is indeed neat.

So I wouldn't be surprised, if his physics engine would go to asset store as well. As far I remember, author wasn't sure yet, how he is going publish it (sell, or free).

Never the less, I did play with a demo. A bit worry me, if I can make enough basic simplistic physics engine, which will suffice my needs. I may get overwhelmed. In the end, I would like to move on on my game dev, rather writing engines from scratch.

I dug out the post. Possibly I have seen it previously, but I just skimmed back then, when I was basically starting gripping with ECS. In the end, is only my second week on ECS topic, or so. Along with other interesting aspects, I need to say rizu, you did upset me now
Nah joking
But following to the double - burst lack of current support, is not funny at all. I suppose will be staying with current solution. Only problem, it won't be easy transfer to doubles, once progressing in dev later.

I think I will keep sticking with camera tricks
It works so far well.

 

I've done physics work for several years as well, but it's totally different to be working on physics components vs building an actual physics engine. Building a simple physics solver isn't rocket science, it's actually rather straight forward if you understand the basics of Newton laws and can do the relevant math. Also sometimes simple solvers are enough, most games don't need super specific solvers. Like for example I could do without joints and broad phase myself as I do vehicles suspension on my own code and I don't have that many rigidbodies on the scene that need to interact. When doing simple physics implementation, biggest tasks are really how you detect and resolve collisions as they determine how realistic/glitchy the physics feel.

In future when Unity exposes the new immediate mode from PhysX 3.4 (expect this to happen on Unity 2019 cycle earliest), you could offload specific physics solvers to PhysX while still maintaining your own core physics implementation (immediate mode = bunch of PhysX solvers you can run individually, outside of physics scene). This would still be limited to floats but you could always only send some relational frame to PhysX where you solve things near float origin and then when you get the results back, just translate them to your real double precision world space coordinates etc.

He's mentioned many times that he plans to publish the basis of the ECS physics engine for free on github etc. Unfortunately biggest issue here is that we don't really know if that will happen next fall or next year or if it will ever happen.

Regarding doubles, if you look at https://github.com/Unity-Technologies/Unity.Mathematics/blob/master/readme.md, they mention "Provide double precision types" on "Known issues" so it's on their radar but no promises yet.

There's also request for doubles on that repos issues here https://github.com/Unity-Technologies/Unity.Mathematics/issues/9 where user tbg10101 linked this: https://github.com/tbg10101/Unity.Mathematics/tree/extension. His double support extension is now outdated as Mathematics lib has evolved a lot since but it wouldn't hard to take that users work and upgrade current mathematics for doubles. Main downside will be lack of those burst optimizations for SIMD math.

Here's also thread I made on the topic https://forum.unity.com/threads/double-support-for-burst-compiler-and-new-math-library.520394/ where only official response I got was:

 

Good references. Some of them I am familiar with, more, or less. So by what I read, should not expect Burst double support any quicker than 2019. And perhaps even later.

Regarding physics, well I don't mind learning and trying implement. I just takes my time I wish put somewhere else
It is really good experience however.

I will take your word for that

I think, I have seen somewhere of his response before, that he may consider sell his Physics Engine as well. Then yes, so far he was more in open source direction. But then, I think he could bee good, to publicize github source as it stands now. There are always interested hands to help with bits and bobs. Since he didn't, I may think, he is potentially considering option for selling.

 

When it comes to Physx performance, Unity's wrappers are not really a good indicator of what Physx can actually do performance wise. Unity takes an approach with most of their stuff where they favor making something work for all use cases at the cost of performance. So Unity is typically synchronizing stuff much more often, plus they don't have a proper concurrent api yet.

Having some experience working with Physx directly, I think you would be hard pressed to find something else that would perform better for the same feature set. Whether it's another physcs engine or home made. Comparing anything to Unity's implementation in terms of performance is just not really interesting. Unity never focused on performance really, or rather they did so within a set of constraints that made it impossible to get anything near what Physx is actually capable of.

 

Thing is, we try to implement ECS approach rather Unity PhysX, for simulating physics and graphics, where possible.
If you look at Austin 2017 demo of minions, it proves, it can perform much better than Unity PhysX, with thousands of moving and interacting units at the same time. Where I see in Unity, it struggles hard, with having 5k falling objects, not even including colliders, or even Mesh Renderer.

Yes Unity PhysX provides lots of nice features. I give you that. But some of use, don't need these. Rather looking on performance side, of what we can squeeze from our rigs.

On other matter, I did quite simplistic OBB 2 AABB collision detection. For now with OOP, to test against Unity colliders.
I am not the expert in the area, but atm, having 800 colliding (intersecting) objects, yellds 25-30 FPS a second. I hope to find better solution/improvement on that. Just to indicate, there is no repulsion, or other forces involved, just collision detection.

 

The austin demo doesn't use physics it uses simple local avoidance which is easy to scale.

The trick is identifying exactly what is the bottleneck. 800 colliding kinematic rigidibodies with simple convex colliders doesn't result in the performance you mention on it's own in my experience with Unity up through 2018.1.. It's likely you just need to drop to a lower level approach for whatever it is you are actually doing that's causing the performance drop.

For example you can do bounds intersection tests in a job. Potentially combine that with periodic sphere/box overlap tests over larger areas to limits the number of bounds you have to check. Use computepenetration on colliders intersectiing and then depenetrate manually.

Most of the time the wall I hit is syncing transforms. Collision detection and penetration/depenetration you have a number of tools at your disposal. Assuming you don't need non kinematic, in which case most bets are off.

 

Thats true, but the fact itself, Unity is capable to render and process such high amount of data, is marvelous. It doesn't matter if is physics, or other tricks. As long as do the job. All objects are moving and interacting. However, I am aware, these minions itself, don't have colliers as such.

While I am on Separate Axis Theorem for collision detection, I have indeed further optimization plans. For example I tend to use octrees, to enclose groups of entities. Then for example ray casting would be more efficient, as not need to scan for all entities. Something in terms of space partitioning, used by number of games.

Some good ideas here indeed. I got some basics tools of mine as well. I.e. recent written simple Job based OBB raycast.

Do you mind to elaborate on that issue? Nor sure if I am familiar, of what you mean.


On the side note:
If anybody feels that may be helpful with improving SAT 3D collision algorithm, for AABB and OBB collision detection, I would be mostly grateful. Int the linked post, is script attached.
https://forum.unity.com/threads/looking-for-efficient-obb-aabb-3d-collider-solutions.544439/

 

Physx is the fastest general-purpose physics engine. In addition to this, Unity is deconstructing it over time, we already have https://docs.unity3d.com/ScriptReference/RaycastCommand.html and more features are planned to drop after 3.4 if 2018.3 proves to be stable.

As far as I know an ECS version is planned by Unity but it will have to wait quite a while. I am certainly not hurting for performance with 3.4!

 

Thx hippocoder for dropping in.

Raycast batching is definitely something I am willing to test near future. In my previous post I haven't specified, but I use ECS based raycast as reference, with additional custom extension. I just didn't want clutter on explanation on my application case. Hoever I used job-system-cookbook example of RayBoundsIntersection.unity as reference and starting point.
I am planning on using Octrees, preferably with ECS entities and raycast them, as I can have as many bounding detection, as I need.

Not sure how correct this is, but I have read somewhere today, there is a limitation of active collides in Unity classic (OOP). It may be as well out of date, as I forgot check the timestamp of the post. It was mentioned some around 30k. More like 27k or 28k ? I need find more information, what that exactly means. As active, does it means "sleeping" colliders are exuded from that count limit?

Additionally, since I am using multiple parallel worlds, current mask system in OOP, is pain in backside. Upcoming separate Scene physics, or something like that, could be solution to that. Providing I can run multiple scene at the same time. But in ECS, worlds are indeed looking good.

Yep, read as well recently. This is definitely something to look for.
Atm. I trying to discover best options, before taking major leap, or maybe decide to stay with OOP for physics, and use ECS, for sub systems / AI etc.

Edit1
Posted in March 2018

Edit2
Posted in March 2018

I heard some rumors, it may be even this month. But I wouldn't give much hope, to not get disappointed.

 

Testproject attached. Open BulletECS and run.
It's using BulletSharp 0.11.1 base don Bullet 2.87. It uses all available CPU cores.

Edit: License added (Assets\Stuff\License.txt)

 

That's a great sample, could you attach license to it so people could potentially use it?

 

Done

 

Well, that was a permissive license

 

You are simply superb. Sorry I have not enough thumbs up to share.
Many thanks. And having working scenes, both with BulletECS and PhysXLegacy. Nicely done.

Yep, it is type of the most hard to digest licences ever

I can look into some bench marking now.

 

What is your performance with the example project from julian-moschuering? (Thanks for that!)
I am getting ~ 8-10 FPS with ~2350 Cubes.

By the way, any tips on how to properly debug entities? They are of course not showing in the inspector, so there is now straight forward way to manipulate (like something simply as translate) them during runtime/in the inspector/via handles like we used to from Gameobjects. Are they any tools for that (or a linker for entity-to-gameobject just for debugging purposes or something like that?)

Sorry if this are dump questions, I am still trying to wrap my head around Unity ECS and how to use it properly in the current state!

 

I did check his sample, it's basically using BulletSharp to recreate simple physics scene (so it's not a full Bullet integration for Unity). It also doesn't use Burst compiler for most operations which I think is rooted how the BulletSharp itself has been implemented. To get the best gains, you'd need to make the whole Bullet integration use Burst as much as possible, now we are mainly getting benefits from new job system only.

It doesn't really change a lot in the big picture though, Bullet itself is still the bottleneck on brute force tests but if you have Burst enabled, you usually can barely measure the Unity ends execution cost where now Bullet syncing can take like 2ms when there's a lot of things on screen.

 

Adding bullet features is pretty easy and straight forward. Bullet itself is the bottleneck, Burst will not really change much as the interface will never do alot other than calling native functions.

The main reason for me to follow this path is to get full featured physics in ECS without managed allocations until Unity implements something similar.

 

Atm., for some strange reason, I am unable to run Bullet + EC. Is my Unity, or VS issue. ECS work-ish by itself.
Anyway.

From my initial tests when I had it working, similar examples using Bullet and PhysX, did show indeed, PhysX performs significantly better. And is much more stable. This is possibly due to number of integration bottle necks, as mentioned. I haven't run extensively tests unfortunately.

However, this is very good case study in my opinion eitherway. And since eventually we will get more integrated Unity physics with ECS, the need of use of Bullet Sharp will phase out. Considerably, I think it is still older engine of Bullet, while PhysX has evolved with Unity.

Seams using bullet would be much more valid few years back, before Unity 2017, or Unity 5.x.

 

As I and julian mentioned, main bottleneck is the Bullet itself, you can find small perf improvements on the integration but it doesn't really change much in the bigger scale of things if you do mass simulations. People using Bullet usually aren't doing brute force simulations tho and it's fine for most projects still.

Nobody (I hope at least) will pick Bullet in aim to get better perf for Unity physics, reasons to use Bullet should be totally different.

 

E.g. being able to use physics in pure ECS?

 

Bullet Sharp do not use Pure ECS. Also it uses C# wrapper from C. Then is linked to Unity. So you got few downfalls, if you consider getting gain on ECS.

My idea was simply to check and test physics engines, if we have any good alternatives, while waiting for ECS to support physics.

 

Yes, of course, I meant using physics without resorting to "classical" unity colliders and rigidbodies etc.
(i.e. physics in pure ECS).
Sorry for confusing wording.

 

Have you updated this to run on the latest ECS? I tried it on newest and after fixing the obvious TransformMatrix -> LocalToWorld and eulerXYZ -> EulerXYZ plus fixing that one overloaded function now not having parameters, I get just stack overflow when I try to run the sample.

I did get stack overflow even in the original sample (with the older ECS version) but that happened only after there were a lot of cubes spawned into scene.

Btw, you wouldn't happen to have this Bullet ECS sample on github etc? Would be nice if one could fork it there

 

No. I currently don't work on this and unfortunately don't have time to. It was only a proof of concept to make sure there is a potential solution for physics using ECS without hybrid. Of course you can push it to github if you want to.

 

I "solved" the stack overflow issue. It was that same old incremental compiler messing things up on beta 6-7. I updated it to the latest one from staging and the updated sample runs again with the newest Burst and ECS.

I still do get the following if I try to examine any entity with the Entity Debugger: