geordiemartinez
Does the forgiveness have a radius or scale or attribute that can be modded? I have some finger tendons that are not intersecting the finger bones. On frame 1 they look like this:

Collision Radius can be visualized on the Guides tab of the Muscle Solver. Points in a state of intersection at the t-pose will be disabled. But this looks like something else is going on. Please submit a bug or hip file so we can take a closer look.

Yes, the workflow is built around the notion that your muscle surfaces will already exist.

While manifold, non-intersecting surfaces are strongly encouraged, they aren't a strict requirement. There is a certain amount of forgiveness built into the vellum MuscleSolver. ie, intersecting points will have collisions automatically disabled at startup to prevent explosions.

Hi Martin, this is mostly an issue having to do with the mass being calculated per point based on the size (volume) of the tet mesh and the supplied Density value. The smaller object effectively has a total mass of 0.001 times the larger box. Try setting your Mass Density to 1000 and increasing Substeps. Try at least 4 substeps for the sim to converge properly. This should get you in the ballpark where you can start adjusting stiffness values.
-j

Hi,
I took a look at your file and included a few minor modifications. Please see the sticky notes inside for more info.

To answer a couple of your other questions…
The purpose behind selecting Primitives after selecting the FrankenMuscle geometry is so that in situations where a model might have multiple muscles as separate pieces, you can extract specific groups from that model to use as individual FrankenMuscles. Since you have discreet geometry objects already, this step might seem redundant.

To constrain specific parts of a muscle, you can use a MusclePin object. This acts very much like a single-point MuscleRig. You can use the viewport shelf tool to place and adjust your pin, parent it to a bone, then include it as one of the rig sources on your FrankenMuscle.

Automating muscle flex activation in 18.0 is pretty open-ended. One way to go about this is to rely on an expression to drive the Flex>Tension parameter on a MuscleRig. The example in the attached file simply uses the bone angle between the two bones in the skeleton as a driver for the tension value.

And finally, regarding the collision penetration, a couple of suggestions might be to increase the resolution of your tissue surface to improve collision detection; perhaps try increasing substeps; and one or two of your muscles are modeled quite thin, you might try adding some thickness to them.

thanks
-j

this probably isn't exactly what you're asking for, but you can break tangent continuity at the first keyframe, and then use the ease-out segment type.

Hi HouUser, I'm not sure if Scott has posted the Minotaur example anywhere yet. The T-Rex legs demo'ed in the Muscles Masterclass video are available for download here [www.sidefx.com]. But these muscles are setup with only the skin deformer workflow (ie, non-FEM). The FEM version of the Masterclass and associated files will be available closer to the release of Houdini17.
thanks
-j

very handy Henry!
nicely done.
-j

(sorry about the busted formatting in that last post.)

Glad to hear you got it working.

I did manage to take a look anyway, and I think you stumbled across a bug in the way the the input nodes might have been disconnected from the solver, but the “Include” toggles were still instructing the solver to use those items. The solver may have been erroring out and it looked like it wasn't doing anything. I've committed a fix for this and it should be available in the next daily build.

The Target Strength parameter had to get up in the neighborhood of 30,000 in order for the tissue to not fall away from the animated target position.

When combined with a painted mask for the targetstrength, ie:


The solver produced this:



Without any internal bones or muscles, the tissue is only constrained where the mask is non-zero.

By adding some very simple bone geometry, it's enough to hold the bulk of the tissue in place:

hi alexis,
sorry I should have noticed the grid markers in your snapshot images, the scale for your character is huge. This is the source of your problem. When dealing with dynamics and the tissue setup, it's not only best practice, but almost essential, that you use real world scales for your objects. By default, houdini's dynamics use 1 unit = 1 meter. And unfortunately, it's not so simple to change the default unit of scale and have everything work correctly in this instance. You ought to consider scaling your character rig and your geometry objects by a factor of ~0.0015 to get in the ballpark. You should then re-capture at this scale to get your bone transforms to affect the skin geometry correctly.

