Copy stamp a string value?

[hopbin9]

Hi,

Is it possible to use the Copy SOP to stamp a string value?

My template points for the Copy SOP have a string attribute for each point, and I want a Font SOP in the copy to be stamped with each string attribute. My problem is the stamp value appears to be numeric only.

[eetu]

exhelp stamps() ?

[hopbin9]

Thanks, that seems to indicate that it's possible.

How do I assign a string value to a stamp input? When I enter "Hello" it always tries to convert it to a numeric value or gives me an error that it's not a value expression. When I look at val1 in the parameter editor, it's a float parameter.

[hopbin9]

ok, i got it working.

Had to create a stamp value of $PT for the point number, and then I could use that to read the string attribute for the reference points going into the Copy SOP.

`points("../ref",stamp("../copy1","point",0),"str")`

Not a very obvious way of doing, but I don't think you can stamp a string value. You can only use a numeric value as a string using stamps.

[gaurav]

Copy sop never fails to amaze me.

Has it been the part of H since the big bang ?

also could someone explain in simple programming terms how copy stamping is achieved ?

eg. for loop,recursion ?

Thanks,

[asnowcappedromance]

actually you can do it with the ftoa() expression, I atttached an example!

cheers,

Manu

stamping_with_strings.hipnc

[rdg]

exhelp stamps() ?

Tricks me all the time, but this one only works in DOPS.

Examples of string stamping operators include the Apply Relationship

DOP, and the Copy Data DOP.

Sadly this is the only hint in the documentation that it won't work in SOPs.

@asnowcappedromance

I think they're talking about stamping a 'real' string - like a filename.

In your example a stamp of $PT works just as fine.

[hopbin9]

actually you can do it with the ftoa() expression, I atttached an example!

cheers,

Manu

I see what you're doing, but I need to stamp a string value (like a phrase or description).

The attached is how I ended up doing it. Using $PT on the Copy SOP so I could look up the attribute from the point templates.

stamping-strings.hipnc

[hopbin9]

also could someone explain in simple programming terms how copy stamping is achieved ?

We connect nodes in Houdini from the top down, but nodes are cooked from the bottom up. So in programming terms, when the Copy SOP is cooked. It then cooks it's inputs X number of times. Each time it does that it changes the value stored in the stamp variables. Allowing each input node to be changed with each copy.

[Macha]

Great, I didn't know the bottom up cooking. Does it not have to cook once the whole way down, or how does it know what data is at the bottom? Is it some kind of recursion thing?

[hopbin9]

Great, I didn't know the bottom up cooking. Does it not have to cook once the whole way down, or how does it know what data is at the bottom? Is it some kind of recursion thing?

Houdini ALWAYS cooks from the bottom up. Except for VOP networks they execute more like source code, but you could think of it as LEFT to RIGHT cooking order.

When you mark as SOP node blue, then that becomes the first node cooked at render time. How it works is kind of like this.

First node cooked is the blue marked node, but when it cooks it can't finish cooking. So it asks the node connected to it's input to cook. That node will cook (if it can) and return the result. Often nodes are cooked up the tree until they hit one marked RED or one with no inputs. If you know computer programming, then this type of cooking is called recursive function calls.

I should put together an AF explanation of how this works, because it would really help people to understand concepts like Copy SOP, attributes and the cook order of things. The big problem here, is that we are taught to create Houdini nodes in the reverse order that they will be cooked. So it's very confusing to understand for a beginner.

[eetu]

When you mark as SOP node blue, then that becomes the first node cooked at render time. How it works is kind of like this.

Then again, it is also the last node to cook, in a way, right?

[hopbin9]

Then again, it is also the last node to cook, in a way, right?

It is the first node that is "called" and the last node to "return". If you view every node as a function in a computer program. The node marked blue would be called "main". It has to be executed first, but it's the last to finish.

[eetu]

Houdini ALWAYS cooks from the bottom up. Except for VOP networks they execute more like source code, but you could think of it as LEFT to RIGHT cooking order.

