andy_vs

A common question with attachments is: 'does the selection order matter'

tl;dr: Not really for fixed. More so for sliding.

Long version:
The order of selection will determine what is the "source" and "target" of the attachment.

The mesh selected first becomes the "source" and the mesh selected second becomes the "target." For each vertex on the source mesh, the closest point will be looked up on the target mesh, and an attachment proxy is created.

You can select a group of vertices first, then a mesh object second, this will automatically paint the attachment weights to zero on the unselected vertices on the source mesh.

You can manually paint the attachment weights by right-clicking on the source mesh and selecting paint > zAttachment > your_zAttachment. Values between 0 and 1 are valid and multiplied against the zAttachment stiffness attribute. (weight stiffness stiffnessExponent)

Standard work flow for muscles, say for the bicep:
1. select a small group of vertices on the bicep mesh, at the origin (close to the bone), shift select the bone mesh, and run Ziva > Attachment.
2. Select a new group of vertices at the insertion of the muscle, shift select the bone mesh, and run Ziva > Attachment.

While the behaviour of fixed attachments will be similar when the source and target meshes are interchanged, when it comes to sliding attachments, source and destination meshes become more important.

Think about sliding a coffee cup over a table. Our attachment proxy points on the source mesh stay the same. (In this case the vertices on the bottom of the cup)
The attachment proxy points on the target (table) however are free to slide around the surface of that mesh. The attachment attempts to preserve the length of each proxy pair (depending on how stiff it is).

Imagine switching the source and target of the attachment in this example. It wouldn't make sense. If the attachment proxy points on the table stay the same (say a group of vertices in the middle of the table) the cup might tumble a bit depending on the mesh, but clearly the cup won't be free to slide around on the table.

Happy to clarify further if there's more questions on this stuff

Cheers
Andy

Vinodh

I found this information helpful. Great.

lisaE

Hi everybody, one question to attachments. First of all Ziva is really amazing 🙂 Working with it is so much fun! I am working on a pig at the moment. When I increase the substeps my attachments do not work correct anymore. I maybe should add that I changed the size of the zSolver along the way. Rebuilding the scene does not solve the problem. How can I increase the substeps without loosing my attachments?

jamesj

lisaE Thanks for the kudos Lisa, and glad to hear that you have been having fun with it 🙂
To help debug your issue, could I ask you for some more detailed information?
What does "attachments do not work correct anymore" mean? Did they get really loose? Did they disappear?
What was the change you made to the size of the zSolver? Did you make it bigger or smaller? By how much?

Finally, if you're able to share a file that demonstrates the problem you are encountering, or steps we can take to reproduce the error, that would be super helpful.

Thanks!
-jj

lisaE

hi james, I changed the zSolver size from 100 to 45. The attachments are still there but as you can see on the picture they are not in the right place anymore.

lisaE

jamesj

andy_vs

James just had to take a call, I looked into your scene. I can make the problem go away if I force maya to go to the corresponding subframe for each substep.

I noticed you've got a full rig going into your bone positions. Maya creates cycles everywhere, even if it doesn't warn you -- it's own orient constraint I think will even make a cycle. That makes it difficult for our solver to know where things are on subframes. This is part of the reason why we recommend using the puppet to control only the skeleton geo, which gets baked to Alembic. Then in a second scene, import the baked skeleton geo and drive your muscle sim with that.