can you post a hip file?

Tutorials will be ready early in the new year.

The incoming skin must always be static. The tetrahedralized solid version of your skin (the tissue) will be driven by any animated bones and muscles inside. If you look at the sop that is being referenced in the merge_static_skin node, you'll see that it will have skipped over the BoneDeform node in your animation, and instead merged in the static geometry that the BoneDeform operates on. If this input were animated, it would cause the skin to be solidified again and again on every frame. (This would be bad).

The current version of the Tissue Solver does, however, assume that your skin is animated via Bone Capture weighting & Bone Deform. If the capture weight attributes exist on your incoming (static) skin, the solver will detect them and use them. Internally, a BoneDeform operation will be applied to your skin geometry, and this animated position will be used as a Target Constraint on your simulated tissue.

Target constraint parameters can be adjusted on the TissueSolver>Tissue>Skin Animation tab. And, they can be further adjusted by the presence of painted point attributes named “targetstrength” and “targetdamping”.
ie, you can paint a “targetstrength” mask onto your skin, with a value range of 0.0 to 1.0, and then use the Target Strength parameter on the Skin Animation tab to adjust (multiply) it's final strength.

Keep in mind that the target strength is a force, and as such, it will attempt to attract your simulated tissue to the constrained location while factoring in all other physical forces at the same time. So your simulated result may not necessarily match your animated positions exactly.

Future versions of the tissue system will include a more intuitive paint setup, and support for skin animation coming from non-captured workflows.
-j

You'll need to establish a valid Capture Pose for your geometry and MusclePins.
To see the problem, on the FrankenMuscle:
-go to the Capture/Deform Tab
-activate Edit Capture Pose (All Rig Sources)
This will put all your franken rigs and your geometry in their respective captured positions. If your Pins are not intersecting the geometry, nothing will get captured.
When you're in Edit Capture mode, everything will turn blue.
You can drag your pins into position while in this mode and that can begin to fix the problem. If you do this, you'll likely need to adjust the animated positions of your pins as well.

However, a simpler way is:
-while your pins are *not* in Edit Capture Mode, ie, when they're in their “animated positions”, (colored red)
-Select your pins,
-Press Capture>Set Capture Pose
This will take the current pin positions & orientations and store them as the capture pose.

-j

hi,
MusclePins are not meant for that purpose. MusclePins are analogous to the end anchors on regular muscles. They are used as region constraints with FrankenMuscles.

When attaching muscle rigs to ik/fk bones, use straight parenting for the end anchors. Optionally you can use Constraints for this too.

For inner handles, you can use one of these methods:
Use a ParentBlend constraint to mimic a parent/child relationship between a handle and any other object,
Or,
Use the BlendPose tool to setup a “set driven key”-like relationship between your handle positions a bone rotation.

-And, a third option would be to just keyframe the placement of the inner handles if needed.

In applications where your muscle is being simulated with dynamics, collisions with the bones would do the physically correct thing, and the tricks mentioned above would not necessarily apply.

see the attached example. (H16.5)
-j

please try a more recent build of houdini. 16.5 preferably.

definitely a version issue. please use a more recent build. 16.5 preferably.

It looks like you may not have captured your geometry with “Regions” as the capture method. The default is to use the newer Biharmonic Capturing. Editing Regions doesn't really affect geometry captured that way.

Fixed in Houdini 16.0.669

Ah. Thanks Henry. And it seems to only happen when drag-selecting. I've filed a bug for this issue. ID=83677

The Edit sop simply stores change in point positions and uses the point indices to know which points to apply the differences to. If you change the number of incoming points, the Edit sop will apply the modifications to the “wrong” points.
If you have a small number of edits to apply, you might consider a more procedural approach where you define groups dynamically, and then have individual sops perform the edits using those groups. Something like the Transform sop, or SoftTransform.
If you have something more complex, then the other option would be to use your modified mesh as a deformer. The PointDeform sop, for example, will take the difference between a modified mesh and its rest mesh and apply that to a separate geometry.