Custom Triangle Mesh for collision shape animated character

I looked in the docs, and all I can find is shape->SetTriangleMesh(tutorialCollision) for static mesh. Is it not possible to make a very simple collision mesh for a character, and use this instead of a sphere or box or capsule.

Thanks

Hi, GodMan!

The clue is in the name: static mesh - it’s typically not animated. That does not mean it is impossible to assign a dynamic mesh at runtime, but it is impractical to modify a physics mesh in realtime using today’s consumer-grade technology.

A more feasible approach is to provide an armature of simple collision hulls (they can be detailed meshes, or primitives like in this screen shot). We can animate the armature, by connecting it to the model’s skeleton. This is just like a Ragdoll, except that these rigidbodies are “kinematic” - they are being driven by animation.

These ragdoll bodies are using a different collision layer / mask than the outer hull, meaning that the number of collision tests required at runtime remains reasonably low. The collision mask ensures that ALL collisions between bodyparts are disabled (not just those between directly connected bodyparts), and no joint constraints are required - we rely on entirely on the animation of the skeleton.

When basic shapes are not an option for you, dynamic collision shapes can be convex hulls ; simply use SetConvexHull instead.

If I use a simple model which is basically some smaller hit boxes, and use convexhull does this behave like the skinned mesh “animated model” or do I have to assign them manually to each bone.

ConvexHulls “cannot” change shape, if that’s what you mean.
If you’re looking for pixel-perfect sniping (for instance) you might be better off using octree raycasts, btw. For something like a ragdoll you’ll need separate shapes.

So this is what I’m trying to do. I was trying to use a very very simple collision geometry for an animated character.

Yes, you can use your own mesh shapes for the physics hull on your animated character, just noting that they won’t deform correctly when the character is animated. If you can live with that, then yeah sure, you can provide your own shapes that closely match your geometry. There’s a few more rules, such as, the shapes must be convex. If they are not convex shapes, they can always be split into convex shapes. But know that Bullet physics does not like concave shapes to move around at runtime. So think in convex terms.

Well what did you do in your screenshot where you have individual pieces?

I see. I took at look at the Rag Doll Sample. I will see what I can come up with.

I used a bunch of primitive convex shapes - mostly capsules, but theres at least two box shapes in there too - I was able to get a “close enough fit” without actually defining any custom geometry.
For each major bone in my skeleton, there is a corresponding bodypart.
For things like the spine, I simplified the number of bodyparts / active bones, thus, there is not a strictly one to one relationship between bones and bodyparts.

So, in Urho3D, when we load our animated model and instantiate it in our scene, there are a bunch of nodes with names matching our skeleton bones. Before playing any animations, we are in the “bind pose” … We attach rigidbody components to those bone nodes, and set the rigidbodies to “kinematic mode”. Now the rigidbodies will automatically be animated when we play animations on that character - but we won’t get any collision responses on our armature because its in kinematic mode. If we want the armature to respond to collisions, we need to do a bit more work.

I used the Ragdoll Sample as a guide to help me construct my armature, but I did not leave the rigidbodies in “dynamic mode” (aka ragdoll mode). Making them kinematic means they get their world transform from their parent node, which in our case means a bone node, which in turn, is likely to be animated.

I separated the hardcoded data from the sourcecode, and moved it into an xml file per character:

When this xml file is read back in at runtime, the data completely informs the code how to construct the armature for that character - this is my understanding of a “data-driven approach”. Note that our code requires no knowledge of the bone topology - this will “just work” for any skeleton, from an octopus to a dinosaur. We just need to craft the right data!
Since the names of bones might differ between character models, we are specifying the bone names explicitly in the per character data, so that is never a problem. Oh yeah - the position and rotation values are relative to the space of the parent node , ie, “in bonespace”. We use them as “offsets” to position and orient the bodyparts, relative to their parent bones, IN THE BIND POSE.

I have data for joint constraints, but I don’t need any joints until I want to switch from animated to ragdoll mode… and when that happens, I may choose to set only part of the armature to ragdoll mode, and leave the rest animated…

What should this character collide with? Is it for actual ragdoll purposes? If not, it’s likely for there to be a more efficient solution to your problem.

In my case? The provision of ragdoll bodyparts was an experiment, to see if I could derive momentum / acceleration stuff at the moment in time when we hand over control from animation to physics. I needed a way to carry on, from the animated state, to the physically plausible result state.
As a bonus, I found myself able to discern which bodypart was being hit during attacks (and where, and at what angle), and therefore implement plausible response.

Which causes clashes between dynamic and animated-kinematic bodies that are hard to fix. Therefor I’m trying to figure out whether a two-state solution (capsule & ragdoll) would maybe make more sense for @GodMan ’s sake.

@Modanung I want something a little bit closer to the mesh of the character like in my pic above, but something still really simple and fast. I just need the collision for the characters environment which is mostly static, and a few dynamic things. I do not currently have ragdolls on the characters.

You may want to stick to spheres, capsules and boxes for the shapes where feasible to save a bit of resources.

So could I use capsules for the limbs and maybe a box for his head. Similar to the ragdoll demo? Using bullet physics shapes.

I certainly did. It’s not the only option, but the result is “good enough” for me.
The “good part” of using convex physics primitive shapes, is that you get “curves for free” - the shapes are usually only expressions of mathematical formulas describing the surfaces (capsule is a perfect example), although the low-quality physics debug drawing could lead you to believe otherwise - you have more fine detail on curved surfaces, and more plausible physical outcomes, using simple physics shapes than you can generally achieve with a triangle based mesh.
I just wish that Bullet supported “ellipsoids”, where we can set the radius for the capsule different at each end. The tangent is naturally derived in such a case, and the mathematical expression of the shape is not difficult to cope with.

I still use an outer capsule hull around my animated ragdoll - but the collision group and masking values are set up to ensure that the bodyparts can’t hit the hull, given that they have entirely different purposes. I’ve extended (but respected) Bullet’s default enumeration for filter groups (layers in urho), and probably already have more than I need, but I note there’s not much fuss made in the Urho3D Samples, or in Bullet, about exactly how these are intended to be used. I’m happy to share something back in terms of how to effectively apply collision filtering in Urho (ie in Bullet), if I felt it might end up being posted in, or referenced by a FAQ for future reference, and not lost in a haystack.