Hello out there,
I've been desperately avoiding doing any proper work… this is what filled the void.
The attached shelf tool is made to be used along with the Capture Layer Paint SOP, and when launched will prompt you to select a position in the viewport. Clicking on the surface of the mesh you are currently weighting will query the geometry for the capture regions currently influencing that primitive and if there is more than one, will bring up a dialog with the bone names (ordered by descending influence), so you can select which one you want to paint with.
If there is only one cregion influencing the primitive, it will skip the dialog and update the Capture Layer Paint to paint that cregion.
The script ignores weights below a threshold which you can set at the top of the script.
Made out of bad memories of trying to weight eyelids with bonkers amounts of ghosted bones all over the place and MMB clicking like a fiend Maybe someone else will find it useful.
Cheers!
PS. Assigning a hotkey is recommended!
Found 256 posts.
Search results Show results as topic list.
Houdini Lounge » Capture Layer Paint select cregion from mesh
- friedasparagus
- 402 posts
- Offline
Houdini Indie and Apprentice » mesh deforming (urgent rigging problem)
- friedasparagus
- 402 posts
- Offline
Oh the capturing definitely works thataway, it's just a shame to lose so much of what makes the biharmonic method rad when using a single point at the centroid of the bone… ‘Cause by-golly-gosh it’s good when you give it enough to work with
In the image, the left one being with the single point from the cregion, the one on the right with the rebuilt capture lines.
In the image, the left one being with the single point from the cregion, the one on the right with the rebuilt capture lines.
Edited by friedasparagus - May 7, 2018 13:25:29
Houdini Indie and Apprentice » mesh deforming (urgent rigging problem)
- friedasparagus
- 402 posts
- Offline
I knew something was bugging me
I repaired the hda to allow for multiple children and also fixed the ‘resmaple by segment length’ to never produce fewer than 2 points per bone…
Here's the update!
I repaired the hda to allow for multiple children and also fixed the ‘resmaple by segment length’ to never produce fewer than 2 points per bone…
Here's the update!
Houdini Indie and Apprentice » mesh deforming (urgent rigging problem)
- friedasparagus
- 402 posts
- Offline
Hello there,
This appears to be a weighting issue. One that arises from the Bone Capture Lines SOP not playing very nicely with how Houdini imports FBX characters - i.e. cregions in nulls as opposed to bones
If you turn on the display flag on the Bone Capture Lines SOP you can see what's being brought in for the biharmonic capture to work with. If the ‘Use Bone Link’ parm is switched on then you should see a mess of ‘null’ shapes being brought in… With ‘Use Bone Link’ switched off, you should see a smaller numbers of isolated points floating around (make sure point display is on to see this), which comes from the target cregion being of near-zero length. The problem is that neither of these options offer very nice capturing with the biharmonic method.
It's a problem that I'll surely hit at some point, so I knocked up a quick hda that works around the problem and rebuilds the capture lines ready for the solid embed. You can dig around in there to see what's going on
Drop it down between the bone capture lines and the solid embed node and it should give you better initial results… Remember to re-stash!
Hope that helps,
Henry
This appears to be a weighting issue. One that arises from the Bone Capture Lines SOP not playing very nicely with how Houdini imports FBX characters - i.e. cregions in nulls as opposed to bones
If you turn on the display flag on the Bone Capture Lines SOP you can see what's being brought in for the biharmonic capture to work with. If the ‘Use Bone Link’ parm is switched on then you should see a mess of ‘null’ shapes being brought in… With ‘Use Bone Link’ switched off, you should see a smaller numbers of isolated points floating around (make sure point display is on to see this), which comes from the target cregion being of near-zero length. The problem is that neither of these options offer very nice capturing with the biharmonic method.
It's a problem that I'll surely hit at some point, so I knocked up a quick hda that works around the problem and rebuilds the capture lines ready for the solid embed. You can dig around in there to see what's going on
Drop it down between the bone capture lines and the solid embed node and it should give you better initial results… Remember to re-stash!
Hope that helps,
Henry
Edited by friedasparagus - May 7, 2018 12:02:16
Houdini Lounge » padzero in vex?
- friedasparagus
- 402 posts
- Offline
hahaha! That's quite hilarious
Note to self… Never offer coding advice with a sore head!
Note to self… Never offer coding advice with a sore head!
Houdini Lounge » padzero in vex?
- friedasparagus
- 402 posts
- Offline
EDIT: Embarrassing code snippet removed for the sake of clarity… please see sane response below!
Edited by friedasparagus - May 2, 2018 07:49:11
Technical Discussion » Rigging- Add twist to a follow curve setup without using normals of curve?
- friedasparagus
- 402 posts
- Offline
Gah, borked the constraint on the chain_root. Try the download link again and the mesh should be there. The NURBs curve won't make any difference apart from the @twist handling.
Technical Discussion » Rigging- Add twist to a follow curve setup without using normals of curve?
- friedasparagus
- 402 posts
- Offline
Hey,
yeah, sorry I only patched up the twist problem on the mid_ctrl. There are a few other things that'll be causing you issues.
Firstly, the parent constraint probably isn't quite what you were looking for here - the rotations produced when doing anything in ry are giving you some nasty flipping before we even begin.
In the curve object, the polyframe is what was throwing you're normals for a loop when you pull the chest down below the hips, the normals should be set by the path cvs. Secondly, the resample SOP doesn't peform slerping of normal attributes, (I have submitted this as an RFE) so this will also be generating some strange results, so this is best avoided in the context of this particular setup.
The last thing in the curve object is that the InverseKIN chop only plays nicely (in regards to the twist attribute) with bezier curves. So if you want twist, at the moment you need to make sure that your output curve in a bezier. All of these are things that the default Path setup does for us, and alas there is not much room for deviation.
I've made these fixes in the scene file and also added a different constraint network in the mid_aim_util object which which feels slightly better to me (although it's not 100%), but there's lots of different approaches to be taken here.
This is certainly an area which needs some TLC in houdini. So hopefully we'll see some updates soon
yeah, sorry I only patched up the twist problem on the mid_ctrl. There are a few other things that'll be causing you issues.
Firstly, the parent constraint probably isn't quite what you were looking for here - the rotations produced when doing anything in ry are giving you some nasty flipping before we even begin.
In the curve object, the polyframe is what was throwing you're normals for a loop when you pull the chest down below the hips, the normals should be set by the path cvs. Secondly, the resample SOP doesn't peform slerping of normal attributes, (I have submitted this as an RFE) so this will also be generating some strange results, so this is best avoided in the context of this particular setup.
The last thing in the curve object is that the InverseKIN chop only plays nicely (in regards to the twist attribute) with bezier curves. So if you want twist, at the moment you need to make sure that your output curve in a bezier. All of these are things that the default Path setup does for us, and alas there is not much room for deviation.
I've made these fixes in the scene file and also added a different constraint network in the mid_aim_util object which which feels slightly better to me (although it's not 100%), but there's lots of different approaches to be taken here.
This is certainly an area which needs some TLC in houdini. So hopefully we'll see some updates soon
Edited by friedasparagus - April 27, 2018 06:44:32
Technical Discussion » Rigging- Add twist to a follow curve setup without using normals of curve?
- friedasparagus
- 402 posts
- Offline
Hi,
In order to add support for extreme twists you need to equip your path with a couple of point attributes: @twist and @initial_twist. Generally the latter can just be initialised to 0.
The problem in the setup you posted is that if you animate the ‘mid_ctrl’ for example, the twist attribute isn't being set on the curve, as this is tied to the “rz” parameter on the ‘pathcv2’. In order to fix this, you'd need to set the twist attribute from the ‘mid_ctrl’ rz. I cracked open the pathcv2 and made this change on the ‘twist’ node, and switched the IK solver back to ‘Best Guess’, it should behave as you expect now.
I'm not a big fan of the default Path/Path CV setup you get from the shelf tools - main reasons being
a) because the setup relies on non-uniform scales, we can't clean transforms without getting really wonky viewport handles and
b) we haven't got the option of ‘breaking’ the tangents on the curve.
c) solving things like you're initial problem involves cracking open multiple locked hdas.
I've also attached an hda that I threw together that creates a paired-down version of my go-to setup, so see if there's anything of interest in there.
Cheers,
Henry
In order to add support for extreme twists you need to equip your path with a couple of point attributes: @twist and @initial_twist. Generally the latter can just be initialised to 0.
The problem in the setup you posted is that if you animate the ‘mid_ctrl’ for example, the twist attribute isn't being set on the curve, as this is tied to the “rz” parameter on the ‘pathcv2’. In order to fix this, you'd need to set the twist attribute from the ‘mid_ctrl’ rz. I cracked open the pathcv2 and made this change on the ‘twist’ node, and switched the IK solver back to ‘Best Guess’, it should behave as you expect now.
I'm not a big fan of the default Path/Path CV setup you get from the shelf tools - main reasons being
a) because the setup relies on non-uniform scales, we can't clean transforms without getting really wonky viewport handles and
b) we haven't got the option of ‘breaking’ the tangents on the curve.
c) solving things like you're initial problem involves cracking open multiple locked hdas.
I've also attached an hda that I threw together that creates a paired-down version of my go-to setup, so see if there's anything of interest in there.
Cheers,
Henry
Houdini Indie and Apprentice » Capture weights editing problem
- friedasparagus
- 402 posts
- Offline
Hey Pete,
Whilst it's probably not an ideal state of affairs, I thought I'd knock together a couple of little examples of using the capture attribute unpack to perform some operations on capture weights that might be handy.
Even if I've missed the mark by some miles, maybe it might spark some ideas for you,
Cheers!
Henry
EDIT: I forgot to make a note of the the ‘Iterations’ parm on the grow_from_selection subnet, that's what'll control how far the weights will expand from the initial selection
Whilst it's probably not an ideal state of affairs, I thought I'd knock together a couple of little examples of using the capture attribute unpack to perform some operations on capture weights that might be handy.
Even if I've missed the mark by some miles, maybe it might spark some ideas for you,
Cheers!
Henry
EDIT: I forgot to make a note of the the ‘Iterations’ parm on the grow_from_selection subnet, that's what'll control how far the weights will expand from the initial selection
Edited by friedasparagus - April 7, 2018 07:32:33
Technical Discussion » Orient Constraint FAIL with CHOPS!
- friedasparagus
- 402 posts
- Offline
Hi Patrick,
what you have in your setup is what I would think of as being a pure orient constraint - the target object matches the orientation of the source object, but ignores all else.
Are you looking to have the pivot move with the orient_boss, but have the box keep it's own translations? In which case we'd have to build a rotation using the orient_boss's translate as the pivot position (If not, you'd be looking at a regular parent constraint).
Have a look at the modified scene file, and see if that was what you were after. There's three methods in there (all equivalent) - a transform wrangle, a transform vop network and using regular chop nodes. It was interesting for me that the transform VOP network came out a clear winner in terms of readability and so forth (I tend to run straight to wrangles )
See what you think,
Cheers!
what you have in your setup is what I would think of as being a pure orient constraint - the target object matches the orientation of the source object, but ignores all else.
Are you looking to have the pivot move with the orient_boss, but have the box keep it's own translations? In which case we'd have to build a rotation using the orient_boss's translate as the pivot position (If not, you'd be looking at a regular parent constraint).
Have a look at the modified scene file, and see if that was what you were after. There's three methods in there (all equivalent) - a transform wrangle, a transform vop network and using regular chop nodes. It was interesting for me that the transform VOP network came out a clear winner in terms of readability and so forth (I tend to run straight to wrangles )
See what you think,
Cheers!
Technical Discussion » Bone stretching Deformation and how to do volume preservation with stretch? (MIGRATION FROM MAYA)
- friedasparagus
- 402 posts
- Offline
Hi Patrick,
for volume preservation, what you're looking for is the crscale parms on the bone.
For the nasty deformations you're getting - that is just a bit of a hitch with how bones are created by default inside Houdini…
Right now, when a bone is created it's length parm is referenced by the zfactor parm on the cregion inside the bone. This causes multiple problems, but the one you're seeing is due to the fact that not *all* of the cregion is being scaled when the length changed - only the middle (tubular) portion. The end caps on the cregion remain constant in scale, which is why you see horrible stepping in your mesh when you adjust the bone length.
The answer I've found that works best is to break the channel reference to the cregion zfactor and instead drive the crscalez parm (labelled “Deform Region Scales”) on the bone itself by dividing the “length” by the “captposelen”.The crscalez will stretch the cregion as a whole (endcaps included) and give you the nice smooth deformation that you'd be expecting.
The funny thing is, that if you look inside the Bone object and find the cregion, you'll find in the Region->Animate tab a parm called “Squash and Stretch”… which is driven by the bones “Deform Region Scales”… which kind of makes sense of it all
Anyway, that was lengthy… here's a hip file!
for volume preservation, what you're looking for is the crscale parms on the bone.
For the nasty deformations you're getting - that is just a bit of a hitch with how bones are created by default inside Houdini…
Right now, when a bone is created it's length parm is referenced by the zfactor parm on the cregion inside the bone. This causes multiple problems, but the one you're seeing is due to the fact that not *all* of the cregion is being scaled when the length changed - only the middle (tubular) portion. The end caps on the cregion remain constant in scale, which is why you see horrible stepping in your mesh when you adjust the bone length.
The answer I've found that works best is to break the channel reference to the cregion zfactor and instead drive the crscalez parm (labelled “Deform Region Scales”) on the bone itself by dividing the “length” by the “captposelen”.The crscalez will stretch the cregion as a whole (endcaps included) and give you the nice smooth deformation that you'd be expecting.
The funny thing is, that if you look inside the Bone object and find the cregion, you'll find in the Region->Animate tab a parm called “Squash and Stretch”… which is driven by the bones “Deform Region Scales”… which kind of makes sense of it all
Anyway, that was lengthy… here's a hip file!
Edited by friedasparagus - March 13, 2018 13:15:30
Technical Discussion » Vex Question
- friedasparagus
- 402 posts
- Offline
I have a feeling it could be the globbing pattern in expandpointgroup causing the problem, don't think it likes “*”. Try taking the asterisk out
expandpointgroup(0, "")
Technical Discussion » How to drag drop Houdini Node onto QtWidgets.QLineEdit
- friedasparagus
- 402 posts
- Offline
Hi,
unfortunately at the moment it doesn't seem to be possible to get drag and drop events to fire in a QtWidget outside of a python panel… are you launching a dialog or such from the tool shelf?
PS… really happy if I'm wrong though
unfortunately at the moment it doesn't seem to be possible to get drag and drop events to fire in a QtWidget outside of a python panel… are you launching a dialog or such from the tool shelf?
PS… really happy if I'm wrong though
Edited by friedasparagus - Feb. 22, 2018 09:53:27
Technical Discussion » QtQuick Scene Graph vs QPainter hints
- friedasparagus
- 402 posts
- Offline
Hello out there,
Just wondering is anyone had any experience working with the QtQuick Scene Graph in pyside2 vs QPainter/QGraphics view? There are reported performance benefits on the qt website, but I was unsure about how render threads might be handled within houdini and whether it was worth pursuing the QtQuick2 route for further GUI work inside H,
Cheers!
Just wondering is anyone had any experience working with the QtQuick Scene Graph in pyside2 vs QPainter/QGraphics view? There are reported performance benefits on the qt website, but I was unsure about how render threads might be handled within houdini and whether it was worth pursuing the QtQuick2 route for further GUI work inside H,
Cheers!
Work in Progress » FK Control Interface for Houdini (WIP)
- friedasparagus
- 402 posts
- Offline
Speak-away-for-me-mad, ndickson Couldn't have put it better.
Glad the tool looks helpful though, Konfetka!
Glad the tool looks helpful though, Konfetka!
Technical Discussion » Modifying CHOPs with a Wrangle on a Per Channel Basis
- friedasparagus
- 402 posts
- Offline
Hi,
had a pop at a setup that might do what you're after… see what you reckon.
Think you were on the right track from what you said - run over channels to be able to store a previous non-zero value and set a “sample” attribute to store that value. Then in another wrangle iterating over samples, write this value back out (you already found that we can't currently write out to a given sample when iterating over channels, this gets us round that). Remember that there are three different kinds of attibutes in CHOPs - “clip”, “channel” and “sample”, this may have been tangling you up.
Hope this helps!
had a pop at a setup that might do what you're after… see what you reckon.
Think you were on the right track from what you said - run over channels to be able to store a previous non-zero value and set a “sample” attribute to store that value. Then in another wrangle iterating over samples, write this value back out (you already found that we can't currently write out to a given sample when iterating over channels, this gets us round that). Remember that there are three different kinds of attibutes in CHOPs - “clip”, “channel” and “sample”, this may have been tangling you up.
Hope this helps!
Houdini Indie and Apprentice » Attribute transfer problem. Not very precise?
- friedasparagus
- 402 posts
- Offline
Another option is to promote you're colour attribute to ‘Vertex’, and then transfer those. This method should work fine with the Attribute Transfer sops default settings too.
Work in Progress » FK Control Interface for Houdini (WIP)
- friedasparagus
- 402 posts
- Offline
Hello!
Just a quick demo of a WIP tool for speeding up FK control creation. Still rough around the edges but we'll get there!
Current immediate TODOs include:
Better interface/handling of hda folders
Toggle for simple, un-referenced ctrl nulls (as opposed to ones attached to bones)
Object naming section for creation of simple ctrl nulls/possible review of current object names
Cheers,
Henry
Just a quick demo of a WIP tool for speeding up FK control creation. Still rough around the edges but we'll get there!
Current immediate TODOs include:
Better interface/handling of hda folders
Toggle for simple, un-referenced ctrl nulls (as opposed to ones attached to bones)
Object naming section for creation of simple ctrl nulls/possible review of current object names
Cheers,
Henry
Houdini Indie and Apprentice » How to get an obj's world pos in a nice expression-friendly way (say for driving a particle source from a null)?
- friedasparagus
- 402 posts
- Offline
Oh, if it was going to an obj node's transforms, constraints totally the way to go.
I was thinking that we were looking at sticking an objects world space translate into a vector parm buried in a dopnet or some such… In which case you could possibly export the t channels from a Get World Space chop node, but the reference->scene data was fewer clicks
I was thinking that we were looking at sticking an objects world space translate into a vector parm buried in a dopnet or some such… In which case you could possibly export the t channels from a Get World Space chop node, but the reference->scene data was fewer clicks
-
- Quick Links