A game friendly armature would be great to have!
There is actually already a game friendly armature, the original bones you get which are located at the last bone layer in rigify final armature. Only thing you just need is to make all of those bones deformable and you are ready to go.
open generate.py, find line 322 and change it from:
#if obj.data.bones[bone].name.startswith(DEF_PREFIX):
to
#if obj.data.bones[bone].name.startswith(ORG_PREFIX):
so if this works, then at least in theory it wouldnt be too hard to make a button that does it optionally?
I will try it later. Thank you for sharing.
Yeah, you can do this. But keep in mind that some of the rig features aren’t represented in the ORG bones (e.g. limb twisting). And, also, the ORG bones are just a copy of the meta-rig, which means there will be some extra bones that were just there to provide extra information to Rigify (like the foot rocking bone) that you may not want to be in the game skeleton. So that’s not going to be a good solution in some cases.
But for games with less emphasis on deformation quality (e.g. especially games that are graphically simple), that’s probably a fine stop-gap solution.
Maybe a gsoc project?
yes please!!! 
I wish rigify could compete with advanced skeleton for games.
Being able to (optionally) generate and drive a clean and easy to export armature that has only bones that are meant to deform the mesh and no specific blender stuff.
This cuts down production cost in time massively.
Btw this same feature has been requested at the Unity forums as well
http://forum.unity3d.com/threads/90913-Rigify-to-Unity
There was even developer’s interest in getting it in truunk. This was back in 2012. What happened?
Now if you really want to dig deeper and make it even mocap friendly, check this documentation-
https://docs.unity3d.com/Documentation/Manual/BlenderAndRigify.html
It is a huge amount of work. I am not comfortable with Python and it simply would have taken too long for me to do it.
That’s the most horrible documentation page that exists for Unity. They generate a Rigify rig. Then they modify the rig, such that it becomes compatible with Mecanim. Unfortunately, after the modification step, the rig is broken and you can’t use the Rigify functionality anymore. Could anyone explain me why they picked Rigify in the first place, if it is not possible to use its functionality anymore? Why didn’t they just explain how to create a meta rig instead?
This document makes no sense in my opinion.
So, I’ll reiterate what I said before: Rigify is simply not designed for game workflows. The best we’re going to get out of Rigify is stop-gap solutions. They might be pretty decent stop-gap solutions, but will nonetheless always be a bit awkward. Rigify’s architecture simply does not lend itself to a separate clean deformation rig with a proper parent-child hierarchy.
The best we’re going to get is a duplicate of the deformation bones that are driven by the rig, but which the user then needs to manually re-parent into a proper hierarchy.
Now if you really want to dig deeper and make it even mocap friendly, check this documentation-
https://docs.unity3d.com/Documentation/Manual/BlenderAndRigify.html
Mocap rigs are even further away from Rigify than game rigs. The entire point of Rigify is to generate animator-friendly rigs with minimal effort. So while I view Rigify’s lack of game workflow support as an unfortunate oversight on my part when designing it, I view mocap rigs as simply outside of the scope of what Rigify is trying to solve. Mocap rigs are just a totally different animal.
In the future I can see maybe designing a totally new auto-rigging system that can accommodate all of these use-cases in a clean way. But if I ever get around to that, it will likely be quite a while from now, and the design of the system would in all likelihood be very different from Rigify.
ah fair enough. In that case then maya/max/etc will continue to be better for animated game assets until then.
As I say my request was not to change the way rigify generates its animation friendly rig. Keep the animation friendly rig!
The request was to add the ability to attach an export friendly rig to it, which the artist can alter without worrying of damaging the animation from rigify. Without touching the rigify rig at all.
So delete export-armature bones that are not required and then (bake on) export.
Then if it slows blender- delete the export-friendly armature.
The point is making it safe and simple to alter bone structure.
Maybe one day someone will write such a rigging system. I guess blender python is more difficult than Maya’s Mel scripting- as there is a huge variety of all sorts of rigging scripts on maya and only one for blender.
On mocap: now lets forget I even mentioned mocap. Lets look more in the direction of game engines. Mechanim lets the artists blend animations with other animations or procedural movement and hook them up with game logic. To do that, the artist needs to be able to alter rigify’s joint hierarchy. Thedocumentation I linked to is not ideal and I am not even sure if it’s official. It is messy as hell as you can see. Destructive too!
There isn’t only one… there’s just only one that’s general enough to be shipped with Blender. Furthermore, I wouldn’t say Python in Blender is any more difficult than Mel (or Python in Maya, for that matter). It’s simply a numbers game. Riggers in general are a fairly uncommon bunch to start with, so there aren’t that many… and of the small population of riggers, there are fewer Blender riggers than Maya riggers. The number of publicly available tools/scripts for each application is a reflection of that disparity.
To get back to the idea of generating the panels driectly from the rigify addon, rather than from a generated text block…
Fair enough. Another advantage of generating the script is that the user can then customise it.
My idea would be that rigify checks to see if an appropriate UI script is present, and if not it draws the UI automatically.
This seems the simplest from the user’s point of view and doesn’t alter the existing workflow.
Yeah, it’s those extra properties that have kept me from attempting it myself.
Of course the whole topic would be rendered moot if we had a way of attaching python scripts to linked groups.
Till then, I think it’s an idea worth considering.
Nathan, we could use now the child of constraint to change the space. For example the hand attached to head or hips or shoulder, and put a driver on the influence, the earlier versions of blender didnt have the influnce on this constraint. You should put this on the code of rigify.
I’m using a slightly older version of a rigify rig, sorry but I can’t remember which version of Blender I used to rig my character. I was just playing around with it last night using the fk arm and one thing I’m struggling with is a forearm twist, when you arm goes from pronation to supination. Is this even possible with this rig because the forearm axis seem to be locked for all but one axis.
So your rigify forearm can replicate the movement of ulna which is the hinged rotation but the radius ability to twist the forearm seem not to be there?
The forearm control only has one axis of rotation, yes. But there are actually two deformation bones. And the deformation bone representing the radius automatically twists to be consistent with the hand position.
Unless you disabled that in your metarig (which you can, e.g. for simple game rigs). But by default, it generates two bones for the forearm, and two bones for the upper arm, for handling twisting deformations properly.
there has been some progress on the topic:
http://www.felixschlitter.com/tool/bake-rigify
somebody made a plugin for baking to bones.
Its better to have the option than have nothing.
Its still not very good though. Messy
This is still a destructive workflow, because if you accidentally hit save, you have lost. Though, there is a solution, that requires a little upfront work, but allows you to have to full animation power of Rigify and preserves a non-destructive workflow.
After the Rigify rig was generated, make all the DEF_ bones non deformable. Instead make the relevant ORG_ bones deformable. There is at least one foot bone that comes to my mind which is placed outside of the skeleton. Pretty easy to identify. The weight painting certainly needs to be made with those deformable ORG_ bones.
If you use e.g. the fbx exporter, the keyframes are automatically baked.
But the exported armature in an absolute mess 
I watched a video at the top of the thread that showed us being able to put in an arm, a leg, and so on rather than auto-generating the whole skeleton. However, I don’t appear to have that option. There are no "rigify buttons’ just a generate option. Adding a bone doesn’'t give me the option either.
The youtube video describing this is quite old and I’m running Blender 2.69.