Rotating bodies don't collide correctly

Hi, I’m a newbie at BabylonJS, and I’m hesitant to call a ‘bug’ when it is likely my own ignorance. But I’ve worked at this for two days, have read everything I could find, and still can’t make it to

I’m trying to bounce oblong spheres with a physics engine. It works perfectly from every axis when the sphere has not been rotated. So the physics engine understands that spheres have (a,b,c) dimensions. (change the shape of the sphere and the top collision still works every time).

But add a little rotation and the collisions no longer take place at the right time. The physics engine understands the rotation and correctly transfers angular rotation from one body to another. But it is as if the physics engine rotates the mesh while the imposter sphere itself doesn’t rotate.

Here’s a demo:

The top pair have no rotation.

The middle pair collide exactly at the same time as the top pair.

The bottom pair is like the middle pair, but using impulse to set angular velocity.

Thanks in advance.

Pretty sure Bullet/Ammo can handle rotations. I’m going to try to figure this out myself. I’ve pulled down the BJS code from Github. It’s crazy hard for a newbie, but that’s how we learn and move up.

What do you think about the idea to use transparent spheres at the oval objects. I think it is easer to detect sphere-collisions.


neat idea, but lots of setup. collisions of rotating objects should just “work”. let me dig into Bullet/Ammo.

also, if the spheres don’t collide but slip past, two objects could get ‘hooked together’.

also might be very slow if lots of spheres. but the idea is interesting. might be easier to distribute a set of approximately evenly-spaced points on the surface of a object (maybe with a Fibonacci lattice?). it’s easy to check whether a point is inside or outside a regular solid, but slow to check EVERY point.

Nature is the best teacher. It does not use solid compounds, but builds matter from atoms that are “connected” by electric fields (probability spaces).

On my way home i came up with the following idea how to check complex structures for collisions.

How would you do that in the real world?

… with light!

Place a point at the highest points of a homogeneous or less homogeneous geometric shape from where light rays are emitted at 45 degrees angles. if the light hits another object, you know that there is a danger of a collision. the shorter the measured light distance, the greater the probability of a collision!

I think, if you chew on these ideas a bit, you will surely come to a more efficient method than checking the overlaps of meshes and the animations will run much more smoothly!

Thanks Necips. But I don’t want to write my own physics engine, just want to dig in and figure out what is going on in the Ammo interface. And learn from studying other people’s code.

Were you driving home in a vehicle? If so, I’d check it for exhaust leaks, if I were you. :smiley:

  1. How many light/photon-receptors intersect functions can you find in BJS? zero. :slight_smile: Okay, maybe ray-casting is somewhat similar to light rays/photons, but not much.

  2. I’m not sure real life uses photon-receptors to do collision/intersect-checking, either. Did you read about some new discovery? Do tell. :slight_smile:

I think real life uses molecular bonds, right? I think real collisions happen at a molecular level, and not really at an atomic level. But, I’m sure no expert in such things. Google knows more, I bet.

Ok, back to actual issue, the physics impostors are not sizing/scaling to fit the elongated sphere. There’s a bug somewhere… in Ammo plugin or physicsImpostor classes.

Testing playground. I changed from MeshBuilder.CreateSphere… to Mesh.CreateSphere… and tried to use scaling = size, instead.

Lines 92/93 - SHOULD work, but they crash the playground or something. Error: uncaught exception: abort(20). Build with -s ASSERTIONS=1 for more info.

Line 85 (the scaling)… seems to be ignored by the lines 87-90 impostor creation (just like the MeshBuilder sizing method gets ignored). hmm.

Lines 95-99 was a failed attempt to wait for “impostor init” a bit longer… before asking it to reshape itself to egg-shaped. Failed. :slight_smile:

Ammo seems to be making a perfectly spherical impostor, no matter how we try to make it egg-shaped. I hear @trevordev is a primary contact on such matters, so maybe he will visit soon and try to help. Stay tuned.

Here is a small (a bit faulty) experiment that confirms my thesis.

By “light” I mean the measurement of a straight line (light-ray) between A and B.

I don’t want to add more of my crazy ideas to tom’s thread. sorry, tom. :slight_smile:

Tom, as a temp work-around, using the MeshImpostor seems to work. BoxImpostors also work, but not as well as MeshImpostors.

I doubled the linearV’s to 2 and -2 for a little more effect.

Possibly, Ammo doesn’t allow non-uniform-scaling/elongation of sphere rigidBodies. Not sure.


Thank you Wingnut !! That’s exactly what I expected. Amazing and wonderful that you took the time to find a workaround.

