I have a pitchipoy rig and a clean matching armature that does two things: follows every deform bone of the control rig, and does all the deforming of the mesh. I call this rig the ‘bind rig’, other’s call it a ‘shadow rig’.
For those wondering why i’d do something like this, it’s because game engines often can’t handle a rig with extra stuff in it and this was a really clean way i knew of solving that issue.
The only problem is that when i bake the animation into the bind rig, there is always an offset when removing the constraints. An offset that seems
Here are some screenshots illustrating the problem:
Please note, since the character is almost fully rigged i want to remind, that the intent of viewing the file should be educational only and only for this situation. Please don’t use it in any way other than to help me solve this problem.
The only time I had something like this, I rekeyed using visual keyframes and it took care of it. On some constraints, they try their hardest to get back to what they think is rest. See if keying visual will help.
If i’m not mistaken, this is what I’ve been trying. (bake actions with visual keyframe and remove constraints)
I’ve also tried manually visual key-framing every frame. And of course i need to eventually removed the constraints because they will drop out when i export anyway. But still i get the same result.
Here is a visual comparison of how this problem appears in the actual run animation:
If you open the file and key visual and removes the contraints you’ll get the same result (where the bones move apart). How can i fix this though? it’s ridiculous, I’m come so far with a rig that feels so complete and yet i’m up against a brick wall.
Hi Simon. How exactly did you build and set up the bind rig? If it was just replecated from the original rig that could be the problem.
I’ve not yet designed a strictly real time game engine rig in Blender yet although I have certainly done a fair few in other 3d software ,Max Maya etc…
What I do know is that the hierarchy of your main deformation or export rig is of paramount importance. The deform rig that you want to export should form a logical and solid FK hierarchy ending in a proper root bone in and of itself, without the control rig. The bones of the deform rig need a proper logical parent hierarchy already in place to accurately read their positions and rotations in space once the constraints of the control rig are taken away. Baking won’t work as any kind of magic bullet if this initial parenting isn’t set up right first. In my experiance the control rig should only effect the deformation rig through constraints. Not any sort of hard parenting.
For myself, I would always want to design a game engine rig from scratch and make sure everything is set up exactly right for whatever the character needs to do in engine.
Do you know for certain if the deform bones of this rig are really suitable for baking and game engine export? I know I heard that originally this rig was based on Nathan Vegdahl’s rigify rig and he’s said before it is not really designed for game engine work.
Why are you removing the constraints? Even if you can’t use the constraints in the game engine you will have baked the constrained action in the animation itself. Just keying visually should be enough. You can do this with Bake Action. (search for it with spacebar)
Then just export with the bind rig.
I assume he’s doing this because he does not want to export the control rig as well. which is quite normal practice. This way a totally clean and simple rig is exported and bone counts are kept to a minimum. You wouldn’t want any unneeded bones in a real time rig clogging up memory and playback or causing any possible complications and problems. The animation would ideally need to be baked directly to the deform bones that are being exported. At least that’s the normal set up I’ve always been familiar with. The control rig is just a tool to animate the exported deforming bone chain in the 3D animation software.
Hey Toka, thanks for your time, really like your work. That feathered dinosaur is extremely well done.
I just took the metarig and modified it basically. As you know, the metarig is the armature that you put in place and it generates a rig. I just took the metarig, divided the arm and leg bones so that the number of bones there matched up, then i added a root/origin bone that matched the placement controller of the control rig and parented the rest of the metarig to it.
This really seems like it’s worth me trouble shooting in this direction. Without knowing the original bone structure of the control rig, perhaps matching things up in just a similar hierarchy is not good enough.
Perhaps the next thing to try is to copy the original rig, delete non deforming bones and use that as the bind skeleton instead.
All I’ve got is a copy transforms constraint on every bone, and the bind skeleton has it’s own armature.
I wish i had your skill man As a rigging hack, I felt the need to resort to the easier option, auto rigging scripts (pitchipoy version of rigify). However i am so tantalizingly close to having a viable solution forever more, and it’s driving me nuts! Most of the pipeline with pitchipoy rig is smooth until this point.
I believe so. Naturally if you just try exporting a rigify rig the results aren’t optimum. But the thing that rigify and even pitchipoy’s version have in common with game rigs is that all the deformation is joint based which is great, because the features of pitchipoy blew my mind.
Spot on. The other reason I’d doing it is so that i can quickly check that the rig won’t mis-behave when it’s exported.
I’m not talking about the original rig but the constraints on the def bones. I mean, I know that, I did it, and it worked, which is why I am confused. So I was wondering why op removed the constraints when they are doing what he wants. The game engine doesn’t care about constraints, that’s just a blender thing anyway. Of course not having the constraints would be a problem if you want to replicate every function of the rig in the game engine itself, but that way of authoring animations in a game engine seems like a bad idea.
So, I made an animation with the control rig, selected the deform rig, baked the animation with Bake Action with the visual keying option selected (which means that the constrained animation is geting baked). Then I selected the mesh and the deform rig and exported those to UE4 (with “only selected” chosen in the fbx exporter so only the mesh and deform rig are getting exported), and saw that the animation looked the same as it did in blender. So, it worked. Thus I’m not sure what the issue is. To me it just sounds like op thinks he has to remove the constraints for some reason.
So far as i understand I’m just manually doing some of what blender does when it exports a rig. The visual keyframes are baked, and constraints are removed when it is exported, i’m just doing it sooner to see the result faster.
So I was wondering why op removed the constraints when they are doing what he wants. The game engine doesn’t care about constraints, that’s just a blender thing anyway
That’s right, the game engine doesn’t care about restraints which is why i was removing them to see how well they can take being removed
So, I made an animation with the control rig, selected the deform rig, baked the animation with Bake Action with the visual keying option selected (which means that the constrained animation is geting baked). Then I selected the mesh and the deform rig and exported those to UE4 (with “only selected” chosen in the fbx exporter so only the mesh and deform rig are getting exported), and saw that the animation looked the same as it did in blender. So, it worked. Thus I’m not sure what the issue is. To me it just sounds like op thinks he has to remove the constraints for some reason.
So you were testing using my blend file? In that case i should test that and see if it works for me too, i’ll get back here when I’ve tried it.
The constraints are removed for sure, but the effects of the constraints are not getting removed from the exported animations. If you then remove the constraints in blender the animation will look off in blender, but in the engine it should look good. I suggest that you check out your exported animation in the game engine you’re going to use.
So following your advice of just baking visual keys and exporting gave me the same result. I sent the rig file with the test animation in it and it has the same problems that show up when i try removing the constraints within blender.
Thanks for the positive comments. I’m animating a complete little sequence with that feathered dino. It’s become my main little Blender training project. I’ll post it up here once its finished.
The problems your rig is exhibiting do look fairly consistent with an exported bone chain that is not parented correctly. It looks particularly like there is no proper reference or root bone in there with everything floating off like that.
What I would say now is to just do some broad trouble shooting tests. Go through the deformation rig (… the one you want to export… ) and check how everything is parented. It shouldn’t be too complicated. If in any doubt then why not just pick out the obvious problem bones such as some of the face ones and just parent them to the head bone or any other obvious looking parent. Just to see what happens. It shouldn’t effect the animation at all since all the bones are constrained anyway. If it does then you might need to check the constraints again.
Try to get them to form one solid FK hierarchy all the way down to a universal root bone.
Also try to look out for any hidden drivers and scripts in the bones. That rig is already so complex just in it’s base rigify form. There are all sorts of FK, IK switches and stretch bones. Much of this would be contained within the control bones I would guess but some of it must still be there a bit in the deforming bones.
Hi Cyaoeu.
I’m sorry about my last post. Seeing it again it reads much more abrupt than I ever intended. Never a good idea to post on forums in haste I guess.
I’m still not clear though, why if the fully baked rig doesn’t work with the constraints removed in Blender then why it would necessarily work in the engine. If it somehow does then it’s a bit like working with blind luck. Not a way I would personally like to work.
Surely the engine is just repeating the same functions? Removing the constraints before export is quite normal in so many cases as well, and has the added advantage that you can more clearly trouble shoot the whole process. If the baked rig works in Blender but not in engine for instance then you have a much better chance to narrow down any problems. Especially in this case when a complex existing rig is being adapted for baking and export.
Right, I see why that happens now. When you move the head control the spine bones are getting scaled. That looks fine in blender because the constraints are negating the scale, but when the constraints are removed, the scale of the spine are having a cascading effect because of the parenting/bone setup of the bind rig. In order to have those crazy stretching animations you have to decouple the scaling so the spine bones don’t affect the rest of the rig. Maybe try experimenting with inherit scale settings.
I feel like your advice about a mismatch in hierarchy is most likely to solve my problem. And i feel like the best way to do that is by taking a copy of the actual control rig, removing anything that shouldn’t be there and using it as the bind rig. So i’d remove ik/fk joints drivers and constraints etc, till all that’s left is a basic hierarchy. I’m currently trying to figure out how to remove drivers and scripts but some googling might get me there. Once it’s all clean, i’m going to slowly begin adding transform constraints. And i guess that’ll also help me flag potential hotspots for problems such as the ones I’ve been having
It looks particularly like there is no proper reference or root bone in there with everything floating off like that.
Believe it or not there is actually a root bone in these examples, i feel like you may have been more on point about the hierarchy mismatch
You’re dead right about why we’d want to constraint before exporting, and your manors are in check for sure!
Cyaoeu,
Right, I see why that happens now. When you move the head control the spine bones are getting scaled. That looks fine in blender because the constraints are negating the scale, but when the constraints are removed, the scale of the spine are having a cascading effect because of the parenting/bone setup of the bind rig. In order to have those crazy stretching animations you have to decouple the scaling so the spine bones don’t affect the rest of the rig. Maybe try experimenting with inherit scale settings.
That sounds like something that might be worth keeping in mind. I’m not exactly sure how’d I’d check and test that given my small experience but it might click at some point. thanks
EDIT:
I immediately ran into a huge dilemma. If i want the exact same hierarchy as the control rig, i think i’d need a LOT of bones that don’t do anything. But the def bones sit within them…
I’m going to try having a similar hierarchy without those bones anyway, because they’d just be a game performance nightmare.
EDIT:
All i’ve been able to learn is that maybe Cyaoeu has the right idea. The main places that seam to be adversely effected by removing the constraints are the areas that use stretch which is sad because I was really keen on it. But why it causes problems i don’t know, all it’s doing is scaling the joints. It doesn’t make sense to me. I’ll try to dig in a bit more to see what i can figure out.
By default the children bones inherit the scaling of the parent bones. When the spine bones are getting scaled in the z axis so are the children. In my rig at least disabling inherit scale for the children bones stopped them scaling when their parent bone was scaled.
Here’s a script to do that:
import bpy
ob = bpy.context.object
bpy.ops.object.mode_set(mode=‘OBJECT’)
for bone in ob.data.bones:
bone.use_inherit_scale = False
also another script for debugging constraints:
import bpy
for bone in bpy.context.selected_pose_bones:
constraints = [ c for c in bone.constraints if c.type == ‘COPY_TRANSFORMS’ ]
for c in constraints: #bone.constraints[“Copy Transforms”].influence = 1
bone.constraints[“Copy Transforms”].influence = 0
This will fix the bones for the bind rig going crazy, however, it seems that it’s only possible to set this in blender. In UE4 children automatically inherit scale, location and rotation transforms and I’m pretty sure unity does the same (you can test though). Basically you’re screwed if you want the current rig for the stretching, however you can replace that functionality with shape keys and drivers. You will have to remake the bind rig though (to an extent).
The other thing you could try is make a new bone that just does stretching and not have it connected to anything. Or, stretch by using translation and not scaling. Actually this would work better since the rest of the children bones just have to move with the parent bone instead of copying the scaling and so on.
As a rigging hack, I felt the need to resort to the easier option, auto rigging scripts (pitchipoy version of rigify). However i am so tantalizingly close to having a viable solution forever more, and it’s driving me nuts! Most of the pipeline with pitchipoy rig is smooth until this point.
![https://trello-attachments.s3.amazonaws.com/55d3e41f8b10e9531e94fb92/244x213/e4694bfc2a49eebefaf13caad93c8976/run_cycle_good.gif[/video]](https://trello-attachments.s3.amazonaws.com/55d3e41f8b10e9531e94fb92/244x213/e4694bfc2a49eebefaf13caad93c8976/run_cycle_good.gif%5B/video%5D){kind=link}
![https://trello-attachments.s3.amazonaws.com/55d3e41f8b10e9531e94fb92/246x212/22f225906c3ffdb8688192912d1286d1/run_cycle_bad.gif[/video]](https://trello-attachments.s3.amazonaws.com/55d3e41f8b10e9531e94fb92/246x212/22f225906c3ffdb8688192912d1286d1/run_cycle_bad.gif%5B/video%5D){kind=link}