What's with Static Entity Collision Hulls?


Continuing the discussion from Random Picture Thread:

I keep seeing this written by different people that they have a hard time determining how to make a collision hull for static entities. It should be straightforward.

Bullet is supposed to handle collisions against static tri-mesh with decent efficiency. That is what btBvhTriangleMeshShape is for. Is that not enabled here? With tri-mesh collisions, especially for planar meshes aka terrain, is should be fairly straightforward to make a collision hull because it can simply be a decimated version of the mesh model (this assumes the normals are correct). The reduction in triangles is done to reduce Bullet’s computational load.

Only dynamic objects need their physics shape defined as convex hulls. Bullet is supposed to handle the collision of dynamic convex hull assemblies against static tri-mesh quite well.

Note that terrain ‘planar’ mesh models should still be modeled as a closed volume. Though Bullet can handle collisions against a tri-mesh, should the object go through it because of high velocity, only a finite volume mesh will make Bullet expel the interpenetrating object. In the vehicle work I did for InWorldz, I also had to add code to assist the expulsion by adding an impulse force against the gravity gradient when full ‘terrain’ penetration happens. Sometimes PhysX (the engine used there) would choose to expel the object in the other direction.


It would be great if the hifi interface client could automatically generate the collision shapes for complex geometry. Using btBvhTriangleMeshShape would be one way to do this for a some meshes. The limitations of this strategy were already mentioned by Balpien.Hammerer but I’ll itemize them again:

(1) btBvhTriangleMeshShape can only be used for static objects that do not move.

(2) It is easy for dynamic objects to tunnel through or snag on objects that use a btBvhTriangleMeshShape.

The first problem adds a bit of complexity to the UI – if someone were to use the mesh shape then the object could not be set dynamic and we’d have to communicate that fact to the user: “The ‘Dynamic’ checkbox is disabled because the object is set to use a triangle mesh shape”. Not a blocker, but a complexity whose existence would be for an idiosyncrasy of the physics engine that happens to be used under the hood.

The second problem would introduce sometimes subtle and mystifying bugs. This would not necessarily a blocker for the short term (if the benefits outweigh the problems)… but it would eventually need be fixed and it might cause as much consternation as the difficult process of generating collision hulls manually.

What would a long-term solution look like? If only the system could magically compute a good optimized approximate collision shape no matter what mesh that was thrown at it!

This is technically possible to do, but would require significant work. The VHACD library is pretty good at computing convex hulls… except that it not able to do it real-time. Depending on the mesh and the parameters used in the algorithm it can take several seconds to several minutes to convexify using today’s CPU’s. If the work can be given to a GPU the process can be sped up by as much as 200X, however that still isn’t quite real-time: three seconds is much better than ten minutes, but blocking the render pipeline for three whole seconds would not be good.

We could…

… do the computation in another thread or…

… pass the job to a super computer on the cloud that sends the results back over the net or…

…require that the collision hulls be precomputed and stored in downloadable assets (how it currently works, but this could be made easier).

I’m curious to know what people think. Should btBvhTriangleMeshShape be used as a stop-gap feature until we get around to implementing a better solution? Should we start working on on-the-fly convexification tools now before some of the other things to be done(*)?

(*) Such as (in no particular order):

(A) More correct collision shapes for avatar limbs.
(B) Vehicles and constraints (hinges, springs)
© Scale and protect the physics simulation performance.
(D) More correct mass properties (center of mass, inertia tensor) for existing objects.


This is known art. It’s even open source known art.

I invite you to visit Inworldz.com where the terrain is a trimesh. There are no punch-through effects there. Simple methods fix that (make the mesh bounded, turn on CCD). I mentioned how to do it in my previous post. SL, InWorldz, and OpenSIM all model objects as tri-meshes and they submit a somewhat quantized (decimated) mesh as the physics shape to their respective physics engine (Havok in L,PhysX in InWorldz, Bullet inOpenSim). In those virtual worlds, when converting to physical there is an on-the-fly conversion to convex hulls (havoc in SL), VHACD in InWorldz, cant recall in OpenSim. The way we did in InWorldz was to cache the generated convex hulls in the region simulator to speed up subsequent conversions to physical (aka dynamic). With mesh models there, people can also specify the physics shape, a convex hull assembly being one method.

