crestchristopher at gmail.com
Tue Feb 9 18:47:06 EST 2016
$YMAX or $YMIN is the min or max of the bounding box. Therefore since
this is expression is applied to box2 $YMAX + bbox("../box1", D_YMAX) it
reads the Max for the bounding box for box1 followed by adding the
parent node in this case the box_object for box1 followed by defining
the YMAX ?
Although why when I change the size on Y for box1 does box2 scale as
well, when I what I want is to change the size on Y for box1 but keep
box2 proportions the same ?
Alex Czetwertynski wrote:
> You should really look up Unix file navigation, as without an understanding
> of that, all of these expressions will be hard to understand, and mostly
> you won't be able to re-create them. All pre-GUI stuff, but still
> extremely important and useful.
> Let's say it this way.
> Opinputpath only works in relation to nodes that are plugged into another
> node. They specifically refer to a node that has a direct connection, a
> line, going from one node to another. Without this connection, Opinputpath
> is useless.
> Now imagine you have two nodes, side by side. They are not connected. One
> is a box, the other a sphere.
> Now say you want to grab a parameter from the sphere and apply it to the
> box. For example scale.
> So you would go into the scale parameters of your box and type something
> like ch("../sphere1/size...")
> You can do this because what you are telling Houdini is "Go from me to this
> other node (../) called sphere 1 and grab this parameter (scalex or y or z
> or radius or whatever).
> You don't have to memorize this stuff, just copy a parameter you are
> interested in and do a "paste relaitve references" to see how it is
> written. Once you see that a few times you will remember the syntax.
> On Mon, Feb 8, 2016 at 10:04 PM, Crest Christopher<
> crestchristopher at gmail.com> wrote:
>> The "."& ".." always mean the node above, not the hierarchy; if so, that
>> is one thing I was getting hung up on.
>> You mentioned that the expression needs the name of the node that has the
>> incoming connection into it; but you didn't apply the expression yet ? ;-)
>> If you applied the expression centroid, "." is the current node if there
>> was another node I assume that would be ".." ! ;-)
>> When you say plug; you mean the first node in the hierarchy, which you
>> skip the torus and go straight to the transform node ? If you had another
>> transform node that would be
>> centroid(opinputpath(".",1),D_X) ?
>> And so D_X stands for... ?
>> François Duchesneau wrote:
>>> opinputpath returns the path of a node. Let's say we have a torus at
>>> /obj/geo1/torus1. This torus is plugged into Transform Sop. You want to
>>> have the pivot of the transform to be the center of the torus. The
>>> expression "centroid" can you give that.
>>> Now the centroid expression requires the path to a node. To get the path
>>> of torus1 node procedurally you use the expression "opinputpath". This
>>> expression needs the name of the node that has the incoming connection into
>>> it. In this case the node is the one that has the expression written to it.
>>> The special "." means this node. ".." means the node above. Don't think the
>>> node above means the torus, we're talking about the hierarchy here, above
>>> is the parent /obj/geo1.
>>> So in the Pivot X channel you would write the following:
>>> centroid(opinputpath(".", 0), D_X)
>>> The first parameter of centroid is the current node. Then 0 is to tell
>>> we're querying the first plug. The second plug would be 1 and so on but you
>>> don't have two plugs on a Transform Sop anyway.
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
More information about the Sidefx-houdini-list