Nested bone layers

[ggoblin]

I'm trying to understand how nested bone layers work, and what their limitations are.

I have a simple head rig with a dial bone controlling head rotation. The head bone layer includes a nested eyes bone layer which I created separately - it controls pupil movement, blinks, eyebrows, etc. The head rig can control the eye bone layer as a single entity (eg move the eye layer as a whole for head rotation), but it doesn't seen to be able to control elements inside the eye bone layer - for example I want to squash the right eye layer when the head turns right to imitate perspective. I can set up smart actions for the head rotation which includes squashing the right eye layer during head turn and it works within the smart action timeline, but when I go to the mainline timeline those actions in the nested bone layer are ignored when the smart action is executed.

I am assuming this is by design, that elements inside one bone layer cannot be manipulated by bones inside another bone layer? If this is the case then whats the work around which allows us to create rigs in a modular fashion (eg create eye rig separately, add it to head rig, then add head rig to body rig) ? I tried controlling a bone inside a nested bone layer by a bone outside the nested bone layer but that also didn't seem to work. What am I doing wrong?

Thank you for your help.

[ggoblin]

There is a very useful script that "Merge bones from a nested skeleton layer into parent layer skeleton". I thought maybe I could use that as a work around so once I import my nested eye bone layer I could run the script to merge its bones into the head bone layer..

https://mohoscripts.com/script/ae_merge_skeletons

But unfortunately I couldn't get it to work. I selected the outer bone group layer and then ran the script, it creates a new outer bone layer but it seems broken - the bone in the outer layer no longer work and the bones in the nested layer don't seem to have been merged..

Has any one used this script, what an I doing wrong?

Thank you.

[synthsin75]

You can do this one of two ways.
1. Have a smart bone in your main bone layer control each bone in your eyes bone layer. This can often be easy to get confused and mess up.
2. Have a warp mesh controlled by a smart bone in your main bone layer squash the vector layers of your eyes. This is pretty straight forward, since a warp mesh under your main bone layer can influence the eye sublayers.

[ggoblin]

Thank you Wes!

I created a very simple test rig and you are absolutely right - a smart bone in the main bone layer can control bones in the nested bone layer. (BTW Also confirmed that a smart bone in the main bone layer cannot directly control layers/points/shapes in the nested bone layer). As a beginner its very useful to know this, thank you.

Unfortunately it still doesn't work in my head rig. In the blue smart bone timeline a smart bone in the main head bone layer can control the bone in the nested eye bone layer to squash an eye, but unfortunately when running in the main timeline that control is lost - nothing happens. I suspected that it might be because I had created the eye bone layer group in another moho project and then copy and pasted that layer in to this project (as a way to import the eye rig). To test this theory I went back to the original eye rig moho file and created a head bone layer there with the eye bone layer nested inside it.. sure enough it works there - a smart bone in the head layer can squash an eye in the nested eye layer group by controlling a squash bone in the eye bone group.

So the original question remains - how do we create modular reusable rigs which can be imported in to different projects as required?

Or do experienced Moho animators not import rigs across projects, just import the methods they have learnt from one rig and recreate it from the ground up when required in another project?

I guess the question is about workflow - trying to understand what method works and what to avoid and why. I wish there was a guide to best practice when using Moho.. there seem so many ways to do something and if you chose the wrong way you can hit a wall and often that wall isn't even documented so you are clueless as to what you are doing wrong.

Thank you for your 'thinking out of the box' suggestion of using a warp mesh, I haven't tried it yet. Will investigate.

[Greenlaw]

(BTW Also confirmed that a smart bone in the main bone layer cannot directly control layers/points/shapes in the nested bone layer).

I can animate points and layer transforms inside a nested bone group using an SBD located in a parent bone group. Just to be sure, I tried this now in 13.5.2 and it's working here. Do you have a project file you can post where this is not working?

