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

[Antypodish]

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://discussions.unity.com/t/629112

I have briefly initiated topic on mentioned forum

@Antypodish

Hi Phong.

Got rather serous question, providing you are familiar with ECS and Job System.
Do you think porting bullet Physics to ECS with Job System is feasible?

I think this could have massive bust for the performance, since you don’t use native Unity collision system.

@zhuchun

We’re doing similar things with Entitas, wrapping BPE as a service. BPE is quite straightforward, for general purpose, you only need to expose a few methods(less than 10) to your ECS core. Read more about this architecture and see if it fits you https://github.com/sschmid/Entitas-CSharp/wiki/How-I-build-games-with-Entitas-(FNGGames)

Since you mentioned about multi-threading and performance, here’re 2 facts you may want to know as well.

1. Unity uses GPU accelerated PhysX which means it’s super fast already.
2. Multi-threading/JobSystem are not magic, you have to take care of thread-safe problems. Things may go crazy because you’re dealing with Multi-threading unmanaged code.

You can read the manual and source first, they shouldn’t take too much time.

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

[julian-moschuering]

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.

[Antypodish]

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

@Antypodish

Regarding benchmarking.
I run some extra test.
Similar to one, I did while ago, but this time I have built the project.

Case 1:
I run ExampleRunners with 12x12x20 boxes. Which gives 2880 boxes in stack.
Then drop them on the surface. Performance in both scene and build were almost the same.
But reaching wind speed of 3 FPS ONLY
Single trehaded

Case 2:

While equivalent of PhysX, runs at average 25 fps.
Multi threaded cores, No GPU.

BulletPhysics Limit Issue

Not only that. If I spawning+3000 cubes, Bullet Physics (both scene and build) crashes.
In contrast, I can have on PhysX over 4 times that, and frames fluctuating around 2-3 fps. but no crash.

I have noticed comment in script

switch (benchmark)
            {
                case 1:
                    // 3000

But I thought is number of spawned boxes initially. But not, since there are 8x8x*20.

So is the way, to switch multi threading?
I thought Bullet2.x supports it?

Or I missing something obvious. Maybe switch?

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.

[snacktime]

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.

[Antypodish]

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.

[tertle]

Slightly off topic, but Object/Object Intersection 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.

[Antypodish]

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.

[rz_0lento]

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.

[Antypodish]

@rz_0lento

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.

[zhuchun]

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.

[Antypodish]

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)

Unity ID

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

N Tutorial A - Collision Detection and Response

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

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.

[zhuchun]

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:

It IS Rocket Science! The Physics of Rocket League Detailed

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

GitHub - mattleibow/jitterphysics: A cross-platform, realtime physics engine for all...

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.

[rz_0lento]

@Antypodish

No one here really claimed that Unity’s PhysX is GPU accelerated.

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.

[Antypodish]

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.

[zhuchun]

@rz_0lento

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.

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!

[rz_0lento]

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)

[zhuchun]

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

[Antypodish]

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.

@rz_0lento

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.

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.

[rz_0lento]

@zhuchun

However you may also notice that he has spent YEARS on this field, so it takes time

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.

@Antypodish

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).

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.

@Antypodish

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.

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://discussions.unity.com/t/693807 where only official response I got was: [quote=“xoofx, post:2, topic: 693807, username:xoofx”]
while it is not currently planned, we may also provide support for fp64 SIMD types and math instructions
[/quote]

[Antypodish]

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.

@rz_0lento

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.

I will take your word for that

@rz_0lento

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.

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.