Here things are a bit different but making something that will be dynamic could still be done the same way, although for now the system could require the maker provide a convex hull set that if not present makes the dynamic object collisionless. Trying to flip a 150K vert static object into a dynamic shape is going to bring Bullet to its knees if the shape is complex.


The good news, is that since High Fidelity is open source you can submit a PR that implements the behavior you’re asking for, and we’ll gladly review it for inclusion.


For a core feature, it’s best to hire someone to do it. I don’t code for free. I think HF has someone on physics, Andrew? Hand him this: https://github.com/InWorldz/halcyon That implementation is PhysX based. He can look in OpenSim for the Bullet implementation.


This is Andrew Meadows. Leviathan is my alt account. Maybe I should make a new account for these forums that looks more official. In any case…

Sorry, that post was a bit wordy. Let me restate in simpler language:

Yes, we know how to fix it, but (a) maybe it would be better to try for a more correct long-term fix rather than bothering with btBvhTriangleMeshShape (this happens to be my preference) and (b) we have a bunch of other stuff we want to work on so where does this one rest relative to the priorities of the others?

BTW, in the past large btCompoundShapes were much slower than btBvhTriangleMeshShapes for certain things, however we made a patch to our Bullet that speeds them up (hmm… I need to get around to submitting that patch back to Bullet) so that isn’t an issue for us – once we have the btCompoundShape of convex hulls they should work fine.


@leviathan If you go to your account preferences, you can set a title like I have next to my name.


You can avoid the entire on the fly convexification project by supporting static tri-mesh.

About the only way I can see myriad compound convex hulls outperforming tri-mesh in Bullet is if your patch builds an octree for the hulls. This is what Bullet (and PhysX) already does for static tri-mesh. But even if the results are par or better, now you have an architecture that demands everything be physics represented as convex hulls.

Khaled’s VHACD is crazy slow. His 2.0 version is better. It works tolerably for hundreds of hulls, and gets insanely slower above that number. Nancy Amato’s ACD looked promising but I never saw source code published. https://parasol.tamu.edu/dsmft/research/app-cd/

Besides you are not thinking past static scenes. Yes, game designers will make and bake their static scenes. They will take the time to spend many minutes creating the CHs. But, the results are fully static. Though that may be fine in a cooked game, it does not work well in general virtual worlds, especially in one where you want people to create things on the fly. Thinking of editing ‘terrain’ inworld.

So, no, don’t work on HACD tools when supporting static tri-mesh will be much quicker to do and yield wider applications. As for the list, my take is set the shinies after fundamentals, so:

Add static tri-mesh support
Fix collisions in general
Scale and protect the physics simulation performance.
More correct mass properties (center of mass, inertia tensor) for existing objects.
More correct collision shapes for avatar limbs.
Vehicles and constraints (hinges, springs)


I choose to “like” this post as I support your stake in the physics realm in much the way I supported @Menithal relay the community demands on Avatar Standards. It helps to have one person that ideas can be channeled through; and allows the devs to triage back and forth with the community easily.

I really appreciate what you’re doing here @Balpien.Hammerer someone needs to. :slight_smile: and it seems like you understand the situation best. When it’s ready, I’ll need to buy a helicopter from you. :smiley:

related: I have only been able to render physics hulls in my mini-mirror for the last 2 months. what’s up with that??? i cannot see them in the primary render on activation.


Excellent, a prioritized list. Thank you for you vote and feedback.

Unfortunately “Fix collisions in general” is to vague and must be stricken from the list. You’re welcome to itemize that one into sub parts. In fact, it seems to me that some of the other items there already fall under that umbrella.

More correct shapes for the avatar is not a shiny so much as a fundamental part of what we’re going for. We want to be able to reach out and whack or grab objects with our hands. We want the avatars to be able to hug, shake hands, or punch each other in the face. It would be new and it would be compelling. Certain very influential members of the team put a high priority on that item.

  • collisions are not sent to a script in an antity when an avatar collides with said entity.
  • When the avatar collides with an entity that is a small distance above the bottom of the avatar’s bottom physics shape, the avatar does not step up onto said entity (aka a step).

There are others like this discussed in several other places in these forums.


