1.stamps(“../OUT”, “DATAPATH”, “../.:grid/Geometry”)
-../.:

2./obj/sim_impacts:copyGroup*/Geometry
-:copyGroup*/Geometry

3.op:`opinputpath('.',1)`
-op:

kipe
1.stamps(“../OUT”, “DATAPATH”, “../.:grid/Geometry”)
-../.:

2./obj/sim_impacts:copyGroup*/Geometry
-:copyGroup*/Geometry

3.op:`opinputpath('.',1)`
-op:

1) That means previous path
3) op means operator
2) I can't remember fully what that means.
You can also check the documentation help that comes with Houdini

DJ

kipe
1.stamps(“../OUT”, “DATAPATH”, “../.:grid/Geometry”)
-../.:

The stamps() expression fetches string variables (text) from particular nodes such as the Copy SOP, L-Systems SOP and certain DOPs. In this case it is most definitely on an Object Merge SOP inside a SOP Solver in the DOPs context. “DATAPATH” is a variable set by the SOP Solver DOP and passes in the previous timesteps “Geometry” data to you. This is all explained on the help card for the SOP Solver DOP.

Houdini uses the unix shell workflow when referencing other folders, objects and parameters in the scene.

../ means go up one directory. When in a parameter, this will jump out of the node and reference the nodes in the current network.
../. means go up one directory and go back to me or “here”.
: is a delimeter which requires a path reference on the left and then a data reference on the right. You can find all the data references or paths in the details view on the DOP network.
../.:grid/Geometry will then read >>> “Go up one directory out of this parm and in the nodes then reference my parent node (../.). Then index in to the data ( for the grid object's Geometry data (grid/Geometry)

Other unix shell constructs that you need to know:

. means ”here“ so in a channel reference to a local parameter could be written many ways. Let's say you want to reference the ty parameter in to the tx parameter of an object called ”geo1“. How many ways to write that…:
ch(”ty“)
ch(”./ty“)
ch(”../geo1/ty“)
ch(opfullpath(”.“)+”/ty“) where opfullpath() is an hscript command that prints out the full path to a particular node and in this case it is being passed in ”.“ or here or ”me“ or geo1 more specifically.

The nice thing about learning unix paths is that you can at some point in time supercharge your workflow by integrating shells in to your workflow and take complete command of your environment. To me native Windows OS is like working on files with a ”condom“ on. Just not as much fun even though ”they" tell you that it is just the same either way.

kipe
2./obj/sim_impacts:copyGroup*/Geometry
-:copyGroup*/Geometry

* = Wildcards. Yet another shell workflow inherited by Houdini.
When you put in a * wildcard it means to substitute any characters of any string length “here”. So:
copyGroup* means fetch all objects that begin with copyGroup. Let's say you fractured an object and all the pieces begin with copyGroup and there are two thousand from copyGroup001, copyGroup002 … copyGroup599 copyGroup600. With the string copyGroup* you can easily fetch all the objects that begin with copyGroup.
An offshot of this is say you only wanted to pick up the objects that end in 0. You could then do copyGroup*0 where the match pattern would read “select all the objects that begin with copyGroup and end in 0.

Now more specifically, copyGroup*/Geometry now reads ” given a path, index in to the data of the following objects ( : ), for all DOP objects that begin with the string “copyGroup” ( copyGroup* ), return all data called “Geometry”.

You may also find the “?” wild card but not as often. It means substitute any string character for just this single string. Let's say someone screwed up the naming of some lights. You have lights lgtKey001 to lgtKey050 but somewhere along the line someone created a few lights called lgtFey… but still need to grab them all. You can type:

lgt?ey0*

which reads “find all the objects that begin with lgt then substitute any character for the next single character, followed by ”ey0“ and finally find any following characters.”

kipe
3.op:`opinputpath( ‘.’, 1 )`
-op:

Ahhh the op: syntax. OK. So many parameters on nodes reference data from disk. Fine. So you want to fetch some geometry on a File SOP off of disk. You use “cmy_project/geo/my_geometry.bgeo”. Great. Now you read the file off of disk called my_geometry.bgeo.
But of course Houdini is uber cool and allows you to reference data internal to itself. This could be geometry for SOPs, images for cops, etc.
So now you want to fetch some geometry from another object inside the current scene. To tell Houdini you want to fetch geometry inside of itself rather than from disk, you precede your path with “op:” where “op” means “ok lets look for an internal operator inside the current scene file” and “:” again is that delimeter which tells Houdini's string parser (the mechanism that has to descipher the string being evaluated) that a path is a comin'. So in any parameter referencing geometry from a path off disk:

opobj/geo1/my_geometry_sop

which reads “let's fetch some geoemtry from inside the current scene file (op and the path to that operator is ”/obj/geo1/my_geometry_sop“.

But when using op: to fetch internal data you have to be aware of the one single limitation: op: currently requires a FULL PATH to the operator and not a relative path. Remember the ../ to go up one directory to reference stuff? Well that's a relative path so you can't use ../ directly.

Now what if you have to fetch a path relatively as you want to make this as procedural as possible? In comes the hscript command opinputpath() which returns a full path to a node wired in to a specific input to another node.
One more thing. The backticks or `ch(/obj/geo1/tx)` in string fields. Well string parameters in Houdini don't evaluate like float or integer fields. If you put an expression that needs to evaluate per frame, you gotta put that inside backticks to tell the string parser evaluating the parameter that it needs to evaluate something. Otherwise it will just read the text and pass it on.

Finally we can now read this last string epxression:

op:`opinputpath('.',1)`

as ”in this string field, look for an internal operator (op as the expansion of the full path to this nodes first input `(opinputpath('.',1)` and get me that data!

Ok. But what about single quotes and double quotes? The expression above uses single quotes to encase strings inside the expression. This is common in hscript. Single quotes can be substituted for double quotes in matching pares in almost all cases. The only hitch up is if you have global variables. ‘$JOB’ would NOT expand the variable and pass in $JOB to wherever while “$JOB” would expand the variable to whatever it is set to.

Hope that helps sort things out a bit.

Again Houdini borrows heavily from shell workflows which is a valid and powerful way to create interesting and dynamic data relationships inside of Houdini and must be mastered in order to progress in to more complicated scenarios.

wow, this is much better than expected. thanks jeff and dj_boxer!

jeff

kipe
1.stamps(“../OUT”, “DATAPATH”, “../.:grid/Geometry”)
-../.:

The stamps() expression fetches string variables (text) from particular nodes such as the Copy SOP, L-Systems SOP and certain DOPs. In this case it is most definitely on an Object Merge SOP inside a SOP Solver in the DOPs context. “DATAPATH” is a variable set by the SOP Solver DOP and passes in the previous timesteps “Geometry” data to you. This is all explained on the help card for the SOP Solver DOP.

Houdini uses the unix shell workflow when referencing other folders, objects and parameters in the scene.

../ means go up one directory. When in a parameter, this will jump out of the node and reference the nodes in the current network.
../. means go up one directory and go back to me or “here”.
: is a delimeter which requires a path reference on the left and then a data reference on the right. You can find all the data references or paths in the details view on the DOP network.
../.:grid/Geometry will then read >>> “Go up one directory out of this parm and in the nodes then reference my parent node (../.). Then index in to the data ( for the grid object's Geometry data (grid/Geometry)

Other unix shell constructs that you need to know:

. means ”here“ so in a channel reference to a local parameter could be written many ways. Let's say you want to reference the ty parameter in to the tx parameter of an object called ”geo1“. How many ways to write that…:
ch(”ty“)
ch(”./ty“)
ch(”../geo1/ty“)
ch(opfullpath(”.“)+”/ty“) where opfullpath() is an hscript command that prints out the full path to a particular node and in this case it is being passed in ”.“ or here or ”me“ or geo1 more specifically.

The nice thing about learning unix paths is that you can at some point in time supercharge your workflow by integrating shells in to your workflow and take complete command of your environment. To me native Windows OS is like working on files with a ”condom“ on. Just not as much fun even though ”they" tell you that it is just the same either way.

kipe
2./obj/sim_impacts:copyGroup*/Geometry
-:copyGroup*/Geometry

* = Wildcards. Yet another shell workflow inherited by Houdini.
When you put in a * wildcard it means to substitute any characters of any string length “here”. So:
copyGroup* means fetch all objects that begin with copyGroup. Let's say you fractured an object and all the pieces begin with copyGroup and there are two thousand from copyGroup001, copyGroup002 … copyGroup599 copyGroup600. With the string copyGroup* you can easily fetch all the objects that begin with copyGroup.
An offshot of this is say you only wanted to pick up the objects that end in 0. You could then do copyGroup*0 where the match pattern would read “select all the objects that begin with copyGroup and end in 0.

Now more specifically, copyGroup*/Geometry now reads ” given a path, index in to the data of the following objects ( : ), for all DOP objects that begin with the string “copyGroup” ( copyGroup* ), return all data called “Geometry”.

You may also find the “?” wild card but not as often. It means substitute any string character for just this single string. Let's say someone screwed up the naming of some lights. You have lights lgtKey001 to lgtKey050 but somewhere along the line someone created a few lights called lgtFey… but still need to grab them all. You can type:

lgt?ey0*

which reads “find all the objects that begin with lgt then substitute any character for the next single character, followed by ”ey0“ and finally find any following characters.”

kipe
3.op:`opinputpath( ‘.’, 1 )`
-op:

Ahhh the op: syntax. OK. So many parameters on nodes reference data from disk. Fine. So you want to fetch some geometry on a File SOP off of disk. You use “cmy_project/geo/my_geometry.bgeo”. Great. Now you read the file off of disk called my_geometry.bgeo.
But of course Houdini is uber cool and allows you to reference data internal to itself. This could be geometry for SOPs, images for cops, etc.
So now you want to fetch some geometry from another object inside the current scene. To tell Houdini you want to fetch geometry inside of itself rather than from disk, you precede your path with “op:” where “op” means “ok lets look for an internal operator inside the current scene file” and “:” again is that delimeter which tells Houdini's string parser (the mechanism that has to descipher the string being evaluated) that a path is a comin'. So in any parameter referencing geometry from a path off disk:

opobj/geo1/my_geometry_sop

which reads “let's fetch some geoemtry from inside the current scene file (op and the path to that operator is ”/obj/geo1/my_geometry_sop“.

But when using op: to fetch internal data you have to be aware of the one single limitation: op: currently requires a FULL PATH to the operator and not a relative path. Remember the ../ to go up one directory to reference stuff? Well that's a relative path so you can't use ../ directly.

Now what if you have to fetch a path relatively as you want to make this as procedural as possible? In comes the hscript command opinputpath() which returns a full path to a node wired in to a specific input to another node.
One more thing. The backticks or `ch(/obj/geo1/tx)` in string fields. Well string parameters in Houdini don't evaluate like float or integer fields. If you put an expression that needs to evaluate per frame, you gotta put that inside backticks to tell the string parser evaluating the parameter that it needs to evaluate something. Otherwise it will just read the text and pass it on.

Finally we can now read this last string epxression:

op:`opinputpath('.',1)`

as ”in this string field, look for an internal operator (op as the expansion of the full path to this nodes first input `(opinputpath('.',1)` and get me that data!

Ok. But what about single quotes and double quotes? The expression above uses single quotes to encase strings inside the expression. This is common in hscript. Single quotes can be substituted for double quotes in matching pares in almost all cases. The only hitch up is if you have global variables. ‘$JOB’ would NOT expand the variable and pass in $JOB to wherever while “$JOB” would expand the variable to whatever it is set to.

Hope that helps sort things out a bit.

Again Houdini borrows heavily from shell workflows which is a valid and powerful way to create interesting and dynamic data relationships inside of Houdini and must be mastered in order to progress in to more complicated scenarios.