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.
Found 81 posts.
Search results Show results as topic list.
Technical Discussion » muscle end constraint issue Houdini 20
- johm
- 127 posts
- Offline
Rigging » Muscle solver vellum issue
- johm
- 127 posts
- Offline
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.
Rigging » Muscle solver vellum issue
- johm
- 127 posts
- Offline
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.
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.
Rigging » Muscle solver vellum issue
- johm
- 127 posts
- Offline
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?
Edited by johm - April 18, 2024 11:58:28
Rigging » Muscle solver vellum issue
- johm
- 127 posts
- Offline
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 can take a closer look at what you're attempting to do.
thanks!
Technical Discussion » Muscle constraint problem
- johm
- 127 posts
- Offline
Please post a hip file so I might be able to help. Could the distance threshold be a problem?
Technical Discussion » Houdini 20, muscle ID Symmetry issue.
- johm
- 127 posts
- Offline
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.
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.
Technical Discussion » Palms and fingers in muscles & tissue simulation
- johm
- 127 posts
- Offline
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.
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.
Technical Discussion » Enhancing Houdini Muscle to match Ziva Muscle result
- johm
- 127 posts
- Offline
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.
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.
Technical Discussion » Muscle sim - Tissue surface not colliding with muscles
- johm
- 127 posts
- Offline
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.
Technical Discussion » Muscle sim - Tissue surface not colliding with muscles
- johm
- 127 posts
- Offline
please post a simplified example if possible.
Or if you're concerned about confidentiality, you could submit a bug on the support page.
Or if you're concerned about confidentiality, you could submit a bug on the support page.
Rigging » paint a vertex map for Muscle Constraint Properties weight?
- johm
- 127 posts
- Offline
While you can influence the MuscleToBone attachments somewhat, you cannot be entirely explicit with the points and primitives being constrained. The target primitives can be declared in a group, or multiple groups, but the muscle points rely on a muscle_id and a weight/mask.
When constraints use the Attachment Candidates parameter, they build a dictionary attribute that uses a {index:value} structure. The index must be a valid muscle_id, and the value can be any primitive group, ad-hoc or explicit. You can look at the candidates dictionary in the detail attributes of the geometry spreadsheet to help debug if you feel it's misbehaving. One frequently overlooked setting is to make sure your declare a valid muscle_id in the Group Parameter on the MuscleConstraintProperties tab(s). This is where the index key is acquired.
If you want to be more "specific" about which area of a muscle connects to which bone primitives, I suppose you could rely on Frankenmuscles to give you multiple muscle_ids within a single muscle tet mesh. But admittedly, this isn't a perfect solution.
When constraints use the Attachment Candidates parameter, they build a dictionary attribute that uses a {index:value} structure. The index must be a valid muscle_id, and the value can be any primitive group, ad-hoc or explicit. You can look at the candidates dictionary in the detail attributes of the geometry spreadsheet to help debug if you feel it's misbehaving. One frequently overlooked setting is to make sure your declare a valid muscle_id in the Group Parameter on the MuscleConstraintProperties tab(s). This is where the index key is acquired.
If you want to be more "specific" about which area of a muscle connects to which bone primitives, I suppose you could rely on Frankenmuscles to give you multiple muscle_ids within a single muscle tet mesh. But admittedly, this isn't a perfect solution.
Edited by johm - Jan. 17, 2024 13:50:55
Houdini Indie and Apprentice » Muscles/Tissues systems with external collision
- johm
- 127 posts
- Offline
It's possible to re-enable softbody dynamics on the cached muscle and bone geometry being supplied to the TissueSolver.
By toggling TissueSolver > Advanced > Relax Internal Geometry you enable a pin constraint that attaches the muscle and bone geometry to the incoming animated positions. If a pin stiffness attribute exists on the cached geometry, it can modulate the pin attachment strength. With a weakened attachment strength, collisions and other forces will push the cached geometry away from its animation.
In the flipbook below, the external collision object is pushing on the tissue surface. By painting a pinstiffness attribute on the cached muscle geometry, the collider is able to affect the otherwise rigid cache as a softbody. On the right, you can see the displaced muscles extracted from the sim.
By toggling TissueSolver > Advanced > Relax Internal Geometry you enable a pin constraint that attaches the muscle and bone geometry to the incoming animated positions. If a pin stiffness attribute exists on the cached geometry, it can modulate the pin attachment strength. With a weakened attachment strength, collisions and other forces will push the cached geometry away from its animation.
In the flipbook below, the external collision object is pushing on the tissue surface. By painting a pinstiffness attribute on the cached muscle geometry, the collider is able to affect the otherwise rigid cache as a softbody. On the right, you can see the displaced muscles extracted from the sim.
Technical Discussion » Muscle Vellum Solver no caching sim (houdini 19)
- johm
- 127 posts
- Offline
hi LaylaLDP
Unfortunately the cheetah asset is not freely available to test with since a full Ziva license is required.
Maybe you could zip up a small sequence of files output from the bone animation as well as your source muscle surfaces?
Also, it looks like you have FileCache nodes upstream in your muscle configuration that are reading sequeces of geo files? The chain of sops that process your muscles should *not* be time-dependent.
Unfortunately the cheetah asset is not freely available to test with since a full Ziva license is required.
Maybe you could zip up a small sequence of files output from the bone animation as well as your source muscle surfaces?
Also, it looks like you have FileCache nodes upstream in your muscle configuration that are reading sequeces of geo files? The chain of sops that process your muscles should *not* be time-dependent.
Houdini Indie and Apprentice » Deprecated muscle system vs New
- johm
- 127 posts
- Offline
Hi Lucas, sorry but the old system is no longer available. The Inflate SOP (muscle displace) is still alive though.
Technical Discussion » Need Help Ensuring Cohesive Deformation of Anatomical Models
- johm
- 127 posts
- Offline
When you say "...anatomical components are starting to separate..." are you still referring to the refitting process on the initial static model? Or are you point-deforming using an animated target mesh?
...ie is your initial refit used to generate a static output => which is then used as the source mesh in your animated deform? Or are you doing the refit and animation all in one step?
In some cases you may get better results by using two separate PointDeform SOPs. One to do *only* the Capture step, and the other to do only the Deform.
Another trick you might use would be to use the outer skin to deform only the skeletal bones. And if that's looking acceptable, then combine your skin and bones, and use them together as your deformation mesh. This would sandwich all the other anatomical elements inbetween. -sort of a simpler, stripped-down volumetric approach.
...ie is your initial refit used to generate a static output => which is then used as the source mesh in your animated deform? Or are you doing the refit and animation all in one step?
In some cases you may get better results by using two separate PointDeform SOPs. One to do *only* the Capture step, and the other to do only the Deform.
Another trick you might use would be to use the outer skin to deform only the skeletal bones. And if that's looking acceptable, then combine your skin and bones, and use them together as your deformation mesh. This would sandwich all the other anatomical elements inbetween. -sort of a simpler, stripped-down volumetric approach.
Edited by johm - Oct. 20, 2023 13:48:30
Technical Discussion » Musculoskeleton and character mesh are different
- johm
- 127 posts
- Offline
I hope I understand your question...
If you have an animation skeleton (a joint hierarchy) refit to match your target character, and you have the anatomical skeleton (the modeled bone surfaces) also refit to match your target character, then the joint transforms should drive the bone surfaces as you'd expect. Re-weighting should not be necessary.
If you have an animation skeleton (a joint hierarchy) refit to match your target character, and you have the anatomical skeleton (the modeled bone surfaces) also refit to match your target character, then the joint transforms should drive the bone surfaces as you'd expect. Re-weighting should not be necessary.
Technical Discussion » Musculoskeleton and character mesh are different
- johm
- 127 posts
- Offline
you would need to use a combination of TopoTransfer and PointDeform like in the following diagram.
TopoTransfer will conform your source skin topology to the shape of your variant models. You would use landmark locations to ensure feature correspondence is maintained.
Once you have generated a transferred topology (probably best to stash the output as it may be expensive to regenerate), then this will serve as a target, ie Deformed Point Lattice, for the PointDeform SOP to operate on the muscle, bones, or kinefx skel geometry.
Some cleanup may still be necessary, but this approach will get you most of the way there.
TopoTransfer will conform your source skin topology to the shape of your variant models. You would use landmark locations to ensure feature correspondence is maintained.
Once you have generated a transferred topology (probably best to stash the output as it may be expensive to regenerate), then this will serve as a target, ie Deformed Point Lattice, for the PointDeform SOP to operate on the muscle, bones, or kinefx skel geometry.
Some cleanup may still be necessary, but this approach will get you most of the way there.
Edited by johm - Oct. 6, 2023 11:44:30
Technical Discussion » Some advice about muscle and scale of character?
- johm
- 127 posts
- Offline
Technical Discussion » Rigging in the muscle system
- johm
- 127 posts
- Offline
acdum1857
1. In the muscle system, where should the rigging be on the body or on the bones?
In a full simulation of muscle and tissue these are the broad steps:
-rigging and animation is applied to the skeletal bones surfaces only.
-muscles are made solid from your muscle surfaces in a static rest position.
-The solid muscles are then constrained to the animated bones (bone surfaces) and cached to disk as a sequence of geometry files.
-the Muscle Solver is run to perform the simulation
-Tissue is built as a solid from your creature surface.
-the solid tissue is constrained to your muscle and bone geometry in a static rest position.
-The Tissue Solver is run to simulate the tissue which is constrained to the cached muscle and bone animation.
So the short answer is, you animate the bones. The bones drive everything else.
acdum1857
2. Is it possible to import geometry (body/bones) from a rigged object without rigging errors?
If so, where should this import be? Is it the 'Object Merge' at the start of the muscle pass?
Short answer is, yes. It's possible.
The Object Merge named: Import_Animated_Bone_Surfaces should point to the sop that displays the animated bones.
And question 3 is probably answered in #1 above.
The video tutorial is also not applicable to the SOP based workflow we've had since Houdini 19. That video demonstrates the outdated Object-Level workflow.
-
- Quick Links