... yeah of course
parentbindis "the bind of parent". Could someone guide me more on how to use this node?
Full Version: How to use Parent Blend VOP?
I'm trying to figure out how to use KindFX's Parent Blend VOP [www.sidefx.com]. However, the document isn't very helpful here:
... yeah of course
... yeah of course
to see the usage you can look inside of Parent Constraint VOP
also it's docs [www.sidefx.com] describe "parentbind" better: "The bind pose of the current parent."
and also the Update Offset and Clear offset help describes what's going on under the hood, so essentially parentbind and newparentbind are the transforms at which the constrained object is "bound" to them
also it's docs [www.sidefx.com] describe "parentbind" better: "The bind pose of the current parent."
and also the Update Offset and Clear offset help describes what's going on under the hood, so essentially parentbind and newparentbind are the transforms at which the constrained object is "bound" to them
tamte
to see the usage you can look inside of Parent Constraint VOP
also it's docs [www.sidefx.com] describe "parentbind" better: "The bind pose of the current parent."
and also the Update Offset and Clear offset help describes what's going on under the hood, so essentially parentbind and newparentbind are the transforms at which the constrained object is "bound" to them
Thank you!
I just realized that I can actual show the code a VOP generates. Parent Blend VOP:
matrix offset = Value1 * invert(Value3); outparent = offset * Value2; outparent = blendtransforms(Value, outparent, 1, 2);
I'm still not sure what the use case of this is tho... it blends
parentwith parentbind * invert(newparentbind) * newparent...?Edit: I kinda get it now. I think in 99% of the cases one should just use Parent Constraint SOP. Parent Blend SOP is more like an internal utility node. It's still a bit weird to me that how the algorithm works tho... cause the "blend" happens twice (one on parent, the other on the final result).
kodrayes, it may be confusing as Parent Blend is literally computing just the parent portion of the constraint which may be hard to visualize
I kinda get it now. I think in 99% of the cases one should just use Parent Constraint SOP. Parent Blend SOP is more like an internal utility node
kodrathe final result blend is just to filter the components which will be affected
It's still a bit weird to me that how the algorithm works tho... cause the "blend" happens twice (one on parent, the other on the final result).
however overall, this is not the ideal system for dynamic parenting since:
- it requires you to set offsets every time you change the spatial relationships just to avoid jumps and misalignments during blending especially for seamless handover
This is especially frustrating when you need to just shift the frame at which the parenting happens, which is something that will not happen automatically with animation keyframes being shifted around
- it's very ugly to have stashed transforms inside of VOP network and also forced editable nodes
tamte
- it's very ugly to have stashed transforms inside of VOP network and also forced editable nodes
I guess this is one of the cases only a system like APEX can solve. (Blender's equivalent has the exact same problem: it needs you to press a specific button manually every time your skeleton changes even slightly.)
APEX has the corresponding node (rig::parentblend). It works the same way: the transforms have to be stashed. But in APEX workflow, the whole network is procedurally generated, unlike VOP. So transforms are stashed all the time and it's less an issue.
kodraThat's not a solution either in my mindtamte
- it's very ugly to have stashed transforms inside of VOP network and also forced editable nodes
I guess this is one of the cases only a system like APEX can solve. (Blender's equivalent has the exact same problem: it needs you to press a specific button manually every time your skeleton changes even slightly.)
APEX has the corresponding node (rig::parentblend). It works the same way: the transforms have to be stashed. But in APEX workflow, the whole network is procedurally generated, unlike VOP. So transforms are stashed all the time and it's less an issue.
As then the state is responsible for updating the offsets, which will automatically break if the channels provided for the rig are not generated within that state but provided to the rig from library or using potential future tools like NLE clip mixing or any form of channel editing
Proper solution is one that handles seamless dynamic parent switching as a part of rig logic without the need to bake in offsets to that rig tree or provide them as additional channels, the offsets should be automatically computed at the frame the parent is switched, this requires history dependent constraints or whatever you want to call them
The only constraint in Houdini that works this way and makes dynamic parenting a breeze is the very old Blend Sop in Constraint mode, so hopefully APEX will gain such functionality that allows us to build constraints like that, instead of just traditional basic constraints that are usually not enough to solve common rigging issues