Little ICE workflow question

[Rob Wuijster]

Hi all,

I'm making baby steps into ICE again, and just wanted some insights on this.

I've created a little ICE tree that will emit particles, slow them down
after a while, next add gravity and finally let them die off.
If somebody could find some time to take a look at the attached image,
to see if this is all set up the way it should be, or if there can be
any improvements in the tree.

The Execute node is there for compound creation, if anyone wonders... ;-)

cheers,

rob

\/-------------\/----------------\/

[Chris Marshall]

Well first up, you can reuse the same Test Particle reached Age Limit node, rather than having 5 of them.

Other than that, I don't tend to use the state machine, so would approach it slightly differently, though I'm sure your approach is fine.

If it works, it's ok!

Chris

[Schoenberger]

Another thing about the age limit:
Instead of applying the age limit every frame in the first state,
apply it at emission.

Then I would do it differently, of course it depends on the effect you
want to have. As
my solution would have a slightly different result.

Just apply the age limit it once at emission and not at every state.
Then do not test 'particle reached age limit' for switching states,
test 'particle Age%' > 0.25
test 'particle Age%' > 0.5
test 'particle Age%' > 0.75

regards,
Holger Schoenberger
technical director
The day has 24 hours, if that does not suffice, I will take the night

Holger Schoenberger
technical director
The day has 24 hours, if that does not suffice, I will take the night

Quoting Chris Marshall <chris.m...@eclipsecreative.co.uk>:

> Well first up, you can reuse the same Test Particle reached Age Limit node,

> rather than having 5 of them.Other than that, I don't tend to use the state

[Chris Marshall]

I've dug myself a hole now, haven't I!

Well when I started playing with ICE and trying to use the state machine, it didn't perform as I thought it would. Not sure why not, though it was probably something I was doing at the time was probably skewed somehow. ie my logic!

What I tend to do now, which if you look inside a state node is the first thing that happens, is basically just use a GetParticleStateID node and run it through an if equals setup. So basically if the state ID is 1, do this, if it's state 2 do that etc etc.

This is pretty much what the state machine setup appears to do, but without the baggage. I've found that digging around inside some of these compounds reveals some useful stuff that can be extracted or modified and re-used.

For example, if you search for Spawn, you don't get a simple SpawnParticles node listed, but if you look inside say, the SpawnonTrigger compound, you can grab the SpawnParticles compound for use it elsewhere. Of course, if you open up this compound, you can see how that works, basically using the ClonePoint node. So you could have used the SpawnonTrigger compound, or if you feel happy doing it, just use the ClonePoint node and setup the values you want manually.

Digging around inside existing compounds is a useful thing to do.

On Wed, Jul 22, 2009 at 12:17 PM, Rob Wuijster <ro...@casema.nl> wrote:

Hi Chris,

Thanks for that. Yes, reusing nodes makes sense ;-)

Just for the sake of the asking, how would you address this particle behavior without a state machine setup? I was under the impression state machines were the way to go with things like this.

The whole ICEtree works as I want it to, but learning about another approach is very interesting as well.

cheers,

rob

\/-------------\/----------------\/

Chris Marshall wrote:

------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.21/2252 - Release Date: 07/21/09 05:58:00

[Rob Wuijster]

Hi Holger,

Thanks for that :-)

I will have a look if I can set it up like that.
That's why I posted the image, to see if I was on the right track or if
there would be a smarter/better/more optimized solution for the sim.

cheers,

rob

\/-------------\/----------------\/

[Gene Crucean]

I always use an execute node before the ice tree node. That way I can quickly disconnect the entire tree with one port for debugging.

--
Gene Crucean
VFX & CG Supervisor/Generalist
** Freelance for hire **

Main email: genecrucean [at] gmail [dot] com

[Grahame Fuller]

I usually don't bother with the Execute node. You can always right-click on the root and choose "Insert Execute Node" if necessary later.

As for reusing nodes, you usually don't need to be too fussed about this especially if it affects the readability of the graph. Chances are that ICE will cache anything that can be reused anyway. The big exception is geo queries: those are very expensive and you should reuse them as much as possible. In addition I like to daisychain and reuse object references because it makes it easier to point to a different object later, or create a compound with a single reference port.

I agree with Holger's comments about Age Limit. However if you want the particles to spend slightly different %s of their lives in each state as they are doing now, you could randomize the Age Limit once on entering each state or on the trigger that causes them to exit the state (in a couple of the states you are resetting the Age Limit every frame).

In the second state, you've got two triggers but Trigger2 has nothing plugged into its Execute On port. I presume you are using the first trigger to execute the randomize and the second trigger to change states? You can use a single trigger for both.

