Something went wrong while trying to load the full version of this site. Try hard-refreshing this page to fix the error.

Female WIP

robert

Hello All,

I've been lurking the forums for a while and am completely amazed by all of the work that has been done here.
Doing muscle simulation is something that I have put off for way to long, so recently I have requested the 2 month trial to have a go at this myself. With this first post I am hoping to start a discussion of my journey using Ziva Dynamics and gain feedback from professionals.

Before requesting the trial I put a lot of working in creating/rigging a skeleton using an auto rigger system I have written myself in previous years. The skin has been modelled by a colleague and very talented artist ( Michael Falzon ), at Digital Surgery. With the skin created I filled in the internals using various references.

This is a small clip of the skeleton in action:
For any final work I am thinking of using the dance mocap data available pre Maya 2016.

To speed up my workflow I've created a GIT repository that will contain all of the utils/tools I've written to help create content faster.

One of these tools helps me import and export animation easily:
The exporter allows you to shift animation and add the preroll animation by setting all keyed attributes to it's default value. The root contains the skeleton. The character name is baked into the export to match animation exports with their muscle rigs. The container contains all of the animated controls of the rig. And the mover is the up must control of your rig.

This exported alembic file can be referenced into the muscle rigs.
As the exported animation is tagged, the importer will recognise any animation files in the scene.
The root contains all of the muscle geometry and the character name needs to match the animation exports. The animation attribute contains all of the animated geometry to be connected, ideally the hierarchy is a straight copy. The ziva solver also needs to be provided for that first frame jump step animation.

In my brief experience using Ziva also made me notice that setting up sliding attachments is very important and there can be many. The following util will select all meshes based on a proximity value, which you can then isolate select to setup your attachments without unneeded geometry in view.

import zGeometryProximity.ui
zGeometryProximity.ui.show()

Another popular one has to do with Line of Actions. This utils help creation and clustering of the curves. It uses the commands coming with Ziva, it just helps with the naming of things.

import zLineOfAction.ui
zLineOfAction.ui.show()

Hoping to get some time over Easter working on the muscles.
Cheers,
Robert

andy_vs

With your rivet stuff, we now have zRivetToBone (as of Ziva 1.6). Should result in fewer nodes for setups and not require 3rd party scripts. Just an idea for your build script, you might want to support zRivetToBone as well! 🙂

tristan_cordeboeuf

robert

Thank you Tristan and Andy.

The need for riveting to the bones is something I wanted to ask a question about. In your video tutorials you mention that constraints don't properly evaluate on sub frames. Same goes with say linear interpolation on rotation values at a sub frame level might give you strange results. When baking out an alembic using sub steps I am not seeing those artefacts which mean I have been parenting my clusters to the transforms. Only downside seems to be that I have to keep the substeps on the alembic and ziva solver in sync. Is there something I am missing?

andy_vs

So with the evaluation on subframes, issues arise because many Maya nodes introduce cycles. When we use the Maya API to query where things are on subframes, we can't actually guarantee where the bones are because of those cycles. Now, because Alembic doesn't seem to present cycle issues, we can be confident where bones are on subframes, therefore it makes sense to rivet to the bones, as we know where everything is.

This is a slightly different problem to rotation 'snap shots'. It looks like you've already solved that issue with baking on sub-frames.

Riveting to the cached bones will work in both cases.

robert

A little bit of progress made:

Still working on getting comfortable with the toolset.
My plan of approach is to make the muscles work nicely on simple animations on single body parts before moving to more complex animation. Is this similar to the workflow some of you have used?

robert

andy_vs
Thank you for the explanation. I might be alright in that case. The workflow I'm using connects the alembic nodes attributes straight into the transforms/meshes on the muscle rig. No Maya nodes are used to drive the animations.
Will keep an eye out for any cycles. Are these cycles something that is logged when increasing the sim verbosity?

robert

A small update on the tools front:

