chen_chen
BTW: Can I use muscle paint node before muscle properties? Do I need the muscle constraint properties vellum initialize all the constraints first?

Best to add MusclePaint at the end. Otherwise the nodes can overwrite the same attributes.

The biggest improvement in speed will come from reducing the heft of the Internal Geometry. Fewer points/prims will result in faster collision detection and sliding.
You can reduce the pointcount on the animated bones substantially and not lose much at all. It would help speed up your muscle sim as well. The muscle sim could be lower rez also, but you may want or need them to be higher rez for quality reasons. (I personally go as low rez as I can since muscles get buried deep below the skin anyway). In that case, use a PolyReduce with a PointDeform to down-rez post sim.

I also reshaped your core surface geo to something that I think will give you better results. ie a little more space for tissue action.

jmbrodsky
I'm curious. Do we need a core layer and surface or could we get away with just having a tissue tet/surface riding on the muscle sim

If you use the TissueSolver, then yeah, you have to use that setup.
(...But that's not 100% true. So long as you understand the relationships I just outlined above, you can break rules accordingly. For instance, the TissueSolver will still work technically if you blast the core and core surface upstream from the solver. But the muscle and bone attachment will be strictly coming from the surface triangles.)

The SkinSolver on the other hand is intended to work more like the outermost layer of tissue.
I have tried a Skinsolver directly over Frankenmuscles and it worked out pretty well.

Just for clarity:

Internal Geometry (muscles and bones) is both collision geometry, and an attachment target.

The Core attaches to the internal geometry.
The Core uses an attachment stiffness multiplied by the corefalloff attribute. Zero corefalloff means the core will not attach to the bones. Corefalloff of 1.0 means it's firmly attached.
The Core has collisions disabled.

Tissue (tetrahedrons) are attached to the Core. This attachment is weighted by the Tissue Attach Stiffness property. Tissue tetrahedrons have collisions disabled.
Tissue tetrahedrons are more often than not occupying the same space as the muscles and bones. Since the tissue tets do not collide with anything, this is allowed.

The Tissue Surface (triangles) have collisions enabled.
Tissue Surface has an attachment to the muscles and bones which is weighted by the Surface Attach Stiffness property.

The Rigid Group is a special point group that has collisions disabled, and a separate attachment stiffness to the muscles and bones.

If the tissue solve is taking a long time it's probably trying to resolve collisions (unnecessary collisions). But this is just my guess.
Are there portions of your internal geometry intersecting with the tissue exterior? I ask because in your mp4 attachment, it looks like you might have solidified the tissue *after* deleting portions of the surface geometry?
If you are using Blast to delete sections of your tissue, you may want to group all the points on the blast boundary and include them in the rigid points group (at least temporarily while your solving with a section of your tissue).

I believe the mention of using a Blast sop in the documentation was not trying to suggest a workflow where multiple pieces are solved one at a time. Rather, the Blast workflow is only meant to serve as an expedited testing workflow. ie, it's quicker to simulate with a small section of tissue before committing to the whole creature.

Regarding the limp hand, are there bones in that area? The Rigid Group is simply given a stiffer attachment between the surface points and the internal geometry. If there are no bones, there's nothing to attach to.

chen_chen
But I am not sure if vellum follow the rules.

Vellum follows the rules of XPBD.

Basically, giving a point more mass enables it to win more often in the tug-of-war that happens when multiple constraints push and pull point locations around. It has little to do with how much material is compressed into a volume.

Regarding the a tendon's "hardness", there's an additional MuscleProperties>Tendon Stiffness parameter that scales the stiffness according to the tendon mask. So tendon regions are stiffer than muscle "bellies" by default, and less prone to stretching/changing shape.
The ability to vary the mass density and the shape stiffness in tendon regions comes from two separate parameters.

I'm not sure it has a lot to do with speed of movement. That looks more like an initial setup issue where the skin layer is either too far from the tissue it's connected to, or, maybe it's intersecting with the tissue (too close?). You might be able to resolve it with the SkinProperties>Shrinkage parameters, but a hip file example would be helpful to see what's going on.

TendonMassDensity Scale will multiply with the muscle's solid mass density using the TendonMask as a mask. ie only tendon regions (the white areas) will receive the mass density scale.
It does not affect hardness. Increasing mass in Vellum in this context has the interesting side effect of "raising priority" for the stretch convergence. It doesn't really raise priority. In areas where mass density varies, there will be less stretching where mass is greater.

from that snapshot, it looks like your MusclePaint node is upstream from the MuscleConstraintProperties node.
So what I assume is happening is:

• MusclePaint is not painting values in the muscletobonemask attribute. It's getting initialized to 0.0.
  
• MuscleConstraintProperties is detecting an existing muscletobonemask attribute and not overwriting it out of an abundance of caution.
  

The result is a zero-weighted muscle-to-bone constraint.

You should either move the MusclePaint node downstream, and thereby let the MuscleConstraintProp node do the initializing, or, enable the MuscleConstraintProp>Mask Falloff toggle to force it to overwrite the muscletobonemask attribute via the parameters.

jmbrodsky
... What's the best way to get the muscles to stiffen up and look less goopy?

With the constraints setup as they are in the MuscleSolverVellum node, we can't get perfectly rigid muscles. A built-in ShapeMatch constraint would have been one way to do that, but in practicality it would serve more fringe use cases. Maybe something to include in the future?
Nevertheless, in your hip file, it would be advisable to include "some amount" of MuscleToBone constraint. This will help the constraint system hold muscles in place and not flop around.
The modified hipfile below manages to ungoop your muscles without the help of the muscletobone constraint, and with fairly low substeps. The main problem was the muscle Damping wasn't low enough to get a response from the shape stiffness. More substeps and constraint iterations could also help.
This, and other changes are commented in the attached modified hip file.

jmbrodsky
What's the correct way to attach the muscle to bones? It seems I can use the MusclePaint> Muscle End Mask or I can use the Muscle to bone mask. Also, when you use a MusclePaint SOP does that override any distance threshold that is set in the MuscleConstraintPropertiesVellum SOP?

Ideally the MusclePaint node should come after MuscleConstraintProperties. ie, use the parameters to get your constraint masks as far as you can, then use MusclePaint to refine.
In your specific case, the paint node was upstream, and muscletobonemask was being initialized to zero. The downstream MuscleConstraintProperties node was not overwriting this value because Mask Falloff wasn't toggled on. The zero value was just passing through.
MusclePaint does not affect the muscletobonedistance attribute.

jmbrodsky
When I use the Muscle To Muscle constraints. The Muscle attachments cause spikes in the muscle geo like every other vertex is being pulled. I've found Muscle Glue Mask yields a cleaner result I'll attach some pics as well

With weaker material properties and low substeps, MuscleToMuscle will potentially pull points into spikes. Internally, MuscleToMuscle uses Vellum Stitch, and MuscleGlue uses Vellum Glue. (The difference being one uses a point-to-prim attachment, and the latter uses a one point to multiple other points attachment -with no sliding).

jmbrodsky
Is there a way to sculpt a custom flexed shape for muscles? It looks like in the file Mio_muscle_setup from the Unreal demo the artist used an Edit and Femdeform SOP to achieve this on the bicep but it's not clear to me how it works or to set this up in my own file.

Yes. The workflow is described in this example available from the SideFX content library.
https://www.sidefx.com/contentlibrary/muscle-target-shape/ [www.sidefx.com]

You don't have to use the MuscleEnd constraint. In fact, there's a toggle on the MuscleSolver that allows you to bypass it altogether if you needed to do that.

If you do paint it out or disable MuscleEnds, then you need to make sure the MuscleToBone constraint is set up properly. That will be the only constraint remaining that will hold muscles and bones together.

If you turn on the MuscleToBone visualizer on the MuscleSolverVellum>Guides, do you see any constraint vectors? If not, does the muscle attribute: @muscletobonemask contain non-zero values? In the MuscleConstraintProperties node you should see a heatmap/mask for muscletobone.

If you want something really rigid... while it's not directly supported in the muscle solver, you could easily crack the HDA open and add a Vellum ShapeMatch constraint yourself.

Thanks for the example SEGAS. The key difference is in your regular Vellum setup, you are using the stiffness parameters without a Scale by modifier. In the MuscleSolver, we use attributes to scale constraint stiffness values.
The Scale By factoring is not a linear scale.
If you look at a geometry spreadsheet for the Constraint Primitives, and watch what happens to the stiffness attribute for tetrahedral stretch, (Scale By Value behaves just like Scale By Attribute):
Stiffness: 1 x 1000

No Scaling yields a stiffness of 1000.0
Scale By Value: 1.0 yields stiffness = 1000.0
Scale By Value: 1.5 yields stiffness = 31669.0
Scale By Value: 2.0 yields stiffness = 1e6
Scale By Value: 10.0 yields stiffness = 1e30
Scale By Value: 100.0 yields stiffness = 1e37

So getting back to your original question, try using much lower stiffness values to see a difference. Once you start getting into higher Muscle Properties Stiffness values, the constraint stiffness starts to max out.

That example file uses some significant Fiber Strength, and the muscles have a boosted lower end to the Fiber Scale range. (meaning that at their minimum muscletension, they still have fiber stiffness applied.) Fiber stiffness can make the muscles stiffer. Once you reach a high stiffness value, there may not be much visible difference. So maybe that's what you're seeing?

Hi
Please post a hip file so I can take a closer look at what you're attempting to do.
thanks!

Please post a hip file so I might be able to help. Could the distance threshold be a problem?

Hello, please share your hip file so I can take a closer look.

But in the meantime, ensure you are following the workflow as in the attached video capture.
-Go to the Symmetry tab on the MuscleID SOP
-enable the Apply Symmetry toggle
-enter your preferred naming prefixes for your Left/Right naming. (Something like L_ or Left_ etc.)

-Enter the viewport state for MuscleID,
-Click on a muscle to select it,
-Hit Enter to bring up the rename dialog
-Type the name of the muscle. Ensure the name you type is prefixed with your preferred Left/Right prefix.

If the name you type does not include the prefix, the string editing function won't find a substring to replace. So the ID will not be mirrored.
Also, the default mirror plane for this SOP is along the X Axis, with the origin at (0,0,0). Make sure your geometry is symmetrical about this mirror plane.

Extremities are usually animated separately and blended back onto the final quadmesh. Tissue simulation is typically avoided in these areas by either chopping them off, or grouping them into the rigid group. The rigid group will only help with constraining the points in finicky areas, or, where sometimes bones are intentionally penetrating the outer tissue layer.

However, if you are going to simulate hands/fingers, ensure you have enough of the Core layer present in these areas, and, that there is adequate weight in the @corefalloff attribute.
The Core layer is constrained to the muscles and bones and the attachment strength is modulated by the @corefalloff point attribute. The core layer is what will "follow" your bone animation most directly. The outer tissue layer is then constrained to the core, effectively animating the tissue from the inside-out.

Here's my quick take on it.... As Edward points out, our system is based on XPBD, which is fundamentally different in the way simulations are handled. Over-constraining can lead to problems when the geometry's shape stiffness can't put up a decent fight with the constraints that push and pull on its points.
I took a stab a generating something closer to your mp4. I reduced the number of tets coming out of MuscleSolidify (fewer points = fewer constraints), and then tweaked the properties a little.

The other thing I added, since smoothness was an issue -especially with the thinner tendon areas- was to use a DeltaMush sop on the output surfaces.

If you can share an example setup that includes your tissue I'd be happy to look at that too.

Hard to say from just a snapshot of the nodes. Do you have a valid t-pose attrib on your Attach geometry? You can also try blasting all but a small subsection of the skin (like a small rectangular patch), and feed that into the first input of the solver. Then on the Visualize tab, display the Attachment Vectors. There should be visible attachments constraining the piece of skin to the 2nd input geometry.