Parasitic rotations / translations

[remicc]

Hello !
I’m stil struggling with clean orientations and translations for a custom game biped.
Here is some screenshots :

I wrote some POST scripts to reset joint orients or override values inside some nodes like matrixConstraint but could produce side effects.

It happens mainly on spine and neck (EPIC_spine_cartoon_01, EPIC_Neck_02 are the ones I use).

What is the proper way to have a rig that has minimum parasitic rotations / translations ?
Also, I think the best way to create a game-ready rig is to use controls that orients bones only to his main children, not be oriented as a tangent of the curve. That’s why I have maybe half of the guides unusable for me.

Do you have any idea ?
Thank you in advance, and congratulations to the devs for the new release of mGear 5.0 !

Rémi

[Miquel]

@remicc Not sure if I understand the issue. The translation can be ok with values, right? and about the joint orient value that always used to ensure that the Rotate values are 0,0,0, right?

if you can give me some examples on the expected results vs the current ones. I will check it
Thanks!

[remicc]

Well in my humble opinion, i think the less parasitic value we have, the proper skeleton we get. Ideally, If I create a skeleton by hand, i would put each joint pointing toward his children, so only X value will be different than 0. If a joint of the spine has translations in Y or Z, it means that my parent joint is not aiming properly to the joint.
Also, if I want to create some automations from the skeleton, it would be better if I have no offsets.
It is ordinary to have multiple transformations in multiple axis for the first joint of a chain, but I would like to avoid it on each children of the chain.

Here is an exemple (a little bit exagerated) :

Left side : wrong orientations
Right side : clean orientations

Is my explanation better ? Let me know if

[chrislesage]

@remicc

so only X value will be different than 0

That’s clear. To only have a single axis in the translate is the most clean.

But what about the jointOrient? I don’t know if that’s avoidable, as far as I know. I would expect any arbitrary values (1, 2, or 3 values) in the jointOrient.

[Miquel]

@remicc Thanks for the explanation I get it now. Specially in joint chains can be cleaner.

But as @chrislesage commented JointOrient will have values in some places, like the first joint or the knee/elbow

I will create a ticket to research this

[remicc]

For elbows and knees (or any 3 joint setup), it is possible to have only one axis of rotation with some maths to make joints having the same XZ plane (in case Y is the up axis).

So in the following image : the rotation is only stored in Y axis.
And there is always a solution for 3 points. It’s not the case for 4, but that would avoid some tiny values and helps generating a more cleaner skeleton.
It will help for spine too because the spine is generally in the plane YZ of the world…

Whatever the rotation informations are inside joint orients nor rotation, we can find the proper matrix to orient joints, that what i would expect of mGear when it comes to generating skeleton

…and of course the first joint of the chain doesn’t follow this rule because it’s the first joint ! I only talk about children of the chain

[Dave_Moulder]

@remicc

I’ve struggled with components in mGear, which give me parasitic values, as you put it. For years, I used to handcraft skeletons (after all, they are just like guides). As I was always taught, the best practice was to have the bind pose identical to zeroing out all the joint rotations. And that only one channel in a chain would contain translation data. AKA joint chain length. The roots of chains will have more than one channel of data. Then, we’d do custom orients of joints (not aligned to children) for specific joints, such as the head and the ankle. For example, the ankle is aligned to the world but pointing towards the end of the foot (toe). This means the Rig would use these orientations, making it sensible for animators and a clean channel graph.

mGear was the first auto-rigging pipeline I’ve used that wasn’t built by myself or the studio I’ve worked at, and these rogue values had me scratching my head. I would also appreciate it if this could be fixed where possible.

I resorted to building the rig, publishing it, stripping out the skeleton to a new file, fixing the issues, and then referencing it back into the rig. Also, some components will make joints on top of each other. This is wasteful and confusing for games, so I clean that stuff up in the skeleton, too. Eventually, this became a scripted pipeline.

[remicc]

Thanks for your feedback ! I agree 100% of your feeling, it’s exactly what i’m doing on my side too !

[Miquel]

Thanks for all the feedback here

I have created a new ticket to review and fix this ASAP

Shifter: Fix parasitic values on Joints

if you have any advice or more feedback on this topic. Pleae let me know.

Thanks!

[DavidM]

This has been a big issue I have to deal with, also not have a consisted axis orientation, direction, for game developement this consistency is crucial, for example in the spine module a minimum variation in positioning of the guides could flip opossite the direction of the resulting joint, so a minor ajustment in the positioning of the guides could have big consecuences in the updated versión of the rig resulting joint hierarchy.
I’m only familiar with regular modules not with epic ones so I don’t know if this thing about axis orientation/direction consistency was something adressed in those modules.

[remicc]

In my opinion, EPIC modules are better for our needs. It has more customization and some of them use maya splines so joints won’t be tangent but aims to their children and it’s better for game anim.

[DavidM]

Unfortunately they were under development when I have to chose between existing modules.

[remicc]

I guess it is a good point because it will receive updates if needed, as Miquel did few days ago on the bugs I reported !
And there is no problem if they are simple like layered controls or chains…
You just have to test it before implementing in the rigs