In the third state, Set Particle Force works because you are using only one force. However in general I prefer to use Add Forces because it doesn't overwrite any force that may have been set by a previous node. It's a good habit to get into in case you ever reuse stuff in other situations.

In the last state, the Delete Particle at Age Limit already tests the age so you don't need to do it yourself. You can simply plug it into Execute Every Frame and the simulation should behave exactly the same as now. Which is to say, in the last state the particles continue on with their current velocity but no new impetus due to any force until they die. Is that what you really want? If I read your intentions correctly, you could plug the Delete Particle at Age Limit into an Execute Every Frame node of the third state and omit the fourth state. That way the particles will still be affected by gravity right up until they are deleted.

All this is just clean-up and readability though. Chris is right when he says that if it works, it's correct.

gray

[Frank Lenhard]

hey Grahame, i would like to chime in here. when you say geo queries,
do you mean a simple reference to a scene object, pulled into the ice
tree? or do you mean something like get closest location or similar?

ciao
franky

Wednesday, July 22, 2009, 8:29:44 PM, you wrote:

GF> I usually don't bother with the Execute node. You can always
GF> right-click on the root and choose "Insert Execute Node" if necessary later.

GF> As for reusing nodes, you usually don't need to be too fussed
GF> about this especially if it affects the readability of the graph.
GF> Chances are that ICE will cache anything that can be reused
GF> anyway. The big exception is geo queries: those are very expensive
GF> and you should reuse them as much as possible. In addition I like
GF> to daisychain and reuse object references because it makes it
GF> easier to point to a different object later, or create a compound with a single reference port.

GF> I agree with Holger's comments about Age Limit. However if you
GF> want the particles to spend slightly different %s of their lives
GF> in each state as they are doing now, you could randomize the Age
GF> Limit once on entering each state or on the trigger that causes
GF> them to exit the state (in a couple of the states you are
GF> resetting the Age Limit every frame).

GF> In the second state, you've got two triggers but Trigger2 has
GF> nothing plugged into its Execute On port. I presume you are using
GF> the first trigger to execute the randomize and the second trigger
GF> to change states? You can use a single trigger for both.

GF> In the third state, Set Particle Force works because you are
GF> using only one force. However in general I prefer to use Add
GF> Forces because it doesn't overwrite any force that may have been
GF> set by a previous node. It's a good habit to get into in case you
GF> ever reuse stuff in other situations.

GF> In the last state, the Delete Particle at Age Limit already tests
GF> the age so you don't need to do it yourself. You can simply plug
GF> it into Execute Every Frame and the simulation should behave
GF> exactly the same as now. Which is to say, in the last state the
GF> particles continue on with their current velocity but no new
GF> impetus due to any force until they die. Is that what you really
GF> want? If I read your intentions correctly, you could plug the
GF> Delete Particle at Age Limit into an Execute Every Frame node of
GF> the third state and omit the fourth state. That way the particles
GF> will still be affected by gravity right up until they are deleted.

GF> All this is just clean-up and readability though. Chris is right
GF> when he says that if it works, it's correct.

GF> gray

GF> From: softimag...@listproc.autodesk.com
GF> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Gene Crucean
GF> Sent: Wednesday, July 22, 2009 10:25 AM
GF> To: soft...@listproc.autodesk.com
GF> Subject: Re: Little ICE workflow question

GF> I always use an execute node before the ice tree node. That way I
GF> can quickly disconnect the entire tree with one port for debugging.

GF> On Wed, Jul 22, 2009 at 7:00 AM, Rob Wuijster <ro...@casema.nl> wrote:
GF> Hi all,

GF> I'm making baby steps into ICE again, and just wanted some insights on this.

GF> I've created a little ICE tree that will emit particles, slow
GF> them down after a while, next add gravity and finally let them die off.
GF> If somebody could find some time to take a look at the attached
GF> image, to see if this is all set up the way it should be, or if
GF> there can be any improvements in the tree.

GF> The Execute node is there for compound creation, if anyone wonders... ;-)

GF> cheers,

GF> rob

GF> \/-------------\/----------------\/

[Grahame Fuller]

I mean the Geometry Query category in the preset manager, particularly Get Closest Points and Get Closest Location. Some of the others can be expensive, too.

gray

[Raffaele Fragapane]

Anything sampling geometry and dumping a cloud of locators over it will tend to be rather expensive in my experience and not superceded by ICE's optimizations.
BTW when are you going to get rid of the initials quoting in mails? It completely freaks out both gmail and tbird quoting systems :)