In version 22, Copernicus received a ton of improvements to the nodes — working with it has become genuinely enjoyable. Easy access to iterations inside a block is already there, and that’s a noticeable step forward compared to loops in SOPs. I’d love to see the same easy reading from a layer with short hscript commands. Honestly, when I write long trains of Python methods I feel like I’m aging in real time.
But here’s the problem with large numbers of elements. I wanted to quickly scatter sprites onto shapes according to given rules and thought — this is perfect for Copernicus and Houdini. But StampPoint accepts a maximum of 10 stamps. What if you need 30–50? I racked my brain going through solution variants and trying to manually iterate over points, and ran into a whole bunch of issues. In the end I decided to split into chunks for StampPoint, but I still had to duplicate the height separately, and it quickly turned into a very cumbersome setup that dropped to 2–3 fps and became completely unmanageable. It would help a lot if StampPoint outputted a sprite height map (alpha × depth) — then different sets could be stitched together into one whole without extra fuss. Although the main question is — why can’t StampPoint handle an arbitrary number of stamps?
The second part of the same problem is procedurally obtaining the stamps themselves. StampPoint needs a cable, but a block doesn’t accept a cable into a loop. And making 50 nodes is definitely not an option! The Sequence node also doesn’t work inside a block. Cutting sprites from a sheet via ID maps seems possible at first, but it turns out the ID numbers are unsuitable for iteration even after collapsing — you can’t even find out the number of pieces. You have to write code just to collapse the numbers, and that’s already economically impractical. Building a Contact Sheet is easy; taking it apart is only possible via caching to disk and reloading, because neither a cable nor a sequence can be created inside a loop, unfortunately.
As a result, COP has almost all the necessary tools: loops, ID maps, points, cables, attributes. But when you need to process a large number of elements, what’s missing are simple, “lightweight” iterations like a Foreach over all elements: took IDs → iterated over IDs; took points/attributes → iterated over them; took a cable → iterated over elements or gathered iterations into a cable or sequence.I think the copytopoints ideology needs to be developed further. Being able to easily iterate and operate on hundreds of elements on a 2D layer would be an ultra-feature that wins in competition, and almost everything for it is already in place. Please keep developing this direction — I’m fiercely rooting for you!

Yes, working with a thick cable of images gets old fast. The GPU is also not very happy with such a setup. Ideally you have a sprite sheet you stamp from; which we have the start of support for.

In attached the spriteuv attribute is used to extract one butterfuly from a contact sheet of butterflies. Unfortunately when building this I realized that the stamp point cop is currently treating it as br/lt rather than br/wh. So there is an extra wrangle to correct this, but we'll probably have to fix copy stamp to do the right layout so it matches the spec of spriteuv...

Thanks for the tip! What a slowpoke I am, ahaha. I completely forgot about spriteuv. In the end, the monstrous network turned into just a few nodes, and everything works in real time. This is amazing, exactly what I expected. Sending you a beam of gratitude.

In my joy, I made converters: ID to spritesheet, spritesheet to sequence, addspriteuv to pts, and everything became incredibly convenient. I am eternally grateful.

I hope users won't miss this moment.

P.S. I think it would be worth adding an "add spriteuv to points" section to configure stamps, with a choice of single or index attribute.

Please note this compatibility note for tomorrow's build:

THis means the viewer and stamp points should now match, but means you'll have to adjust your newly created nodes.

I do agree that spriteuv generation needs to be added to the configure stamps. It should allow the random selection of tilesheets, etc, as well.