The question is related to importing gltf/glb meshes. I have a use case where I would like to import semi low polyish meshes to Babylon. The more I’ve searched the more I’ve been thinking of a normalized way of doing this. Many examples seem to just create the physics impostor collision meshes by hand with primitive shapes and I suspect this is required if the mesh is too detailed. However, I keep wondering if there is any to none actual performance hit using meshImpostor with low poly meshes? This way you could just slap the mesh in without having to do the hassle with some scaling, reparenting, etc…
^ Here I just have two really different models, one is almost cylinder and the other is a palm tree that has a weird shape The performance seems pretty adequate when there are <100 objects in the screen at once… I’ve only added the mesh impostor to the gltf/glb model root object, and it seems to be working…
So the actual questions:
Do you see any problems with this method of just adding the meshImpostor to the root mesh, if the models are not that detailed/high poly?
How to enable physics debug mode I seem to not see the meshImpostors in the playground, or it might be that I just haven’t found the correct button…
If meshImpostor is too performance hungry, how would one create impostors in a normalized way for most 3d objects… Assigning primitives seems like a lot of work
The best method is the one that works
If the meshimpostor fits your target regarding CPU and memory usage, then everything is fine.
I remember for Uncharted game on PS, artists put simple box for collision, a lot of them. Box collision is faster and uses less memory. It also means a lot more work. No magic solution here. Aim for the simplest and rafine if you have problems.
I am looking into the same topic. Right now I create glb model with additional boxes/spheres invisible meshes just for physics imposters. I optimised my model mesh to low poly that its getting close face count to the imposter mesh so wondering whats the point. Especially that sphere imposters around the corners need to be detailed enough for the collisions to work properly. Now I am thinking just to optimize my mesh so its more dense around the corners and just use it as an imposter without extra shapes. I am not sure if there is any extra penalty when you use mesh imposter vs ie. sphere with the same amount of faces.
Has there been any performance testing on this subject with low poly models? If you put a mesh impostor for a simple box mesh, is it the same as putting a box impostor in the same box mesh? Just as @kri100s said here:
Also kind of curious if the mesh impostor simplifies the impostor mesh or is it the same as the actual mesh? For some reason the mesh impostors don’t show up in the debug view in the playground, as seen in the example that kri100s made: https://playground.babylonjs.com/#S7E00P#138
no, a box collision detection is faster and uses less memory. It’s basically just a matrix. As a mesh impostor, even with a few triangles is a matrix, all the geometry and spatial partioning datas.
If this is a case, is there a solution to give a box/sphere/cylinder impostor easily for any glb/gltf mesh, if you just want to use it generically? Like just give the boxImpostor for the root mesh, that it would use the bounding box of the child meshes? Doesn’t work straight out of the box at least… https://playground.babylonjs.com/#S7E00P#139
And there is still the case that why can’t we see mesh impostors in playground?
I’m pretty sure BabylonJS automatically creates a Convex Hull shape if you have a dynamic, non-zero-mass physics impostor. So barrels and palm trees are in fact Convex Hulls, where as your static ground and wall are both MeshImpostors/TriangleShapes. Static physics bodies usually benefit from using triangles, as smaller shapes are usually quicker to run through the narrowphase.
AmmoJS/Bullet uses GJK as its narrowphase(And EPA in case of inter-penetration), and only needs the three vertices of the triangle as support points. If you used a box instead, you would have to test 8 vertices. Using SAT gets even worse with bigger convex shapes, as with a triangle you have three vertices, three edges and a face to test, but with a box, you now have 8 vertices, 12 edges and 6 faces.
With dynamic physics bodies, the same thing more or less applies, and as you are already using a convex hull, I don’t see any need to manually decompose your meshes into a compound selection of primitives. But if are going that route, spheres are certainly the quickest to test against.
I’m not sure whether Bullet uses bodies or shapes in it’s broadphase, but if it’s the latter, having a single convex hull might prove faster in updating the dynamic AABB tree, than having a lot of smaller shapes.
In other words, I think what you’re doing now is good enough. Only think about changing something in case you actually encounter performance issues.
I’ve managed to create a physics object with box impostors pretty easily using a collider mesh generated in Blender. I’ve created a “collider-cube” and “collider-cylinder” meshes that will be used as reference when creating the impostors. I also hide these from view after importing.
I’ve never seen that before. Cans are really unstable. Sometimes they accelerate for no apparent reason
I tried to tweak gravity/friction/… anything I could without a better result. I have no idea on what’s happening.
Can it have something to do with the NoImpostor?
Right now the there is the parent/child hierarchy of:
__ root __ ← NoImpostor
Cylinder ← CylinderImpostor using the collider-cylinder mesh as a collider (has a parent of __root __ )
collider-cylinder ← the collider that is hidden when loaded (has a parent of __root __ )
Seems that the cylinder gets a bit speedy and… Wait a minute, does this have something to do with the plane width/height and its subdivisions? https://playground.babylonjs.com/#BEFOO#1434 At least when increased I can see the erratic behavior at once
The performance seems pretty adequate when there are <100 objects in the screen at once… I’ve only added the mesh impostor to the gltf/glb model root object, and it seems to be working…
I seem to not see the 
