Jeff Lait

Yeah, detail attributes with a detail() expression is probably the easiest approach for now.

Largely, the answer here is no. If a parameter depends on pixel values and is set by an expression it means we can't keep the computation on the gpu, so have to bounce back to the cpu. Historically this results in networks that are impossible to then make gpu friendly, so we consciously did not make it easy to do this.

We're not happy with the current state as we want to drive these things ourselves, so are looking for ways to enable it properly in the future

But what can you do today?

pic expression is the old cops only, but I see our docs didn't say that. I've added a note to that effect.

volumesample must point to a sop, not a cop.

So the current complicated work around is to use a sop net in cops. Dive into that and put down a copnet sop and set it to fetch an external cop. Point to the cop you want to read. This gives you a volume. Now back at the original cop level you can write a volumesample expression that points to the copnet node inside the sopnet.

Note that this will be a break point in graph evaluation, we'll not be able to compile through this, so it won't work in blocks, and there may be performance issues as it bounces through the CPU. But if there is a will, there is a way...

No; there is no easy way.

The hard way is to make something like a Constant Layer that you Add One to each iteration; and add to your set of feedback wires. But that is just a painful workaround for something that should be just an @cop_iteration expression in a parameter!

Yes; we are planning on adding such a thing. But I'd rather not promise anything that isn't shipped.