ice | clone point /add point | context ?

[Sam Cuttriss]

Im doing a bunch of water stuff,
Ive got a workable base wave, ive emitted a bunch of shoreline
splashes and ive cached the results, so far so good.

It would be cool to manage renderability of individual states in
partitions (is there an attribute for that?)

assuming i cant do that, i intend to clone particles that meet
specific conditions into new particle clouds.

big hurdle im striking in context.
the moment an added or cloned point is directed to a new particle
cloud my ability to send info to it "on creation"
i guess i could do a whole bunch of "set data" work to the original
cloud so the properties automatically exist in the clones cloud.

It would be nice to generate them as they are needed on the particle
that needs them.

are there any context whisperers who can shed some light on this?

_sam

[Grahame Fuller]

If you want to set data on the cloned points using the Clone Point node's On Creation port, you need to specify the cloned cloud's object name, i.e. Set Data "ClonedCloud.MyAttribute". "Self" still refers to the object with the tree, even for nodes plugged into that port.

gray

[Sam Cuttriss]

hmmm, thanks grahame,
it looks like i was using the default set particle velocity which has
"Self" inside it.
also im having way more luck using the "out name" port of the clone
node to send data to the new cloud.

It seems ambiguous context nodes can get locked into the wrong context
an refuse to connect to the rest of a tree.

now i need to figure out why only the first frame is cloning when the
same technique has worked for another cloud in the same scene.

_sam

[Raffaele Fragapane]

Normally when the first frame of an ICE tree is doing something, and then it stops working as intended, the first thing to look at is simulated vs timeless.
Simulated will store the state at the first frame as its initial state, and "freeze" anything below the simulation before it moves on with it.
If you have a non simulated ice tree in the same history that you expect to contribute to the simulation over time, you might need to look at that.

--
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

[Andy Nicholas]

Hi Sam,
One thing to watch out for is that sometimes ICE trees can jump around the construction stack without you moving them yourself. I had that happen quite frequently when I was doing a load of cloning points between point clouds on the last job I did. The problem usually occurs with the ICE tree entries that are shown in italics.

it seemed to be an issue when the scene was loaded, the order the ICE tree was created, determined the order on the stack. This obviously then caused evaluation problems if it wasn't how it was originally intended.

Just thought I'd mention it :)

Cheers,
Andy

[Sam Cuttriss]

ah, thanks guy,
it was a combination of that.

the spawning (wave) ice tree was automatically referenced into the
modeling stack of of the splash ice tree.

thats a curious quirk,
i guess that makes sense, the modeling mode effectively gives ice amnesia.

thanks again
_sam

[Raffaele Fragapane]

It's not really a quirk as much as it's a general limitation of time based, stateful simulations.
Accumulation, modulation and a number of other things that steer a simulation can't really work without knowing what the previous frame was doing it unequivocally, and the only way to do it is to "freeze" the initial state of the simulation, and then let it take control of the whole subsystem.

Things such as moving geometry, if absolutely needed, should come from outside (say a pointcache), and be fed into the simulation as contributing forces for things to be consistent to the system. They can't be evaluated within the context before the simulation once it's past the initial state.

[Vincent Fortin]

Sam,

Apart from your evaluation problem which is by design like Raf pointed out, I too sometimes feel a bit confused about the Clone Point node.

>It would be nice to generate them as they are needed on the particle that needs them.

+1. I think the Clone node won't let you set data even if the custom attribute already exists on the target cloud. Alternatively, like you said, you could create it on the source cloud but you'd have to randomize since singletons aren't passed to the new point as far as I remember.

I also had daisy-chaining-in-reference-input-ports failing on me for no apparent reason in which case I had to resort to an explicit target reference. Creating a brand new Clone node would work again but only for some time.

Like Andy said, italic trees tend to create havoc in the construction stack. Sometimes it's impossible to reorder, manually or by script. I found a workaround that once saved the night but left me with mixed feelings: delete the cloud and undo. Then the ops would magically go back to their original order. Or copy paste all nodes in a new tree. That was with 2010... haven't tried again since.

cheers

Vincent

[christian keller]

jumping around happens often if you have the clone node in the source cloud and you reorder the
the stack position in the target cloud. pretty annoying to check this everytime you load a scene, and
sometimes it get´s f§$d up completely. you are not able to move the node to the right place at all.
if you just merge complete clouds or do rough stuff, you could have your clone node in the target cloud ....

christian keller
visual effects|direction

+49 0179 69 36 248
chr...@gmx.de