Copy Stamping using the new ForEach workflow

[JH12]

I'm following recommendations to avoid use of the copy stamp SOP.  I have a trail effect which I've created with a solver sop which I want to copy to points on a grid, using a forEach and a CopytoPoints.  But I want to vary the randomise seed of each of my trails so they appear different.  How can I pass on an attribute with a unique value per point which will "stamp" the trail, allowing me to apply a unique seed to each copy?  Thanks for the advice.  

  

polyextrude_solver_foreach.hiplc

[davpe]

hi, this video explains how to use instancing with for-loops

https://vimeo.com/251729016

Edited August 12, 2018 by davpe

[JH12]

Thanks David, nice video. I am familiar with those techniques for stamping static objects. Where it is not working for me is that I'm trying to copy solvers, and use the same technique to vary a seed which randomises the pattern of each trail.  However for some reason, it doesnt work, all the trails still appear the same (see project file).  Do you know why this may be?

Also, I noticed in your vimeo comments you replied that you weren't sure whether for each loops are more efficient than stamping. I believe that whilst there may not be much gain just comparing to for each loops, the benefit comes from being able to use for each loops inside compile blocks, which are significantly faster.  Jeff Wagner talks about it here at around the 45min mark: 

 

[toadstorm]

I don't think you can copy the results of a solver and expect to vary the simulation seed post-copy. It might be possible with stamping, but I don't recommend it.

Instead consider either caching out multiple seeds of your solver and then copying the cached sequences to your points, or have your solver run post-copy on everything at once.

[Andr1]

We're getting closer, but something is wrong..

If you stop at any frame, you can notice that every new extruded cube is being randomly scaled  based on the iteration, but next frame it immediately loses the randomness.

Dunno whats wrong

polyextrude_solver_foreach_MHHH.hiplc

[JH12]

3 hours ago, Andr1 said:

We're getting closer, but something is wrong..

If you stop at any frame, you can notice that every new extruded cube is being randomly scaled  based on the iteration, but next frame it immediately loses the randomness.

Dunno whats wrong

polyextrude_solver_foreach_MHHH.hiplc

Thanks Andr1.  This is a little different to what I was proposing which was to change the actual branching of each pattern, but is interesting nonetheless.  I've been trying to decipher your hip, can you elaborate a little on what you are doing by isolating the back face and applying the pivot?  I'm a bit lost getting that part.  Thanks for providing that example.

 

On 13/08/2018 at 4:31 AM, toadstorm said:

I don't think you can copy the results of a solver and expect to vary the simulation seed post-copy. 

Thanks Toadstorm.  I'm surprised by this, I would have thought it would be a common technique..  I suppose it is not a very efficient way of doing things. 

[anim]

8 hours ago, Fireandsmoke said:

Thanks Toadstorm.  I'm surprised by this, I would have thought it would be a common technique..  I suppose it is not a very efficient way of doing things. 

not saying it'd be technically impossible to make system like this as I don't know

but I can't imagine how clever the devs would have to be to be able to decipher the feedback dependencies of individual solvers considering that every iteration you can have completely different amount of points fed in, different branches active within the for loop, etc.  

so even if all simdata was cached for all "virtual" solvers on each frame there is simply no telling which solvers in next frame of for loop should get which data, unless there was some tagging system which would help define those dependencies, but certainly not automatically

so in my opinion, I wouldn't consider it a common technique, however I get that it may seem trivial at the first glance, maybe with the assumption of constant number of copies and memory to spare for all simdata solvers need for next frame

what's common however is pre-caching data or instead of solver use Feedback For Loop, which since not cached will compute all iterations from scratch every frame, but will at least work within loop so for lightweight experiments why not 

In production you would probably use wedging to produce all your simulated copies

Edited August 14, 2018 by anim