Hi howiem,
Have you checked out the RMB menu on a parameter? Try going to Reference->Scene Data and then in the selection dialog find your target obj and look under Transforms->World. This will populate the parameter with a bunch of expressions (that you probably wouldn't want to type by hand )
Found 256 posts.
Search results Show results as topic list.
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
Technical Discussion » Multi object/channel CHOP Structure question.
- friedasparagus
- 402 posts
- Offline
Hi Judah,
Yes, this is a bit of a mismatch between the fetch and export CHOP nodes.
There are two methods that I can think of off the top of my head to get around this - one is to reorder the channels to match the order expected by the export chop using a Reorder CHOP, the other is to rename the channels and export directly from that rename CHOP (with the export flag).
When turning on the export flag of a given CHOP node, houdini uses the nodes ‘Export Prefix’ (under the Common tab) and the channel name to lookup the channel to override. By default the export prefix is set to “../..”, so a chop node with a channel named object1:tx will export to “../../object1:tx”.
Take a gander at the examples and see if it helps! Of course, in both our examples we are working with object names that are easily globbable (if that IS a real word ), if we want to generalise this to work with completely disparate object/channel names then we would probably be looking at a dive into VEX land.
Cheers,
Henry
Yes, this is a bit of a mismatch between the fetch and export CHOP nodes.
There are two methods that I can think of off the top of my head to get around this - one is to reorder the channels to match the order expected by the export chop using a Reorder CHOP, the other is to rename the channels and export directly from that rename CHOP (with the export flag).
When turning on the export flag of a given CHOP node, houdini uses the nodes ‘Export Prefix’ (under the Common tab) and the channel name to lookup the channel to override. By default the export prefix is set to “../..”, so a chop node with a channel named object1:tx will export to “../../object1:tx”.
Take a gander at the examples and see if it helps! Of course, in both our examples we are working with object names that are easily globbable (if that IS a real word ), if we want to generalise this to work with completely disparate object/channel names then we would probably be looking at a dive into VEX land.
Cheers,
Henry
Houdini Lounge » For loops and timeshift
- friedasparagus
- 402 posts
- Offline
Hey Matt,
interesting pickle! My best guess would be that having the block begin set to fetch input grabs the incoming geometry on each iteration, whilst iterating over pieces grabs to the incoming geo once, and then runs - meaning that the time shift hasn't got anything to refer back to within it's own scope.
Pretty much a stab in the dark though. I'd also be interested to know of Reasons
interesting pickle! My best guess would be that having the block begin set to fetch input grabs the incoming geometry on each iteration, whilst iterating over pieces grabs to the incoming geo once, and then runs - meaning that the time shift hasn't got anything to refer back to within it's own scope.
Pretty much a stab in the dark though. I'd also be interested to know of Reasons
Houdini Lounge » Trying to teach myself CHOPs
- friedasparagus
- 402 posts
- Offline
@Daryl Dunlap, great to hear you're getting your feet wet with CHOPs Look forward to seeing some goodies!
@matthias_k, had a quick look at your scene, and had a little go at cleaning up the chopnet. This idea did involve changing some stuff in sops too in order to track the frame at which the triggering occurred… see what you think, it may give you some ideas.
@matthias_k, had a quick look at your scene, and had a little go at cleaning up the chopnet. This idea did involve changing some stuff in sops too in order to track the frame at which the triggering occurred… see what you think, it may give you some ideas.
Houdini Lounge » To Character Rig... or Not
- friedasparagus
- 402 posts
- Offline
Hey eitch,
Here's a possible quick setup for replicating the approach you linked to - try not to pay too much attention to my painstakingly crafted blendshapes here
There's two versions in there (inside /obj/tommy/chopnet1), the orange network box is the one that most closely matches the SI version, the green network box is a one-node vex version. See what you make of it.
Cheers!
EDIT: Oops! In order for the behaviour to be identical between the two versions you'd have to move the math chop upstream of the limit chop nodes - at the moment the limit is placed before the multiplier is applied (which means the min/max values are -85 and 85!)
Here's a possible quick setup for replicating the approach you linked to - try not to pay too much attention to my painstakingly crafted blendshapes here
There's two versions in there (inside /obj/tommy/chopnet1), the orange network box is the one that most closely matches the SI version, the green network box is a one-node vex version. See what you make of it.
Cheers!
EDIT: Oops! In order for the behaviour to be identical between the two versions you'd have to move the math chop upstream of the limit chop nodes - at the moment the limit is placed before the multiplier is applied (which means the min/max values are -85 and 85!)
Edited by friedasparagus - Dec. 22, 2017 09:30:43
Technical Discussion » Points Attribute transfer Dilemma - @ptnum
- friedasparagus
- 402 posts
- Offline
Hi Bogdan,
The hitch there is that you're removing all the points on the same, single timestep -with the delete SOP not having any knowledge of what order the points were “tracked”. In order to get it going, we need some way of recording the order they were added in, the Solver SOP being the natural place to put this.
Here's a couple of examples, the first creates geometry inside the solver, and so we get well-ordered points for free. The second option uses attributes much like before, but I've added a second attribute that gets set to the frame number when the point gets set to active. Then later on you can sort your points based on that ‘active_frame’ attribute.
Hope that helps,
Henry
The hitch there is that you're removing all the points on the same, single timestep -with the delete SOP not having any knowledge of what order the points were “tracked”. In order to get it going, we need some way of recording the order they were added in, the Solver SOP being the natural place to put this.
Here's a couple of examples, the first creates geometry inside the solver, and so we get well-ordered points for free. The second option uses attributes much like before, but I've added a second attribute that gets set to the frame number when the point gets set to active. Then later on you can sort your points based on that ‘active_frame’ attribute.
Hope that helps,
Henry
Houdini Indie and Apprentice » Customizing the New Auto Face Rigger
- friedasparagus
- 402 posts
- Offline
Hi,
Thanks for the link, that's a really nice looking rig Very comprehensive.
Did you check out some other pages discussing it? www.olivier-ladeuix.com [www.olivier-ladeuix.com]
There's some ongoing links from there to where Spiel Kind was running through their working process.
Lots of blendshape work here, apparently 27 shapes which were then split up and masked out to create 90 separate shapes. This then combined with ‘joints’ (bones) to control broader deformations.
The connecting of control objects to blendshapes is likely to be done with ‘set driven keys’ as they are called in maya, with the houdini equivalent being ‘blend poses’ which uses the blendpose chop [www.sidefx.com] which in turn is created by the corresponding shelf tool [www.sidefx.com].
The rig for the lips seems to be a classic ‘zipper’ or ‘sticky lips’ setup, which you can google to find out more about, but there's a starting point here [vimeo.com] or here [www.kimonmatara.com]. The eyelids look like they contain very similar techniques, and have the really nice feature of being able to pose the gesture of the closed eyelid. Of course both of the resources I linked to there are aimed at rigging in maya, so there is some translation work to be done, but they should give you an idea of how the solution is structured.
There's a lot of ground to cover in a rig like this (facial rigging in particular tends to see riggers flexing every technique in their toolbox! ), so personally I would pick one of the above mentioned techniques and really get a handle on that before tackling the whole shebang. You will learn HUGE amounts from this. The ‘sticky lips’ setup for example will have you working through things like:
I don't know how much of this stuff you are already comfortable with, so I do apologise if I'm preaching to the choir
On the other hand, if you are starting out, try to break things down and make yourself comfortable with each part of the process. Check out videos demoing rigs you really like and try to find any resources that refer to the techniques used, you can learn shed-loads from seeing approaches in all different software packages, it is this that will help you ask the ‘right questions’ to yourself when sitting down to rig in H… it's a fair amount of detective work, but (I strongly believe) you will be a better rigger as a result!
Oops, that was long… not sure how useful it was, but I do hope that helps in some way.
Cheers,
Henry
Thanks for the link, that's a really nice looking rig Very comprehensive.
Did you check out some other pages discussing it? www.olivier-ladeuix.com [www.olivier-ladeuix.com]
There's some ongoing links from there to where Spiel Kind was running through their working process.
Lots of blendshape work here, apparently 27 shapes which were then split up and masked out to create 90 separate shapes. This then combined with ‘joints’ (bones) to control broader deformations.
The connecting of control objects to blendshapes is likely to be done with ‘set driven keys’ as they are called in maya, with the houdini equivalent being ‘blend poses’ which uses the blendpose chop [www.sidefx.com] which in turn is created by the corresponding shelf tool [www.sidefx.com].
The rig for the lips seems to be a classic ‘zipper’ or ‘sticky lips’ setup, which you can google to find out more about, but there's a starting point here [vimeo.com] or here [www.kimonmatara.com]. The eyelids look like they contain very similar techniques, and have the really nice feature of being able to pose the gesture of the closed eyelid. Of course both of the resources I linked to there are aimed at rigging in maya, so there is some translation work to be done, but they should give you an idea of how the solution is structured.
There's a lot of ground to cover in a rig like this (facial rigging in particular tends to see riggers flexing every technique in their toolbox! ), so personally I would pick one of the above mentioned techniques and really get a handle on that before tackling the whole shebang. You will learn HUGE amounts from this. The ‘sticky lips’ setup for example will have you working through things like:
- understanding point/parent constraints
- averaging point positions in SOPs between the upper and lower lips curves combined with:
- understanding ‘layered’ deformations, and the use of ‘drive’ geometry (the underlying curves)
i.e. ctrl obj -> drive geo -> capturing bones -> character mesh - and blending of attributes along the length of the curve (being able to make one part of the curve sticky whilst leaving the rest open), as driven by a parameter - you can pick your poison from chops or expressions here
I don't know how much of this stuff you are already comfortable with, so I do apologise if I'm preaching to the choir
On the other hand, if you are starting out, try to break things down and make yourself comfortable with each part of the process. Check out videos demoing rigs you really like and try to find any resources that refer to the techniques used, you can learn shed-loads from seeing approaches in all different software packages, it is this that will help you ask the ‘right questions’ to yourself when sitting down to rig in H… it's a fair amount of detective work, but (I strongly believe) you will be a better rigger as a result!
Oops, that was long… not sure how useful it was, but I do hope that helps in some way.
Cheers,
Henry
Houdini Lounge » To Character Rig... or Not
- friedasparagus
- 402 posts
- Offline
Ok, here's the updated version…
It includes the above-mentioned fix as well as another improvement which is that it now no longer requires the original rig to be in rest position. This is done by grabbing the weights from the selected deform SOP's input and then transferring the deformed point positions to the shadow_geo (necessary because it's very common for the deform SOP to be set to ‘Delete Capture Attributes’, the auto-rig is setup this way).
Performing the capture correct after this step sets the whatever the current pose is as the ‘capture pose’. So then all subsequent deformations to the shadow_geo will take place *from* this point. Meaning bones and deformed geometry will always match up.
This could be handy if you're working with an already animated asset, that you don't want to mess about duplicating or resetting channels on to retrieve the rest position (I am really, really lazy )
Nulls also have their display scale set to something hopefully more sensible.
It includes the above-mentioned fix as well as another improvement which is that it now no longer requires the original rig to be in rest position. This is done by grabbing the weights from the selected deform SOP's input and then transferring the deformed point positions to the shadow_geo (necessary because it's very common for the deform SOP to be set to ‘Delete Capture Attributes’, the auto-rig is setup this way).
Performing the capture correct after this step sets the whatever the current pose is as the ‘capture pose’. So then all subsequent deformations to the shadow_geo will take place *from* this point. Meaning bones and deformed geometry will always match up.
This could be handy if you're working with an already animated asset, that you don't want to mess about duplicating or resetting channels on to retrieve the rest position (I am really, really lazy )
Nulls also have their display scale set to something hopefully more sensible.
Houdini Lounge » To Character Rig... or Not
- friedasparagus
- 402 posts
- Offline
Hey eitch,
I'm really happy it's working for you
There is one hitch in the tool that I just clocked - the ‘Get World Trasform’ chop that I create for each shadow object is fetching the ‘pre-constraint transform’ of each node in the source rig. This is (I believe) how the constraints are designed to work. However, that means that if the source rig has nodes in the ‘skinning’ hierarchy that have chop based constraints applied to them, this will not be reflected in the shadow rig…
The fix is to replace the Get World Transform chop with a transform wrangle that calls optransform(source_rig_node_path) and set the matrix that way. The optransform method returns the objects world transform matrix after any constraints have been applied, that way it should works for rigs that use constraints too.
I'll post the updated tool when I've got that changed!
I'm really happy it's working for you
There is one hitch in the tool that I just clocked - the ‘Get World Trasform’ chop that I create for each shadow object is fetching the ‘pre-constraint transform’ of each node in the source rig. This is (I believe) how the constraints are designed to work. However, that means that if the source rig has nodes in the ‘skinning’ hierarchy that have chop based constraints applied to them, this will not be reflected in the shadow rig…
The fix is to replace the Get World Transform chop with a transform wrangle that calls optransform(source_rig_node_path) and set the matrix that way. The optransform method returns the objects world transform matrix after any constraints have been applied, that way it should works for rigs that use constraints too.
I'll post the updated tool when I've got that changed!
Houdini Lounge » To Character Rig... or Not
- friedasparagus
- 402 posts
- Offline
Hey!
Here's a little shelf tool script I knocked up thinking about the issue of FBX export and the ‘shadow rig’ idea.
I'm also slightly in the dark re rig requirements for games, but I'm working on it
There would be quite a few things left to do on the tool to make it truly worthy, but see if it's along the right lines. When running the tool you'll get prompted to choose an operator, the operator you're looking for is the final deform so in your rig. Select that and you should get a ‘shadow rig’ spat out in /obj. Which should export nicely to fbx (not including the fact that the fbx imports the nulls at a very large scale)
Cheers!
Henry
Here's a little shelf tool script I knocked up thinking about the issue of FBX export and the ‘shadow rig’ idea.
I'm also slightly in the dark re rig requirements for games, but I'm working on it
There would be quite a few things left to do on the tool to make it truly worthy, but see if it's along the right lines. When running the tool you'll get prompted to choose an operator, the operator you're looking for is the final deform so in your rig. Select that and you should get a ‘shadow rig’ spat out in /obj. Which should export nicely to fbx (not including the fact that the fbx imports the nulls at a very large scale)
Cheers!
Henry
Technical Discussion » best way to copy nodes to a new name with python?
- friedasparagus
- 402 posts
- Offline
Hi Dani,
You don't have to worry about nodes being overwritten, as the normal resolution of conflicting node names takes place (if “null1” already exists, it gets renamed to “null2”).
The copyItems() function returns the newly created nodes in a tuple so you can rename them after copying. Something like:
Hope that helps
You don't have to worry about nodes being overwritten, as the normal resolution of conflicting node names takes place (if “null1” already exists, it gets renamed to “null2”).
The copyItems() function returns the newly created nodes in a tuple so you can rename them after copying. Something like:
net1 = hou.node("/obj/net1") net2 = hou.node("/obj/net2") nodestocopy = (net1.node("A"),) newcopies = net2.copyItems(nodestocopy) newcopies[0].setName("newname")
Hope that helps
Technical Discussion » Goz Plugin not working in new version houdini?
- friedasparagus
- 402 posts
- Offline
Technical Discussion » Soft selection cluster
- friedasparagus
- 402 posts
- Offline
Hey guys,
This one is a little bit of a pickle… The soft transform SOP gets really close, and for broad stuff where no manual control of weights is required, it works fine. The hitch is with creating a handle for the animator to work with. Promoting the handle to the rig hda does not currently play very nicely (the pivot ain't where it should be!)… And of course we need the handle to follow any previous deformations applied to the mesh.
In order to work round this, the best I've managed to come up with for this kind of setup is
- creating a point constrained null that uses the same point and up vector as the soft transform SOP
- making sure the soft transform SOP is using ‘Local Transform’
- setting the correct axes on the point constraint (lookat -Z, up +Y)
- **make sure the point constraint is referencing the node upstream of the target soft transform to avoid double transforms**
- parent another null to the previous one; this is our handle
- now that we have a null in the same ‘space’ as the soft transform we can just channel reference the parms back to the soft transform SOP.
I've included my advanced torus rig as a quick demo Hope you find it useful. Oh, and if anyone out there has found a better way, please let me know!
Cheers,
Henry
This one is a little bit of a pickle… The soft transform SOP gets really close, and for broad stuff where no manual control of weights is required, it works fine. The hitch is with creating a handle for the animator to work with. Promoting the handle to the rig hda does not currently play very nicely (the pivot ain't where it should be!)… And of course we need the handle to follow any previous deformations applied to the mesh.
In order to work round this, the best I've managed to come up with for this kind of setup is
- creating a point constrained null that uses the same point and up vector as the soft transform SOP
- making sure the soft transform SOP is using ‘Local Transform’
- setting the correct axes on the point constraint (lookat -Z, up +Y)
- **make sure the point constraint is referencing the node upstream of the target soft transform to avoid double transforms**
- parent another null to the previous one; this is our handle
- now that we have a null in the same ‘space’ as the soft transform we can just channel reference the parms back to the soft transform SOP.
I've included my advanced torus rig as a quick demo Hope you find it useful. Oh, and if anyone out there has found a better way, please let me know!
Cheers,
Henry
Houdini Learning Materials » Tension Map learning
- friedasparagus
- 402 posts
- Offline
Technical Discussion » autorig arm rotation problem
- friedasparagus
- 402 posts
- Offline
Ah! Many apologies, I didn't understand the problem properly
Yes, this setup isn't serving your case very well at all, as bringing the arm to the side is robbing you of an axis to do the swing with. This is to do with the rotation order on the upper arm, changing this to RxRyRz for example gives you a much cleaner result.
So, it looks like this should be changed to RxRyRz by default, or possibly having an option to switch rotate order… I am struggling to think of when another order might be needed, but then you never can until you need one
I ended up adding a rotate order parm to the left arm of your character, you can find it under the ‘Left Arm’ -> ‘Controls’ tab. Try changing it to xyz instead of the default zyx, it should behave more like you want.
Cheers,
Henry
Yes, this setup isn't serving your case very well at all, as bringing the arm to the side is robbing you of an axis to do the swing with. This is to do with the rotation order on the upper arm, changing this to RxRyRz for example gives you a much cleaner result.
So, it looks like this should be changed to RxRyRz by default, or possibly having an option to switch rotate order… I am struggling to think of when another order might be needed, but then you never can until you need one
I ended up adding a rotate order parm to the left arm of your character, you can find it under the ‘Left Arm’ -> ‘Controls’ tab. Try changing it to xyz instead of the default zyx, it should behave more like you want.
Cheers,
Henry
Technical Discussion » Bendy Bones
- friedasparagus
- 402 posts
- Offline
Hi Duncan,
Have you tried checking out the “Bones from Curve” tool, with the ‘Kinematics’ dropdown set to ‘Follow Curve’? This should get you most of the way there. You can always set up different deformation control for the curve itself if you need to customize further,
Hope that's useful
Henry
Have you tried checking out the “Bones from Curve” tool, with the ‘Kinematics’ dropdown set to ‘Follow Curve’? This should get you most of the way there. You can always set up different deformation control for the curve itself if you need to customize further,
Hope that's useful
Henry
Technical Discussion » autorig arm rotation problem
- friedasparagus
- 402 posts
- Offline
Hi seifdune,
This is all normal behaviour, what's happening here is Houdini is performing some calculations behind the scenes to generate the proper rotate values… How this behaves is also dependent on rotation order, in the case of this control it looks like it will be RzRxRy (the same as the default rotation order for bones). If you want see a contrast to how the rotate handle normally works, try RMB clicking on the handle and select ‘Gimbal Mode’, this will preserve the orientation of the individual axes, but you can also see it makes certain kinds of manipulation tricky.
Long story short - don't panic! All is well.
This is all normal behaviour, what's happening here is Houdini is performing some calculations behind the scenes to generate the proper rotate values… How this behaves is also dependent on rotation order, in the case of this control it looks like it will be RzRxRy (the same as the default rotation order for bones). If you want see a contrast to how the rotate handle normally works, try RMB clicking on the handle and select ‘Gimbal Mode’, this will preserve the orientation of the individual axes, but you can also see it makes certain kinds of manipulation tricky.
Long story short - don't panic! All is well.
Technical Discussion » channels (CHOP) from table import?
- friedasparagus
- 402 posts
- Offline
Technical Discussion » channels (CHOP) from table import?
- friedasparagus
- 402 posts
- Offline
So for that we just need to check for equality between the current sample index and the relevant value in the original file.
Does this do it?
EDIT: blurp… didn't remove the sticky note.. please ignore
Does this do it?
EDIT: blurp… didn't remove the sticky note.. please ignore
Edited by friedasparagus - Oct. 19, 2017 14:44:24
Technical Discussion » channels (CHOP) from table import?
- friedasparagus
- 402 posts
- Offline
Oh sorry, I was assuming you were using a ‘File’ CHOP node to read the file. That's what I was thinking of when I wrote that… have a go at renaming your some_file.csv to some_file.chan and then read it with a File chop and see what it gives you. I haven't tried it with a proper csv file, but the .chan format seems pretty tolerant towards things it can't understand (string, commas etc).
It doesn't feel like you should need to be using SOPs as a middle-man for importing this kind of thing.
For the toggling, you can try the logic in the example I put up. Although the interpolation there is not necessary for your task
It doesn't feel like you should need to be using SOPs as a middle-man for importing this kind of thing.
For the toggling, you can try the logic in the example I put up. Although the interpolation there is not necessary for your task
Edited by friedasparagus - Oct. 19, 2017 13:35:48
-
- Quick Links