Best approach in terms of rigging body parts

I’m having a great time exploring JME, but I’m finding there are so many ways of doing things it’s easy to get a bit lost (especially if you don’t have a background in animation or game development).

Therefore I was hoping to get some advice on the best way of handling articulated models, and whether to break them down into separate body parts and deal with them in code or whether to rig it all to an armature in Blender and import it somehow.

For background purposes, I’m building a game/simulator featuring a hexapod robot with six limbs and 18 degrees of freedom.

I have my own code for calculating walking gaits and handing Inverse Kinematics. All the limbs are rigid bodies, and I won’t be doing any mesh deformations or keyframe animations.

Having read the tutorial on Ragdoll Physics and various joint types, collision shapes, rigid body controls etc, I can see that I can just load the various piece of the robot in as resources (coxa, femur, tibia and body) and wire all the joints up in code. This seems to work, but is quite fiddly to get right (ok, so I have more of a jellyfish than a hexapod at the moment but I think things are going in the right direction and I’m having a great time playing with the physics engine).

Is this the best approach?

The reason I ask is that I’ve also looked at creating armatures in Blender, which can apparently be exported and loaded into JME. I think this is more applicable for doing keyframe animations, but is possible to manipulate the joints directly at runtime by doing this? At some stage I would like users to be able to load their own meshes, so being able to load in a complete rigged model would probably be easiest.

Any advice gratefully received.

seems like everything you need is:

well there are some examples in RAW JME tho:

But Minie have much more features about it, and not everything was added into core.

Thanks for your reply.

I had looked at the TestRagDoll example, and I based my approach on that. All working (well mostly) with Box geometry as a placeholder.

My question was really how to handle the mesh resources. I assume I would need to include separate meshes for each body part, and specify the local coordinates on each of the two meshes I’m joining, (relative to the origin point in Blender).

I wondered whether there any best practice to doing this, is terms of where to place the origin in Blender (i.e at the bottom, in the centre of the bit to be joined to the child etc) and how they should be rotated. I read the exporting from blender article, but that seemed to be describing complete models (and recommended that the origin is at the base of the model).

These aren’t big issues, but if there is a convention to use I’d like to understand what it is and use it.

Equally, I saw it is possible to export skeletons in Blender and wondered whether there was a way of rigging the whole model in blender and just importing it as one model (and being able to access all the joints in code).

I hope that makes sense. :wink:

but model can be made of multiple Objects(Geoms in JME) or separated meshes.(for same skeleton)

Generally skeleton require vertex group thaty have “Weights” for related Bone.

So it can be done easly using separate Geoms, or harder, merging Meshes with their related weights into single Geom.

For example in my game, i have character that can have multiple armors/helmets/hair/etc/etc. it all uses same skeleton, but dont need to.

and if you want add “new bone” for existing skeleton dynamically in-game, it would require update JME skeleton data, i belive Minie had some example of creating custom skeleton.

Sorry if I’m being obtuse, but just so we’re on the same page: My objects/Geoms represent bit of a physical robot. They can’t be deformed.

So I think you’re saying that using separate Geoms is the simplest way to go. In this case, I wouldn’t use a skeleton as such, as per the TestRagDoll example, and would just specify joint angles to animate the robot.

Conversely, if I used a skeleton, I’d have a single mesh (like I have in Blender for the limb above) and each segment of the skeleton would be weighted to affect all the vertex of a particular segment of that limb. So functionally I’d have the same result.

The only reason the skeleton option seems appealing is because I can connect everything together visually in blender. Getting the orientation and positioning of the individual parts seems trickier, unless I’m missing something obvious. :grinning:

Yes, i also think that skeleton solution is better in your case anyway.

Im just not sure if you want dynamically-modify skeleton(add new bones/etc in-game), or only add/switch parts that belong to some bone of skeleton.

First option is hard, while second is easy (since i use it myself for character).

Robot difference is that parts cant deform like you said, but indeed if skeleton mesh weights for all verticles are 1.0, then it will not deform partially, but just rotate all “robot-part”.

Thanks again for taking the time to reply.
I don’t see an immediate need to dynamically modify the skeleton during play, or even add or switch parts.
So using the second approach (skeleton), could I still treat the whole mesh it as a rigidBodyControl for physics purposes, or do I have to do something different (i.e is it still a rigid body)?
Looking at the JME skeleton class, it seems I would then use setBindTransforms/setUserTransforms to move the actual limbs?
Then I just need to figure out how to export a skeleton from Blender and load it into JME! :slightly_smiling_face:

exporting skeleton into JME is easy, you just need export as GLTF / FBX.

For animations you need setup NLA Tracks in Blender for skeleton.

Dont be afraid to use Minie, there are examples of what you need :wink:
Minie is same core physics as jme core one, but updated with new features and maintained.

Well, option 1 (using hinge joints) seems to be out now since I’ve discovered that it is not possible to directly set the angle of the joint. Furthermore, I don’t know enough about how the joints work internally to try and subclass one in a meaningful way. Otherwise I could model a Servo motor (i.e set and angle, spin motor until angle is reached and stop). I could do this is the main game loop, but it seems a bit messy and suggestive that I’m going against the flow/using the engine in a silly way. I’ll be sure to check out Minie though, in case that gives me any other options.

I’ll play with the export to GLTF again. For some reason I was having problems getting a skeleton out of it. Maybe it’s because I didn’t have NLA tracks set up?

Thanks again for all the good advice. :slightly_smiling_face:

1 Like

Actually, it looks like Minie does actually implement a servo in New6Dof. So I’ll be looking at this too. :slightly_smiling_face:

told u, hehe. I belive it have all types of joints thanks to @sgold work done there.

1 Like

Indeed, thank you. @sgold I tip my hat to you sir! :wink:


Thanks. Like most people, I build on the work of others … in my case, many, many others!


Do also consider carefully the overall correlation of the custom animations and the physics (presumably collisions).
For example:
does the animation determine the motion of the body, or vice versa?
does the collision detection drive the animation, or does the animation force transforms?
where in the animation code can physics constraint solvers be integrated, or vice versa?

1 Like

Interesting points. My previous ‘simulator’ was just a representation of the gait of the robot with no real physics engine. So climbing over obstacles etc wasn’t supported. When I started looking a JME, it was mainly to get access to a better graphics engine. Then I got excited about all the physics stuff which opens up a world of new opportunities.

So in answer to your questions, I think it’s a bit of both. The IK solver will supply targets joint positions. Whether the joint is able to reach the desired position is then a function of interaction with the environment (physics engine). This models the real thing quite nicely, in that a servo will be set to a specific position, but there is no guarantee that it will ever get there.

1 Like