When you mark as SOP node blue, then that becomes the first node cooked at render time. How it works is kind of like this.

First node cooked is the blue marked node, but when it cooks it can't finish cooking. So it asks the node connected to it's input to cook. That node will cook (if it can) and return the result. Often nodes are cooked up the tree until they hit one marked RED or one with no inputs. If you know computer programming, then this type of cooking is called recursive function calls.

This is indeed a very clear and concise explanation, maybe the help should have some sort of a "how things actually work" section. One for DOPs would be great, too, as the whole node tree concept is different in simland..

[hopbin9]

This is indeed a very clear and concise explanation, maybe the help should have some sort of a "how things actually work" section. One for DOPs would be great, too, as the whole node tree concept is different in simland..

I'm not sure how the DOP networks cook when solving a simulation. The manual does say that it's a "two pass" process, but doesn't clarify what that means. I assume it's referring to the fact that before solvers can cook they must cook SOP input nodes.

Still, the order of nodes cooking in the DOP network is the same. Attributes and Groups work the same in the DOP network, as far as cooking order, because they are connected above the nodes that reference their data and the result of the network is defined by marking the first node with a BLUE tag.

What I've found strange with DOP networks, are things like Gravity nodes which seem to work above or below a solver. That behavior of a node doesn't appear to be a bottom up cooking process. Now if we perform "two passes" in a bottom up approach, then the Gravity nodes can work. Depending on where Gravity data is stored.

The other strange thing, is that DOP networks are not a root level network. For example, Houdini has /obj /shop /pop root level networks. You can't use SOP nodes inside /pop unless you create a SOP manager. Why didn't SideFX create a /dop root level network for DOP networks? It's strange cause DOP networks cook differently and have no display flag. Only a BLUE render flag. So they are kind of a hybrid SOP network, but it depends on SOP data.

Edited February 20, 2012 by hopbin9

[eetu]

I'm not sure how the DOP networks cook when solving a simulation. The manual does say that it's a "two pass" process, but doesn't clarify what that means. I assume it's referring to the fact that before solvers can cook they must cook SOP input nodes.

Still, the order of nodes cooking in the DOP network is the same. Attributes and Groups work the same in the DOP network, as far as cooking order, because they are connected above the nodes that reference their data and the result of the network is defined by marking the first node with a BLUE tag.

What I've found strange with DOP networks, are things like Gravity nodes which seem to work above or below a solver. That behavior of a node doesn't appear to be a bottom up cooking process. Now if we perform "two passes" in a bottom up approach, then the Gravity nodes can work. Depending on where Gravity data is stored.

The nodes in DOPs do not specify a sequential process, they just hierarchically collect the data needed by the solvers. In essence the DOP nodes collect what you see in the Details view - what forces and operations and solvers should affect which objects.

I guess the second pass would then be the actual running of the operations and solvers with that collected data.

(At least that's how I think it goes..)

[graham]

How DOPs works: http://www.sidefx.com/docs/hdk11.1/hdk_dataflow_dop.html

[hopbin9]

Thanks guys, and thanks Graham, I'm going to read that over now.

Found this in the manual ->

Houdini cooks dynamics simulations in a two step process:

1. Process the network to establish objects and data attachments.
2. Run solvers on the processed data tree.

[hopbin9]

While it might sounds like I know what I'm talking about. Clearly there is still much for me to learn about how Houdini cooks things. Thanks for that link. Very informative.

[edward]

Great, I didn't know the bottom up cooking. Does it not have to cook once the whole way down, or how does it know what data is at the bottom? Is it some kind of recursion thing?

Some info in this mailing list post as well:

http://www.sidefx.co...=20&revdate=off

PS. I've been thinking that I should do an advanced presentation on cooking and dependencies in general after H12 releases. However, I'm not sure that anyone would care for it as I imagine it only being useful for (advanced) HDK users. However, I guess non-HDK users who want to really understand how the internals work would find it useful (at the cost of yawning through it all).