So the original question remains - how do we create modular reusable rigs which can be imported in to different projects as required?

You'll have to show an example file that fails because under normal use, importing character rigs with Smart Bone Actions from 'master' project files is a standard workflow for Moho animation production. Done properly, this should work flawlessly.

Importing modular parts with SBAs is not standard workflow but it's certainly doable if you follow some guidelines. (This is discussed fully in that other thread about Transferring Rig Parts.)

Or do experienced Moho animators not import rigs across projects...?

As mentioned, importing a character from a 'master' project is standard workflow in Moho. Just choose File >Import >General Import, select your file, check on the group (i.e., character rig) you want, decide if you want a copy or a reference, and then click OK. The rig should appear in your project ready for animation.

Just a thought: be sure you are using Moho 12.5 or Moho 13.5.2. If you are using Moho 13.0.x, importing a rig may not work properly because there were changes made with how Smart Bone Actions were identified in that version.

This problem was fixed in Moho 13.5 and up.

[Greenlaw]

On a related note: a while back, Jeremy at Cartoon Saloon explained using 'grandfather', 'parent' and 'child' projects when importing characters. What this meant was you have a master 'grandfather' project where you make all your edits and changes, and this is imported to another 'parent' project as a reference. Then, the animator imports this version as a reference into their 'child' project for animation.

The idea is that this allows the rigger to continue working on the 'grandfather' version of the rig without disrupting the work of the animators. Once the rigger has updated the 'grandfather' rig, he can update the reference inside the 'parent' file and then inform the animators about the change. Also, in the animator's project files, the rig's reference icons will change from green to red to let the animator know the master rig (i.e, the 'parent' ref and 'grandfather' original) has been changed.

At this point, the animator can decide if they need the update or not. If they do need it, they should make a copy of their project file before updating the rig because there is always the risk that the update will break their animation. If the update does break their animation, they can simply revert to their back up copy and just ignore the update or make the changes manually to their file.

Be aware that some updates will not carry into the reference rig; for example, changes in bone strength. Basically, any art changes, added or removed items, and anything key-frameable should carry over to the reference rig.

I set up a similar system for our animation team back when I was working on Boss Baby: Back in Business, and it worked out great for us.