The code below will reverse the direction of the fibers ( I don't think it actually matters at this point ).
But to keep things consistent I am keeping black as the origin and white as the insertion. The following code will just reverse the colors on the endPoints attribute.

import zCopyWeights
zCopyWeights.reverseFiberDirectionFromSelection()

Another things I found usefull is to be able to transfer maps between different nodes. An example is if the fiber weights are already painted you might want to create a material layer with that fiber map. The following code will fire up a UI that will allow you to transfer maps and reverse the values of needed.

import zCopyWeights.ui
zCopyWeights.ui.show()

Been making some progress on the sim side as well. Will hopefully have time to sim some frames and post some gifs tomorrow.

andy_vs

I like the idea of being able to copy maps between nodes.

Also would be great if you could invert them. (The invert function would do what you want with fiber direction too, seeing as the end points map is 0, 1 or 0.5. But of course it would be more general)

Here's an example I can think of where something like your tool would be useful:

That map is for a material layer (zMaterial.weights), but it would be cool to transfer it to the zTet.weights, and then invert the map so there's more tet resolution between the plates.

robert

andy_vs Haven't even thought about the zTet.weights example. Been coming across that now working with the tendons on the toes. Currently as long as the vertex count matches up you can transfer across any paintable attributes between any of the nodes.

I had some issues finding the paintable attributes. First I tried to get them using Maya commands the results were a bit off when no weights had been painted on an attribute for example. Have since pushed an update that gets it from the MAP_LIST attribute on the Ziva nodes in the zBuilder.

robert

Another small update:

Still working with the standard mocap data from Maya 2018.
Having some issues making the muscles move as a block together. The rectus femoris has a lot more freedom as the other vastus lateralis and medialis. Ideally I would like to see the rectus femoris push the mass of the muscle to the side on side ways movement. Because at the other end when locking in the rectus femoris within the two muscles the whole block locks way to solid. Would any if you have any tips on how best to achieve that?

Another problem I am having is creating gaps in extreme poses. Is this something to worry about as it might cause issues when simulating the skin later on?

mikeporetti

i think decreasing the tet size will fix alot of the problems youve circled, but also make sure your attatchment weights are thinly painted to the actual attatchment area and dont falloff too much down the muscle

robert

mikeporetti Thank you Mike, will give this a go after coming back from FMX 🙂
Edit: Seems the decreasing of the tets has had some effect. Think when simulating the skin will have to see how low I must
really go. Scene is starting to get slooooow haha.

robert

Another small update for today. Far from perfect results so far.
Will have to fix the trapezius in place a bit more near the spine area, but quite pleased with the shoulder area itself.

I think the main problem I am having is that I tend to constraint things into place a bit too much. Not seeing the jiggle I would like in the triceps and biceps. Will try play around with the sliding constraints tomorrow.

mikeporetti

robert

Another small update for today. Have since moved onto the forearm which unfortunately is causing me issues requiring a bit of remodelling.

Loosened up the attachments to the triceps a bit giving it more of a giggle when moving around quickly.

Also did some work setting up the line of actions and fibers for the upper arm.
As always any feedback is welcome 🙂

robert

Another thing I would like to share with you is amanager tool. Upon opening it will list all of the bones and tissues present linked to a solver. The tissues are grouped by their direct parent which makes it easier to enable and disable muscle groups.

A callback is registered to populate the mesh detail when it is selected in the scene. You can also populate the ziva detail by clicking on the mesh button in the UI itself. The ziva nodes can then be selected by clicking on their buttons. But it is also possible to select for example the source and target mesh of a zAttachment. Or go into the paint mode on anything paintable.

It will also link the zLineOfAction linked to the mesh rather than the zFiber which makes it easier to find / select.

andy_vs

robert

andy_vs Thank you Andy. I think there is, it is retargeted from the sample that comes with Maya 2018 which contains the noise. Still looking to get my hands on some clean character animation. I am hoping that only minor tweaks will be needed after checking the contraction and movement based on animation clips that target individual muscle groups.

Thank you for pointing out the Ziva Scene Panel. Completely overlooked it 😅 . Will deprecate the code and use the Scene Panel instead. It does exactly the same job but better haha. Should learn to press a few buttons before thinking it hasn't been done before.