Need help with using matrix constraint techniques along with joint orients

[marten.zanderBH2FZ]

Okay, what I am trying to do is very basic actually. I have two joint hierarchies, one being an exact duplicate of the other. Both hierarchies include two joint chains. One chain on the positive X and one on the negative x (mirrored). Now I want to use matrix constraints to lock the relevant joints to the duplicated one, no matter what. In case you don't know what I mean with matrix constraints, please check out this link:https://www.youtube.com/watch?v=7A98wukXsJQ&lc=UgydVWgq4hz0gdADnrJ4AaABAg.9cwn9CmIAPP9cx6bjnAFgI

Basically everything works fine, except for the mirrored side of my joint hierarchies. A behavior mirrored joint chain adds a value of 180 to the first joint's X orient attribute. It seems like these orient values also contribute to the world matrix output which leads to a double transformation with my current setup for the rotation channels. I created a little demo scene to outline the issue which you can find attached to this post. In this file you can find the two joint hierarchies and a red squared controller. On the controller you will find a "blend constraint" attribute which will blend between the constrained state and the default state. When you display the local rotation axis, you will notice that once the blend value is set to 1, the rotation axis don't line up, at least for the mirrored side. The joint chain without orient values will behave like expected.

I am sure there is a simple way of solving this issue, but I guess I just don't know enough about matrices and how to calculate with them in order to solve it on my own. If any of you can point me into the right direction I would be very grateful!

[Kahylan]

Hi!

Your issue stems from the fact that jointorientations need to be separately calculated in when you use matrix constraints, since the joint orientation is basically a offset transform above the joint itself that tends to mess up the constraint if it isn't in scene orientation (like your not mirrored arm).

Now you already have found Jarreds Channel and he has a video on this specific issue, so I'd say you best start there:

https://www.youtube.com/watch?v=_LNhZB8jQyo

I hope it helps!

[ShinyShadow41 · Accepted solution]

Yes, a matrix from a joint gives you the "joint orient" before the actual rotation. But unfortunately there is no easy fix(at least with vanilla Maya). I've put a link here that describes matrix constarints and there at bottom, how to fix that joint orient issue.

https://bindpose.com/maya-matrix-based-functions-part-1-node-based-matrix-constraint/

Fixing that with 5 extra nodes still faster than a constraint but gives more headache. I discussed this issue with someone else in another forum, here is the link, this might helpful.

https://tech-artists.org/t/getting-rid-of-joint-orient-values/15007

For me, i don't prefer using joints if not needed.

[Baboonian]

bindpose.com is a very cool site! 

Thank you ShinyShadow

[marten.zanderBH2FZ]

@ShinyShadow41 thanks for showing me that article, very useful and the provided solution actually does the trick. Now I am also wondering if creating these extra nodes is worth the work. But "work" is relative because I am about to automate the process I am working on using python anyways. So I won't have to deal with manually creating these nodes anyways. In this case, what would you suggest than? Going for the node setup or sticking to constraints?

[marten.zanderBH2FZ]

@ShinyShadow41 I also encountered an issue with joint rotations and orient when using the offsetParentMatrix instead of decomposing the final matrix and plugging the outputs directly into transformation channels. My mirrored joints will then have inverted y rotation values. Of course I won't use the offsetParentMatrix for this case but I was assuming plugging a matrix into the offsetParentMatrix or decomposing it and plugging it directly into transform Channels should have the same result.

[ShinyShadow41]

Like i said, this quaternion setup is faster than constraints but it's hard to handle so if there is a problem with rig, then it would be harder to debug something. If you don't have a performance problem then constraints are more useful. Also there is another trick i remembered now: if you zero out the joint orient values and transfer that orientation offset values from actual values to offsetParentMatrix, then problem is fixed.

[ShinyShadow41]

You're welcome. 🙂

[ShinyShadow41]

That inverted values comes from mirroring i think, because world position is changed. And using OPM instead of actual values is not gives same result always. OPM treats like a parent node above the object and OPM always at one above the object, no matter if you parent the object again to something else.

[marten.zanderBH2FZ]

@ShinyShadow41 yes, no doubt the issue comes form the fact that these joints are mirrored. But I don't understand what is technically going on under the hood. And actually plugging the same matrix into OPM or transform Channels should result in the same transformation as long as the transform channels are zeroed out if using the OPM.

[ShinyShadow41]

That OPM represents the 0,0,0 position of it's object. Now imagine a structure like that:

In this case if you move the parent1,2 or an another parent, OPM also moves with it. So that means OPM has moved in a local space and if you write a world location on to it, the results gonna be wrong. This case also like this if you freeze transforms of that object (because, remember OPM represents 0 position). You should do some experiment on these systems to understand properly.

[marten.zanderBH2FZ]

I feel like we are talking at cross purposes. All I say is either using transform channels or OPM shouldn't make a difference when using matrix constraints. I attached an example file. the left pSphere1 is a child of pPlane1 (using OPM) and pSphere2 is a child of pPlane2 (using transforms). And they behave the exact same way.

In your example it is clear to me that the object will follow the OPM group because it's a direct child. And yes, without touching the object itself it will never change its local transforms.

[ShinyShadow41]

Then, maybe i misunderstanding if there is still a problem or not? I think all i can say is: That's how Maya works.