It comes after fixing avatar to entity collision events. That fundamental bug needs to be fixed first before those cool shapes will generate a collision event. And yes, having articulated avatar physics shapes that approximate the limbs and bones is awesome,an awesome shiny.


@Balpien.Hammerer, PR-8070 is an experiment with btBvhTriangleMeshShape. We might keep it if it works well.



Hi @leviathan can you quickly discuss (just a few lines please) what this means for objects already assigned a phull, and objects not assigned a phull?

I will not be a crying milk-baby if you guys remove support for phull; (i learned a lot of Blender this way) I’m just wondering about the future of things. If it is truly easier for me to ditch the custom phull and just let btBvhTriangleMeshShape work it’s magic, I’m fine with that.

Can you highlight a few expectations for us? Thanks.


@AlphaVersionD, Bullet supports a static triangle mesh shape. PR-8070 is a simple test implementation so we can see how well it works.

To use it you would not bother giving the entity a “Compound Collision URL” but would instead select “Static Mesh” as the shape type. The object should then be immediately collidable exactly like its rendered triangles (we do no mesh decimation yet).

Things that use “Static Mesh” cannot be set dynamic in the physics simulation. I didn’t lay down any logic in that PR to prevent overlap of those two features so unless you’re curious about undefined behavior: don’t combine them.

The triangle mesh shape collides using infinitely thin triangles, so it may be easier for moving dynamic objects to “tunnel through” the mesh and arrive on the other side (one of the things we want to test), or to just collide incorrectly and “snag”. We expect Bullet to have trouble executing its “resolve penetrations” logic when a dynamic object gets embedded into a triangle mesh shape since the “out” direction may be ambiguous.

What this means for you:

(1) It will probably work well for avatar capsules walking around on a big cruise ship.

(2) It might not work well for a pile of dynamic chairs colliding against the cruise ship’s deck.

Making things collide correctly by default is our ultimate goal but I think it will take a while to get there. We’ll definitely continue to support the “collection of convex hulls” shape. In fact, I’m about to begin exploration to see if we can build suitable hull collections on the fly for most models.


I’d love to try this as soon as it is made available. I’m of little to no use without a pre-built installer. :frowning: Sorry.


I am testing this PR build soonest, and thank you for making it available. If I find any problems I will certainly log them in detail.

However, I honestly do not know why this negativity is said about tri-mesh over and over again. So, I have to get a bit honest and unvarnished about it.

I need to point out that this description of infinitely thin triangles and tunneling is something the HF boyz do not understand. If a triangle mesh is properly manifold, has a volume (meaning it is a closed mesh), and if CCD is enabled then no tunneling will occur. It does not happen in SL, it does not happen in OpenSim, it does not happen in InWorldz. I’ll use InWorldz as an example because I (and another) wrote grid code for it and I made it work extremely well. Any object that is not dynamic is, by default, represented in tri-mesh. Even the terrain there is modelled as physics tri-mesh. Now granted it is using PhysX, but the myriad OpenSim grids do use Bullet and they too do not have problems with tunneling on tri-mesh.

If there is a problem in High Fidelity it means Bullet was not configured properly. There is one difference between PhysX and Bullet WRT CCD. In PhysX, CCD is a global setting - it applies to everything. In Bullet, CCD seems to be an object/entity property, so that means it has to be enabled for every entity introduced into a scene (when rezzed). Perhaps that is not being done here in HF?

If a pile of colliding dynamic chairs fails to work here against tri-mesh, it is a configuration problem. Or, worse, it is a Bullet deficiency because it absolutely does not happen with PhysX. We do need to determine that soonest, although I’ve never seen that problem in Bullet based OpenSim grids. Now the HF devs can keep trying to manufacture consensus that this is indeed a bad thing to do, but all you need do is go create a pile of dynamic chairs on OpenSim, SL, or InWorldz and see how well that works there.

So specifically to the HF devs, you need to go to InWorldz, OpenSim or SL. You need to see for yourself there is not the problem you keep mentioning. Also, the interpenetration issue you mentioned is quite real but, unfortunately, it applies to an assembly of convex hulls just as much as it does to tri-mesh. In that situation PhysX does better than Bullet, but not massively better. There is a nice hack that if the physics engine gets lost for too long resolving inter-penetration, external code takes over, and slides the object outside the bounding box of the object.