But I’m still going to poke at this and see if I can fix the problem (and learn as I go). I’m just figuring out how to build the environment and run the VScode debugger (I still cannot compile the full system without errors, but I can get my colliding asteroids working).

Thanks again. I’ll report back soon.

1 Like

My pleasure… and may I say that it takes a special kind of “chutzpah” to keep digging for more information… after a work-around solution is found. Very cool! I look forward to your findings/reports, and I hope you are able to maintain your beefy stamina.

I learned about MeshImpostors back when CannonJS physics engine arrived at BJS. It was a God-send for making a terrain heightMap… be physics-active… a highly-used feature in webGL, especially for Perplexus-like games, and for golf games.

Speaking of golf, with CannonJS physics… MeshImpostors can ONLY collide-with sphereImpostors. Just for fun, let’s try another test… to see if AmmoJS has the same limitations:

Here, I added another argument/parameter to your createOneAsteroid() function… the type of impostor to use.

So, in this test, A1, B1, and C1 are all meshImpostors, and A2, B2, and C2 are boxImpostors.

As you can see… all is fine. AmmoJS meshImpostors don’t suffer from the same “sphere collisions only” limitations as CannonJS. YAY! Ok, party on!

Well, here’s the “first answer”

Bullet / Ammo’s ‘btSphereShape’ is always only a uniform sphere for performance reasons. There is no equivalent for a Babylon-style ellipsoid. Uniform sphere collision tests can be done in nanoseconds, and that’s Bullet’s priority.

Of course that’s not a solution, and others have found the same problem. For example: Ellipsoids - Real-Time Physics Simulation Forum

The second answer, thanks to Wingnut, is a workaround using Meshimposters. That may become very slow when the number of spheres increases.

So the third answer is to use ‘btMultiSphereShape’ and populate it with a few spheres. We can create an approximation something like this but expanding against all three axis.

It might be fun to implement multiSphere and check the performance of using a 9-, 12- or 15-sphere ellipsoid vs the meshImposters approach. Or even make the number of spheres variable (like IcoSphere). I think multiSphere will be MUCH faster, indistinguishable from a uniform sphere. We can also test whether the Babylon sphere is uniform and fall back to ‘btSphereShape’

At a minimum, we should test the sphere in ammoJSPlugin.ts and slip in a meshImposter instead of a sphereImposter if it is an ellipsoid, so that Babylon works properly. The coding for MultiSphere doesn’t look difficult, need to define ‘btMultiSphereShape’ in AmmoTypeDecls.ts and then fix the sphere code in ammoJSPlugin.ts. Of course, everything looks easy until you try it.

I’d be happy to give both approaches a try and run a performance test. Comments?


Glad you managed to find a workaround to this issue

I created this issue to try your recommended solution AmmoJS support ellipsoid · Issue #6376 · BabylonJS/Babylon.js · GitHub Definitely would be nice if you want to tackle it, otherwise i can try taking a look today/tomorrow so let me know

Yes, to create an ellipsoid you can use the btMultiSphereShape with just one sphere and set the non-uniform scaling on that shape, using setLocalScale(…).

from Ellipsoids - Real-Time Physics Simulation Forum seems like another thing to try

1 Like

I will tackle it. but it may take me a few days,

I’m learning TS by studying BJS which is awesome. but I am baffled by the tool chain and multiple opaque transpiling steps for my local build. Finally figured how to configure Babel to handle decorations, and now I’m stuck on some island that doesn’t know about get-set properties. I need to build a test case for my configuration ?!? I suspect everyone has to start this way.

The ammoJSPlugin code needs a bit of love and some careful testing. I’m good at that and would love to work on it. Real soon.


When I look at the status of the Github Pull Request Update Ammo.js library and AmmoJS plugin to support ellipsoid then I get the impression that the logic for Ellipsoid as a single solid impostor/shape has been implemented in at least Ammo.js Physics Engine. Is that correct?

How can I choose the Ellipsoid (which is not a stacked Spheres but a real solid convex Ellipsoid) as the Impostor now for a Mesh?

I don’t see a EllipsoidImposter type defined in the API: PhysicsImpostor - Babylon.js Documentation Do I need to use SphereImpostor with some special option instead? :slight_smile:

I am looking for a way to translate the ellipsoid & ellipsoidOffset properties of a Mesh that the BabylonJS Collision Engine uses to the same settings but then for the Physics Engine.

A link to a working demo playground will do.


Looks like you simply need to use a sphereImpostor with none homogenous extend size.

Ping @Cedric for confirmation :wink:

Yes, @sebavan is right. Any none homogenous extend sphere will create a btMultiSphereShape. So it will be like creating an ellipsoid.