4

I have recently completed a complicated rig, and within its own file it works brilliantly. (Yay, me).

My problem comes when I Link it into another file.

Everything is Grouped, and I link its Group from the new file.

Everything gets linked in, however... apart from the base armature a lot of the wonderful additions I've given the rig no longer work, such as the Hide Menu, or the extra armatures for the damaged state.

My question is this: How do I properly set up my rig so that, when I link it, everything works?

I'll go through my process step-by-step, below.

Firstly, here's how I understand simple rigs to work when linked: Simple Rig set-up

When the Amature, Mesh and extra Controllers are Grouped together the Linking process goes swimmingly: Simple Rig being Linked

Using the above diagrams as a basis, here's how my new rig differs:
(FYI: my actual rig is a tank, not a person). Complicated Rig

There is an extensive Hide Menu which is used to switch on/off various controllers, meshes, damaged states, etc. Hide Menu

Because there is different state changes to the rig, it uses three other armatures parented to the main armature.

There is also Deformer cages over different parts of the mesh which have various controllers "hooked" to it.

So, not simple, but not SUPER advanced either. Here's what happens when I Link this rig to a new file: Complicated Rig being Linked

Essentially, all the parenting breaks, and my list of Proxy options balloon out, forcing me to set things individually: List of Proxy options

The Hide Menu is the one that kills me the most because I had a terrific Location Constraint placed on each of the switches, and once the proxies have been pulled in the visibility drivers still work (which is excellent), but the Location Constraints do not (meaning that the little switch can now be dragged far from the menu)> The Damped Track and Copy Rotation of the Hide Menu also doesn't work, which means that it won't automatically face the camera anymore. Not to mention that all the elements (50+) need to have each of their proxies set individually, which is an unworkable solution.

Right now my Outliner of the Rig's file looks like this: Outliner

00_GUI = All the GUI elements for the Hide Menu.

00_RIG= The armature containing the entire rig elements.

STG_ = Stage elements

ZZZ_JNK = Mostly just the custom controllers for the bone shapes.

All of the Rig's elements (including the Hide Menu) are Grouped together, which is what I've been linking from the new file.

I would be very appreciative if someone could set me in the right direction in terms of setting up an advanced rig properly so that when it is linked in to a new file it works as it does in its original file.

Cheers,

Mat

Mat Brady
  • 129
  • 8

2 Answers2

3

Take a look at this:

Rigging question about Spline IK and having all controls on one armature

It's an example of rig structure with multiple armatures inside parented, to avoid dependency issues.

The trick is to have all the controls the animator will interact with inside one master armature, and to copy these bones with constraints to the other armatures where they do things. This way, you only need to make a proxy of this master armature when the rig is linked and everything else becomes inner workings of the rig.

This should remedy any parent breaking problems when creating proxy rigs.

Jaroslav Jerryno Novotny
  • 51,077
  • 7
  • 129
  • 218
2

Firstly, thank you Jaroslav for your workaround. Unfortunately this means my really cool camera-facing GUI (to hide/unhide things) won't work because it's now a child of the base armature.

In fact...

(and this is to anyone else looking for a way to set up an advanced rig to be linked within a production pipeline)

...I've now found out that Blender simply doesn't work the way you expect it to. If you're coming from Maya, referencing (their version of Linking) is robust and simple. Blender's, while seeming to be more flexible, just seems in practice to be limiting and easily-broken.

But all is not lost. I turned my frustration into inspiration and crafted a proposal to the RightClickSelect forum. I spent a week working on it and I'm very proud of it. I hope it starts a conversation.

There was no solution to my original problem (above), but here's my proposal for the devs to improve on linking in general:

https://blender.community/c/rightclickselect/l6bbbc/mr-tapll-a-new-method-of-linking

Mr.Tapll

Mat Brady
  • 129
  • 8
  • In Blender it is much more convenient to have a rig UI script with buttons in the side properties panel (N) or even drawn with opengl on the viewport. Such script then also handles any relationships this proxy of linked rig has to other scene objects (to camera, to simulations, particles, etc.) – Jaroslav Jerryno Novotny Apr 28 '18 at 10:06
  • 1
    You are right the link mechanic in Blender is prehistoric and there are many more bigger problems with it - like drivers added to constraints on proxies vanishing after file reload, etc. Don't forget Maya is not free and is in different weight fighting category, it's not even comparable. There are handful of active Blender devs and their hands are full. You should bring the discussion here, talk directly with the devs. There is a pipeline (linking system) redesign in progress for 2.8. – Jaroslav Jerryno Novotny Apr 28 '18 at 10:11
  • Jaroslav, thanks so much for replying. You're the only one that has so far, so thank you.

    You mentioned drawing a rig UI to the viewport using open gl. If you could point me in the right direction for learning that, I will get myself the rest of the way.

    Lastly, yes, linking in Maya is not comparable, or free, but I was able to propose something radically new directly to a Blender dev, and he responded. This is something that would NEVER happen with any Maya dev, ever. Blender can change. Maya will only atrophy. I'll stick with Blender because it's the future.

     – Mat Brady Apr 29 '18 at 23:58
  • You can copy some code from this relic which is linked to this answer. The only annoyance is if you want interactivity, you pretty much have to run it inside modal operator that has to be explicitly started/ended, getting mouse coords or key presses is hard otherwise. Displaying passive info like motion paths that auto-update through bpy.app.handlers requires less effort to implement. – Jaroslav Jerryno Novotny Apr 30 '18 at 15:49
  • Joroslav, you’re a champion. Thank you.

    Through the process of making my Mr.Tapll proposal I spoke with one of the devs on the 2.8 Code Quest. He told me that many, if not all of the issues I have with the rig will be solved in 2.8. Whether that’s true or not, it means that I will get back to modellling and texturing other assets until that happens.

    You’ve been an EXCELLENT help though, and I thank you again for your efforts. :)

     – Mat Brady May 01 '18 at 19:09