bindPreMatrix/worldInverseMatrix issue, workflow quesiton

[Anonymous]

This is a follow up to my previous post

I've been trying to follow a tutorial on bindPreMatrix, however almost immediately I run into an issue - when trying to plug the worldInverseMatrix to one of the bind Pre Matrix parameters that mirror the Joint connection to Matrix parameter in skinCluster node, like in the video, the skinned geometery snaps out of the skeleton mesh towards the skies! In the video, the person plugs wrong parameter of the objects - WorldMatrix - to bind Pre Matrix attribute, and it snaps the object the same way. However, he manages to fix it by plugging the worldInverseMatrix, and me? I'm not so lucky!  I've even recreated the scene from the video, but the same issue occurs. 

Ultimately I want to be able to drive the skinned joints from a blendshape, like I've described in my previous post, but running into an issue from the get go is extremely discouraging. I've been trying to read the documentation but there's barely any info on bindPreMatrix parameter, and that one video tutorial is the only thing that describes the workflow similiar to what I'd like to know. Feeling really bad to be forced to make threads all the time also! Sorry! 

[zewt]

Can you attach a scene with the connection you've made?  What he does in the video is correct, so I need more info to see what you're doing differently.  Make sure you're connecting to the correct bindPreMatrix entry.  Each element corresponds to the joint index, so you need to connect to the same index as in the matrix array.

It looks like you're following that tutorial to learn how bindPreMatrix works rather than just to edit joints, but FWIW I wrote a tool a while back to automatically set up basically what he's doing in that video.  Maybe it'll be useful: https://zewt.github.io/zMayaTools/tool-create-editable-joints.html

One thing to beware of: if you ever connect something to bindPreMatrix and then disconnect it, it'll break the skinning, since the bindPreMatrix entry will be deleted.  I worked around this here: https://github.com/zewt/zMayaTools/blob/master/scripts/zMayaTools/skin_clusters.py#L264. Just FYI since it trips up anyone trying to rig bindPreMatrix.

[Anonymous]

Hey, thanks for reply again! I'm attaching the scene with two test rigs, one is connected through invertWorldMatrix at 4th joint, the other's not.

Meanwhile I have tried out your script - it worked when I've selected every joint in the chain, however trying to apply it for either one of the joints breaks geo, I'm attaching screenshot. I've tried out your script on one of the DAZ models, and it seemed to work, even though I couldn't select the root joint, had to select hips and up. And yeah, I've noticed that disconnecting the node deletes bindPreMatrix, since it breaks the rig for some reason for me though I'm not worrying too much about it yet. 

Your script is very good and I'll definitely use it to move multiple joints, but like you said, I want to learn this and potentially do something with it, ideally I'd want to drive the position and scale of joints with a blendshape. The more I think about the whole concept though the more I get discouraged. It just bugs me that joint translation could be locked and driven by a morph in daz, I guess.

[zewt]

The world matrix of pCube_connected_inverse isn't actually the same as joint4.  It's actually at the origin (with a slight translation from the "connected_geo" parent, which might be unintentional), where the joint is at Y=6.64.  You can check this by looking at pCube_connected_inverse.worldMatrix[0], or running xform -q -ws -t pCube_connected_inverse.  What looks like a translation is actually just the pivot.

The problem is probably that you're using a regular transform to hold the bind matrix instead of a joint.  Joints and regular transforms have different transform setups, for example joints have jointOrient which transforms don't have, so trying to make a transform match a joint can do confusing things.  I'm not sure what exactly would have caused the translation to move into the pivot like that (the cube is offset from the transform, so I'm guessing something to do with baking transforms), but if I duplicate joint4 and use it instead, it works correctly.