I'm running a curve past a sphere that has a colour attribute on it.
Then using an attribute tranfer to transfer the colour to the points of the curve nearest to the sphere. I use a Group sop to group those points, then I birth particles from that point group.
Since the attribute transfer works by proximity the curve points change back to their original colour as they move beyond the sphere.

I'd like the points that have been changed to retain that colour once past the sphere. I can usually think of some clever, none scripted, solution, but my brain isn't kicking in yet.

Anyone with a suggestion?

chops.

Assuming your geometry starts out black ie Cd = <0,0,0>, you can bring in the Cd attribute into chops using the geometry chop, set it to ‘animated’ such that it will bring in your entire frame range.

Append a lag chop, an set the lag2 param to 10000 - such that the values will be allowed to rise from 0, but never drop back.

use a channel sop (also set to animated) to bring the newly-lagged attribute back to sop land.

I've often wished for a new class of ‘accumulator’ attributes for things of this sort, but it was pointed out that they don't quite fit the philosophy of being able to cook each frame distinctly in sops.

Gene

The SOP Solver is very good for tricks like this

Though, an accumulate SOP would be fantastic!

ForEach will also accumulate but with both ForEach and SOP Solver you're into simulations. Which makes sense, given what you're trying to do

Cheers

Peter B

…but with both ForEach and SOP Solver you're into simulations.

I totally hear what you are saying with regards to ‘simulation’, in the sense that values for frame N+1 depend on the result for cooking at frame N.

OTOH, it must be said that under certain circumstances (like the above mentioned Cd accumulation) these type of setups CAN be effectively described procedurally if we expand the definition of procedural as we know it today.

We add a ‘this network is procedural with respect to time’ context.

in it's present state, ‘procedural’ implies “jump to any given frame, and collect your results at the end of the sop chain”. This is great; however, if we instead allow a network to examine itself over a range of frames (still procedurally) we stand to gain a great deal, without incurring the traditional costs of a ‘simulation’.

There is no question – we need to cook the whole dataset to generate the data (whether it's done in dops, sops, or chops), i'm just suggesting that as a matter of convenience, we could probably do away with some of the context hopping.

in programming terms this is perfectly valid (assuming compute_new_value_for() is time dependant):
temp = foo;
frame_advance();
temp2 = compute_new_value_for(foo);
foo = max(temp,temp2);


…yet we cannot generate a sop network to describe this situation. it would be cool if we could.

Gene

Thanks guys, I'll likely do the chops thing since Gene is obviously not that busy today Besides logic statements frighten this old brain and I'm about to open a bottle of wine.

keyframe

…but with both ForEach and SOP Solver you're into simulations.

OTOH, it must be said that under certain circumstances (like the above mentioned Cd accumulation) these type of setups CAN be effectively described procedurally if we expand the definition of procedural as we know it today.

I think it's called POPs and DOPs. The code is a simulation. However, I agree, certain simpler things maybe should be manageable without going into neighboring contexts. Maybe a DOPs OTL that encapsulates what you're trying to do. Then it's just a matter of plopping down this OTL in SOP land.

I think it's called POPs and DOPs. The code is a simulation. However, I agree, certain simpler things maybe should be manageable without going into neighboring contexts. Maybe a DOPs OTL that encapsulates what you're trying to do. Then it's just a matter of plopping down this OTL in SOP land.

I was thinking more along the lines of what the trail sop is doing when set to “compute velocity”.

I don't know this for a fact, but I imagine that setting up the data structures required for even the most basic ‘simulations’ would have far more overhead then simply storing the value of the previous cook, and comparing them to the current values.

“Vroom Vroom”, you know?

Gene

keyframe

I think it's called POPs and DOPs. The code is a simulation. However, I agree, certain simpler things maybe should be manageable without going into neighboring contexts. Maybe a DOPs OTL that encapsulates what you're trying to do. Then it's just a matter of plopping down this OTL in SOP land.

I was thinking more along the lines of what the trail sop is doing when set to “compute velocity”.

I don't know this for a fact, but I imagine that setting up the data structures required for even the most basic ‘simulations’ would have far more overhead then simply storing the value of the previous cook, and comparing them to the current values.

“Vroom Vroom”, you know?

Gene

I don't know if they “fixed” the trail SOP, but last I checked, it didn't actually “store” the previous value: if you watch the performance monitor, it causes two (or more) cooks: it cooks at the current frame, and then cooks at the previous frame, and how ever many that you have your trail length set to.

– Antoine

if you watch the performance monitor, it causes two (or more) cooks: it cooks at the current frame, and then cooks at the previous frame, and how ever many that you have your trail length set to.

I don't have Houdini in front of me at the moment, but if that were true (and it may very well be), doesn't that point to the fact that the trail sop needs some lovin' rather then shuffling the data into another context with it's own overhead and issues?

It's obvious we don't see eye to eye on this issue – which is all good. Discussions much like this one are often ones I end up learning from the most. I'm certainly not attacking you personally – I hope it's not coming across that way.

Best,

Gene

keyframe

if you watch the performance monitor, it causes two (or more) cooks: it cooks at the current frame, and then cooks at the previous frame, and how ever many that you have your trail length set to.

I don't have Houdini in front of me at the moment, but if that were true (and it may very well be), doesn't that point to the fact that the trail sop needs some lovin' rather then shuffling the data into another context with it's own overhead and issues?

It's obvious we don't see eye to eye on this issue – which is all good. Discussions much like this one are often ones I end up learning from the most. I'm certainly not attacking you personally – I hope it's not coming across that way.

Best,

Gene

No, not at all. The trail SOP, iirc, did do actual caching back in the PRISMS days. My only concern is that the user is clear whether or not a particular SOP will return the exact same result regardless of prior frame computed. That's the beauty of SOPs and (a large part of) the Houdini paradigm. When you break that, you get into situations that are ambiguous – you get one result once, and then you do it again (but approach from a different set of computed frames) and get a different result. That gets frustrating real quick!

– Antoine

I can never turn down a how to do in CHOPs type question …

Here's a simple solution that seems to work