Rig inside of rig is being affected by parent actions

[stephenthomas0]

Stumbled across this today and have verified with everyone else working on the project. This is using 14.4, the bug doesn't appear in 14.3.

Nest one rig inside of another rig. Both rigs have Actions of the same name (e.g. 'blink'). The bone controlling the action for the parent also drives the action for the child rig inside.

Here's a screen recording of the bug with an ultra simple example: https://www.dropbox.com/scl/fi/ctkibmfb ... yh51v&dl=0

I'm going to submit an official bug report, but wanted to post this here too incase someone else stumbled across the same issue, took a good couple of hours to problem solve and finally figure out it was the software and not a rigging issue.

[Greenlaw]

That's interesting. I don't think I've ever placed a full character rig inside another character rig, but I can see how this happens because Smart Bone Actions in a Parent's Bone layer can, by design, affect the actions/bones of a Child's Bone layer. I believe the system looks at the bone/action names, not the item's ID, so it might get confused. FYI, reading the item name in Moho is preferred in many situations, but it can cause issues in others. (Same with Layer names, which is why it's important to give layers unique, identifiable names when using Layered PSDs or Switch Layers. With PSDs, at least, Moho will default to using layer ID if it can't find a helpful layer name.)

I'm surprised to hear nested duplicate Smart Bone Actions worked in 14.3, but not in 14.4. Let me know if you get a reply from LM about this. I'll try some testing here on my own.

In the meantime, try giving the nested rig unique bone/action names. I think there are scripts available that can facilitate the renaming process. Check mohoscripts.com. I've used one to append and change bone names in a skeleton, and maybe there's one for Actions, too.

Hope this helps.

[Lukas]

You could try nesting the sub-rig in a grouplayer that does not have the action. It might stop the action from influencing the sub-rig.

Be aware ‘entering’ the action from the top rig layer, will probably create the action on the mid-group. Which would enable the influence again.

(Not tested, but I’d assume this would work)

[SimplSam]

I think you are tremendously lucky that it ever worked 'OK'.

Actions are assigned per layer and then also per animation channel, and actions can have actions. Such that each Point width, Shape fill color, Layer position, Bone rotation, etc., etc., references its associated Action(s) independently, which can result in many thousands of Action references per project, all based solely on name.

As already mentioned, your best solution is to rename one or other action, ideally whilst the character rigs are in separate documents.

[stephenthomas0]

Thanks for the replies everyone

Hey Greenlaw, yes, renaming bones & actions did fix it, but it was odd because this used to work fine without having unique names per rig. Someone on our team suggested the same about IDs, a bit crazy that it just looks at names which don't have to be unique... I did get a reply from LM and it wasn't great. The person looking at my ticket claimed that I'd sent them the wrong test file (I didn't). I tried to send them a reply with more details in the hope that it would help figure out what went wrong, but when I clicked 'submit' it kicked me out to the login screen and I can no longer log back in. All I wanted to do was provide information to try and help the devs figure out what's going wrong and make Moho more stable, but it felt very much like "This isn't a bug! Go away!"

The really weird thing about this issue is that it stopped happening for everyone on the team at about the same time. Maybe Moho has some kind of cacheing system meant to speed things up that somehow temporarily stored this issue Really weird.

Thanks for the suggestion Lukas, we did try putting the child rig into a group, but that didn't make a difference.

Thanks SimplSam... Something I'm learning more and more about Moho is that just because you 'can' do something, doesn't mean that it will work/is stable I went down a rabbit hole a couple of months ago trying to build an FK/IK switch into limbs. You 'can' set a parent to change in an action, but it always resulted in bones jumping/rotating randomly... The logic of what I was trying to do was sound and the workflow is there in the software to do it, it's just broken when you try to...

[Greenlaw]

Using IDs for Actions has been tried before in Moho 13.0, and it was a disaster. The team that took over Moho development towards the end of its run at Smith Micro did that, and it broke EVERYTHING...the studio where I worked at the time immediately switched back to Moho12.5. This is one of many reasons why Lost Marble and Moho's current dev team chose 12.5 as the foundation for 13.5-14.x rather than picking up where the final Smith Micro version left off. So, yes, been there, done that.

The reason to use Names for Actions is that IDs are easily broken when the item or rig is being edited, and this causes all sorts of problems when rigs are shared and edited between several animators working on the same production. Names, on the other hand, are more likely to remain constant, and can be easily changed when necessary. (Such as in your example.)

So, technically, Moho using names instead of IDs is not a bug, but I imagine using the Action's ID could work as an optional alternative to names, provided the ID is editable. I feel the same way about custom Styles, although Styles use IDs rather than Names, and sometimes, I wish I could switch to Names for Styles instead. But I'm not a programmer, and I'm sure the reality is way more complicated than my layperson's description.

(BTW, Moho's PSD support sort of uses layer IDs. It uses Names first, and then switches to ID when a unique name isn't available or helpful. In general, using names has been more reliable, though. Spend a little time in Photoshop, adding, deleting, and merging layers, and you'll quickly see why. But even with PSD files, the layer ID isn't editable unless you want to jump into the file's code.)

[stephenthomas0]

Ah yes, I remember the great rollback, was working on a Moho project when it happened and we switched to 12.5 for stability reasons too.

I have some programming experience, not going to pretend I know how easy this would be to improve/fix though as I haven't seen the code, but it's not going to be impossible. I know Blender is a different program, but AFAIK they use an ID based system that uses the name as part of the ID, they enforce unique names for everything because of this.



I've never had any issues with constraints or modifiers getting confused about what object they're pointing at because of this, it's impossible for things to get mixed up, but if somehow two objects did get the same name, that would be a bug to be fixed. For items inside of an object (e.g. a bone in a rig), the bone is a child of the rig and the names of the rig and bone are included as part of that bone's ID. This way, you can have several characters using the same bone names because their ID includes the rig name too.

It's a shame that Smith Micro borked their implementation of an ID based system, but it could definitely be done right. It would no doubt break compatibility with earlier versions of Moho if they tried again, but I'd personally appreciate a more stable system. At the very least, if they do stick with a name based system, they should make names unique and enforce it when creating new objects, duplicating objects, importing objects and any other action that creates a new item or renames an item.

[Belgarath]

I tried to send them a reply with more details in the hope that it would help figure out what went wrong, but when I clicked 'submit' it kicked me out to the login screen and I can no longer log back in. All I wanted to do was provide information to try and help the devs figure out what's going wrong and make Moho more stable, but it felt very much like "This isn't a bug! Go away!"

Getting logged out and not being able to log in could be a cookie issue. You can reply to their emails directly, no login needed.

[stephenthomas0]

I tried to send them a reply with more details in the hope that it would help figure out what went wrong, but when I clicked 'submit' it kicked me out to the login screen and I can no longer log back in. All I wanted to do was provide information to try and help the devs figure out what's going wrong and make Moho more stable, but it felt very much like "This isn't a bug! Go away!"

Getting logged out and not being able to log in could be a cookie issue. You can reply to their emails directly, no login needed.

Tried logging in again today and it worked, maybe the cookie expired, thanks for the tip