Spacesuit Visor Problem
[I solved this problem in July, but ran into it again today and realized it was not in my log. This is adapted from a thread I started in the “Blender NPR & Stylized Rendering” group on Facebook, mainly so I have this in a permanent location to refer to.]
The quick answer was that the problem would not occur if I remembered to include the armature in the visor group in the library file. Then, when the armature moved, it would displace the visor group the same as the character group.
However, I think it may be instructive to include my troubleshooting process.
At first, I had no idea what was going on! The weirdest detail is that this would only happen when rendering with the Blender Internal renderer. In the GL previews or in the viewport wireframe, the visor would be in the correct location, and test-renders with Cycles also showed it correctly placed (although the render itself was terrible):
This is the weirdest bug I’ve run into with Blender in a long time. As you know, Freestyle does not support transparency. I have a work-around for that that I’ve explained elsewhere ( http://wp.lunatics.tv/?p=3057 ), but it involves putting all of the transparent objects into a separate layer.
Now if the object is part of a character (spacesuit visor in this case), then it becomes necessary to link the character as two separate dupligroups, rather than the usual one.
So I’m trying this out. I’ve tried using “parenting” to associate the visor object with the character and also the “child of” object constraint which does almost the same thing.
The weirdest thing happens — in the viewport and in GL renders, the visor appears located just as I would expect. But in the actual renders, it is displaced oddly. This happens consistently in successive renders (so it’s not the proxy-glitching problem I’ve run into before, which also shows up in the viewport when it happens).
Well, I’ve isolated the problem.
I created a new file and linked the character group and the visor group, both at the origin.
I parent the visor dupligroup to the character dupligroup.
Now I proxy the armature (Ctrl+Alt+P — select the rig).
Then I ROTATE the character dupligroup and the proxy armature with it.
The visor dupligroup moves with it in the viewport. AND a render at this point is still correct.
Next, I go into pose mode and move the ROOT of the proxy armature forward. This does the correct thing in the viewport — the visor moves forward.
BUT at this point, the Blender Internal render moves the visor SIDEWAYS (i.e. in the original direction, not honoring the rotation of the objects).
That suggests to me that there is a problem in the code for applying the armature to a mesh in Blender Internal’s code, somewhere — does not work the same as elsewhere in Blender.
So that’s what’s going wrong. Will have to figure out a way to avoid it.
After some more troubleshooting, I found the problem:
Interestingly, the parenting of the dupligroup doesn’t seem to matter. If I clear the parent on the visor and then just manually rotate it to match the rest of the character, the same problem occurs.
So that means that the armature is acting differently on the visor than it is on the rest of the character.
I tried reversing it — using the visor to create the proxy, but — aha! — there IS NO rig in that group to proxy.
So… I go back to the character file and I simply add the armature to the “visor” group as well.
Now I can create the proxy from the visor — what will happen?
Turns out, now it does what I want — the character and visor stay together.
So I THINK I have solved this puzzle — the problem being simply that the separated component group also needs to include the armature.
It’s still weird that that only affects the BI render, though.
SOLVED, I think: the visor group in the library file must include the armature, just like the character group does.
That makes some sense to me — the weird part is that it only affects the BI render and not other renders or viewport.
So this would appear to be a bug in the Blender Internal rendering code (since it doesn’t behave the same as the other rendering engines). But the work-around is pretty simple.