Parasitic Values Limbs and Twisters

[Dave_Moulder]

One issue that’s erked and plagued me is the way that mgear uses the roleSpline calculation to work out the rotations for the final joints.

Suppose we take a standard EPIC leg component. The knee joint isn’t calculated with a clean rotation (4); that’s because the root of the leg is counter-rotating (1) as part of the twist calculation. It’s also common to only have one twist joint in game development. But because the U value is only halfway through the rollSpline U value, it never makes the 100% twist (2). So the skinned knee will never point at the pole vector. (3)

It’s important in games that we keep the skeleton as clean as possible. It offers benefits for animation compression, blending poses, and running post-process rigs. Just in animation compression alone, this can add up if there are lots of characters on screen.

In game development, we strip joints out of the rig at lower LODs. In the current setup, if I strip the twisters, the twist shearing happens at the knee as the skinning of the twisters propagates to the leg root. (1) So the candy wrap effect at the knee is more prominent at extreme poses. So far, tho, I’m only stripping joints out at lower LODs, but I know this will be a problem on consoles where we offset the LODs for performance, so LOD2 becomes LOD0 on lower spec. I’m waiting for those skinning bugs to appear on lower-end devices.

What’s the solution?

Right now, I can post-edit the rig to fix the twister and achieve the correct rotation at the proper position by running another roleSpline and merging the result to the div_loc.

I can’t fix the parasitic knee rotations without rolling my own component.

[remicc]

Hello!
I’ve been having some issues with parasitic rotations, and I haven’t found a solution yet. I agree with you — parasitic transforms can have a noticeable impact on the game, and I could provide some other examples.

I add a question for mGear developers:
Is there a reason why the first joint of the limb is aimed toward the front of the character instead of lying in the same plane as the leg?

I mean, if each joint of the limb has the same up vector and aims toward its child, then we would have only one axis of rotation, and all roll joints would have clean transforms (assuming there is no translation except along the forward axis for any joint in the chain).

I’m really curious about the explanation behind this choice.

[Dave_Moulder]

I’m with you. I think that mgear is excellent, but it comes from a film and VFX background where the skeleton is just a result of the rig stack, a byproduct that isn’t carefully managed enough to meet the demands of game production. In games, the skeleton is a 1st class object; it needs to be highly managed and carefully thought out.

Internally, we are already considering switching to a custom rigging pipeline, where the skeleton is at the front of the chain, and rigs are defined by adding metadata to the skeleton. Meaning we can uplift any historic skeleton to an internal rig.

The other option is to stick to mGear and work with them to solve these issues. Just because it has EPIC in the component name doesn’t mean best practices are followed for game development.