So you want to copy stamp? ​

Don't ​

Just don't. Ok?

But I wanna ​

No.

Why? ​

If you've used Houdini for a while, you get used to the idea of top-down data flow. You start with a sphere, you mountain sop it, you copytopoints a cube to the points.

Way back in time someone realised that it'd be useful to set different properties on those cubes when they get copied. Thus stamping was born. Old Houdini users just accept it, but if you've learned Houdini at any time after 1994, it feels weird.

For those lucky enough to have avoided it, of if you've just been pointed here by another grumpy fx person, think how stamping disrupts the top-to-bottom data flow:

• you start with a sphere
• you add attribs to control the box subdivisions
• you get to the copy sop
• it copies a box to the point
• oh wait, you have stamping
• it now goes backwards up the network chain to the cube, sets the parameters based on the stamped attributes
• now it copies the cube

Is there any visual indicator for this? No of course not, you have to carefully read the stamp parameter on the copy sop, track where the attributes were being created, then go to the box and understand the annoying stamp hscript command.

This sucks.

On a tech level this requirement of hscript can slow things down; hscript is single threaded and slow, any time you're advised to start peppering backticks and hscript into a complex setup, be alarmed.

Avoid the problem ​

Now for a lot of cases you don't need stamping; 9 times out of 10 with a copy sop you're just affecting basic scale, rotation, colour. In this case you can just use @pscale, @N, @up, @orient, @Cd to do what you need.

For other times where you have a variety of shapes you can use the piece/variant workflow, where if your points have string attribute, and the shapes your copying have a matching attribute per shape, the copy to points node will then copy the right shape to the right point.

But you want to be special, you really need your stamping workflow? Fine smartypants. For loops.

For loops ​

If stamping incurs an icky backwards data flow and hscript, and you start to think of houdini as visual coding, a coding paradigm that everyone is (mostly) happy with is for loops.

For each thing in a list, do stuff.

This may look very similar to the stamp walkthrough, but internally it makes houdini much happier, and scales better:

• you start with a sphere
• you add attribs to control the box subdivisions
• you get to a for loop. Inside the loop:
  • it looks at a single point
  • it read the attribute you want
  • it creates a cube with the divisions you asked for
  • a copy sop puts that cube onto the single point
  • the loop starts again with the next point
• the loop combines all the results of the loop together.

If you're careful with how you link parameters and attributes (using spare inputs which I explain on the main for loops page), then houdini can multithread the loop when you wrap it in a compile block, performance will scale much better.

But can't the stamp just use a for loop under the hood? ​

No, it's ways are old and cruddy, and it's been depreciated. Just use a for loop.