To be clear, it's not necessary to use reference rigs, but it's useful to do this when you anticipate changes will be made to the rigs after animation has started, especially in longer format productions involving several animators. (For smaller projects where I'm the only rigger and animator, I might not bother with this...it really depends on the scope of the project.)

This is an advanced tip but I hope this helps explain some of the options available and why/when you would use them.

[synthsin75]

Unfortunately it still doesn't work in my head rig. In the blue smart bone timeline a smart bone in the main head bone layer can control the bone in the nested eye bone layer to squash an eye, but unfortunately when running in the main timeline that control is lost - nothing happens. I suspected that it might be because I had created the eye bone layer group in another moho project and then copy and pasted that layer in to this project (as a way to import the eye rig). To test this theory I went back to the original eye rig moho file and created a head bone layer there with the eye bone layer nested inside it.. sure enough it works there - a smart bone in the head layer can squash an eye in the nested eye layer group by controlling a squash bone in the eye bone group.

That's what I meant by this method being easy to get confused. I'd likely have to see an example of what you're trying to know where you're going wrong.

[ggoblin]

(BTW Also confirmed that a smart bone in the main bone layer cannot directly control layers/points/shapes in the nested bone layer).

I can animate points and layer transforms inside a nested bone group using an SBD located in a parent bone group. Just to be sure, I tried this now in 13.5.2 and it's working here. Do you have a project file you can post where this is not working?

I've included the simple test rig here.

https://we.tl/t-Gs6148Ntk4

An outer head bone layer includes a nested eye bone layer and a vector head layer (just a flesh coloured circle)

The nested eye bone layer has just one layer - a vector eyes layer which includes both eyes (white circles)



The eye bone layer has a SBD 'squash reye' which squashes the right eye using transform points.



The head bone layer has 3 SBD's :

1. 'head squash reye' SBD - this controls the 'squash reye' SBD of the eye bone layer to squash the right eye from the head bone layer - it works fine. (fig 1)




2. 'head squash eye directly' SBD - this uses transform points on the points of the nested eyes layer to squash the right eye. Whilst appearing to work in the blue SBD timeline, it doesn't work in the main timeline. (fig 2 &3)


works in the blue SBD timeline


doesn't work in the main timeline

3. 'head squash both eyes' SBD - this uses transform layer to squash the whole eyes layer (ie both eyes). Again this whilst appearing to work in the blue SBD timeline, it doesn't work in the main timeline. (fig 4 & 5)


works in the blue SBD timeline


doesn't work in the main timeline

[ggoblin]

Using this simple rig I copy pasted the 'eye bone' layer in to another head rig (as a nested layer) and it successfully controlled the 'squash reye' SBD of the eye bone layer to squash the right eye. Of course this is a much simpler rig than the one where it doesn't seem to work, but it shows that the importing in itself can't be the problem.

I will have another look at my problem rig.. and if I still can't figure it out, perhaps if anyone is generous enough to have a look at it I can upload it? I don't want to waste anyone's time as the rig is of no consequence, its just a learning exercise - just my first attempt at a head turn.

[ggoblin]

On a related note: a while back, Jeremy at Cartoon Saloon explained using 'grandfather', 'parent' and 'child' projects when importing characters..

Thank you, it seems like a sensible approach to version control especially when working in teams

Be aware that some updates will not carry into the reference rig; for example, changes in bone strength. Basically, any art changes, added or removed items, and anything key-frameable should carry over to the reference rig.

Thats very useful to know, I would never have guessed that. Why is something as fundamental to a rig as bone strength left out?

[Greenlaw]

Thats very useful to know, I would never have guessed that. Why is something as fundamental to a rig as bone strength left out?

I'm guessing it was an oversight, and possibly missed because it's not a key frameable item? I don't know, it might be more complicated than that. I'm sure it was reported but that was in the 'before times' so maybe it's time to ask again.

That said, so far it hasn't been too big a deal for me. The issue came up maybe twice during all of Boss production, and I just the other animators know to adjust bone-X exactly Y-much after updating rig-Z. Your mileage may vary of course.

[MrMiracle77]

How does the rig work on frame 1? Not all nested bone actions test properly in the preview pane on frame 0 (no idea why).

[ggoblin]

How does the rig work on frame 1? Not all nested bone actions test properly in the preview pane on frame 0 (no idea why).

Sorry, maybe I didn't explain properly.

There is only one bone action in the nested bone layer - you can set it anywhere in the timeline by manipulating the 'squash reye' bone. It should work fine.

But the problem is in the main bone layer. Out of the three smart bone actions only one works in the timeline or on frame 0 (though they all work in the smart actions own 'blue' timeline).

Sorry I left the timeline blank, I've uploaded the project again - this time with the 3 smart bones manipulated in turn on the timeline to show the problem.

https://we.tl/t-vez9Rv6PA3

Thank you for looking.

[synthsin75]

If you delete your single bone on the eye bone layer, both of your other SBs work. It's an either/or situation. Either you have bones on your eye bone layer, or you allow nested SB control. Having any bones on the eye bone layer blocks the influence of any bones from a parent layer. That's why daisy-chaining the parent SB to the sublayer SB is necessary, if your sublayer has any bones.

[ggoblin]

Yes this is what I assumed - its by design that smart bones in the main bone layer cannot directly control layers/points/shapes in the nested bone layer. To exert control from the main bone layer you have to do it indirectly by calling a SB in the nested bone layer. Thank you for confirming this.

Its good to be aware of this when designing reusable (embedable) rigs - ensure you create smart bones for anything you want controlled from outside the rig.