Rigify Game Rig (Development)

I have been looking for a simple way to get a rig using Rigify that doesn’t have a „destroyed“ deformation bone hierarchy since some time. Like that IK animations would become possible just with the generated rig for the usage in game engines.

A few days ago I was informed that the basics for such a solution can be achieved by the modification of a single line of code! It means that the ORG bones are used for the weight painting instead of the DEF bones.

We decided to work together on that topic and communicate in an „open“ way in this forum.

Our goal is that our changes are finally merged with the offical Rigify code. The user should be able to decide, if the default rig should be generated or the game rig. That may be done using a checkbox or another button. (e.g. „Game Rig“ checkbox or „Generate Game Rig“ button.)

That’s what we have so far. Let the discussion begin :slight_smile:

1 Like

In my opinion we need to make a few more modifications in order to allow the same workflow with the game rig and the default rig. That means:

  • DEF bones should not be generated at all, or we need to delete them afterwards if that is easier
  • As the ORG bones become the actual deform bones they should also be named DEF and should be moved to the correct bone layer

I think that’s very important to get a consistent user experience.

Hi Dantus,
I can see why you would want this. However, the DEF bones really are what you should be using for deformations, not the ORG bones, so your solution here is kind of a hack.

I would be more interested in looking for a generalized way to preserve the hierarchy of the deformation bones. Though doing that is a non-trivial problem, and I wouldn’t want it to complicate the code too much. In any case, it is not at all difficult to write a script that will change which bones have “deform” checked on based on their names. So you could easily do it as an after-the-fact thing.

Also, keep in mind that Rigify was originally designed and written for film/tv rigs, for hand-animation. I was never considering games, motion capture, match-moving, etc. rigs when it was designed, so Rigify’s core design may simply be ill-suited to those use-cases. I am not at all opposed to expanding Rigify to be better for those use-cases, of course. But only if it fits with Rigify’s core design principles.

DEF bones should not be generated at all, or we need to delete them afterwards if that is easier
As the ORG bones become the actual deform bones they should also be named DEF and should be moved to the correct bone layer

This would require imposing more limitations on how rig types are written (e.g. DEF bones would have to be forbidden from affecting ORG bones), which I would rather not do. I want to keep rig types as flexible as possible, which is part of what makes it difficult to adapt Rigify to adhere to the limitations of game rigs.

@Cessen, I understand your points. Having a general solution is definitely better than a hackish one. So, I am going to have a closer look at how this could be achieved and will show it to you. This will probably take weeks, as I don’t have too much time at the moment and I am not that comfortable with Python and especially not in Blender.

@test-dr, thanks for your input. That would be perfect if I just had to get it working. As I am looking for a “cleaner” solution, that’s not really what I am looking for.

@Dantus: i think this solution is very clean, because it demonstrates the possible exchange of different animations (actions with fcurves) in blender from one object to another object. For example, if there is an armature A1 and a different armature A2, but both have the same bone “head”. Then one can put the animation of the head-bone of A1 to A2 without any problems. If you think about some mystical creatures like the “horseman” (centaurus), then its easy possible to use the animation of a normal bipeds upper body for the upper body of the centaur and some animation of a horse-armature (the lower body with 4 legs) for the lower body without any problems. If you plan your armature and use the same naming conventions, then you even dont need to do any re-naming of the bones or the recorded action-data (and both can be done with a script - but if you have very bad created bone-names, you will end up to setup a name-relation for every single bone and you cannot use simple string-replaces).

@test-dr: That’s correct. But from my point of view it is a better workflow to set up the meta-rig for Rigify, push the “Generate” button, done. From a technical point of view your solution is totally valid. But I am looking for simple workflows.
I would like to integrate such a solution directly into Rigify to make it as simple as possibly for any user. As Cessen said the initial proposal is too hackish for him, I going to try the non-trivial one.

Looking forward to seeing what you come up with. However, do keep in mind that this may be a very difficult or impossible problem, whilst still preserving Rigify’s flexibility and modularity.

If it turns out to be too difficult, you might consider creating a new auto-rigging system geared specifically towards game requirements. It would be more work, of course, but it might be the best way forward. Sometimes specialization is the way to go. I would be happy to give pointers as my (admittedly limited) time/energy allows.

Any news on this ?

Unfortunately, no. As Cessen pointed out, this is not a trivial topic and it would be necessary to redesign a lot of code and the rig itself. I carefully checked how much work this would be and it is simply too much at the moment. I really would like to do it, but I just don’t have that much time.

@Dantus, can you rephrase what the problem was you were trying to solve? Is it just about the complexity of having the extra bones/bone layers?

Sure, I can certainly rephrase it. It is not the extra bones/bone layers. The basic issue is the hierarchy of the deform bones. Rigify does not create a hierarchy for them that can directly be used for inverse kinematics, because some of the arm and leg bones (if I remember correctly) are not properly connected for that purpose. The inverse kinematics behaviour is needed outside of Blender, where only the deform bones are present, that’s why the hierarchy of them matters.
Hope this helps.

Why do you need rigify ? (I have never used it)

is it for ragdolls? mocap?

Because it is so much easier to animate with it. I know there are alternatives, but as Rigify is part of Blender and is actively maintained, it makes sense to use it.

You mean so for example if you were taking a character into Unity or Second Life or whatever?

Right. The idea is to create the whole character including animations in Blender and exporting them in my case to Unity. In Unity there are several tools that automatically adjust the animations using ik, that’s why the bone hierarchy is essential. The most important tool that makes use of ik is now probably Mecanim.

I know that there are quite some Unity users who are using Rigify. I know that this tool is downloaded about 250 times per month, so there are surely some users and there is some interest in this topic.