Krakatoa

[Bobo]

Hi there,

I’ve recently started digging into Krakatoa and I’m experiencing a little difficulty.

I have a particle emitter that’s Path constrained onto a spline and I am trying to save a sequence of Krakatoa .prt files of that animation. I’ve done so and it saves the particles, but not its animation along the spline. Is there any way that I can do this?

Thanks a lot

Can you provide some more info?
What kind of Emitter (legacy particles or PFlow), what is the end result and how is it different from the expected result? Screenshots, animation or a scene file are welcome.

Krakatoa is supposed to save the particles in world space exactly as calculated by Max. Of course, moving an emitter along a path does not automatically move the particles along the path (in the case of the legacy particles like SuperSpray, there is a space warp for that, for PFlow it is doable via scripting).

Once you have saved the PRT sequence, do the particles loaded by the PRT Loader when set to 100% in the viewport match the positions of the particles of the source system? (normally they should - show us a screenshot if they don’t align). You can also deform particles loaded by a PRT Loader using a Path Deform to create a particle cloud following a path after the saving which might be easier and would be a lot more flexible.

[xtremist999]

Can you provide some more info?
What kind of Emitter (legacy particles or PFlow), what is the end result and how is it different from the expected result? Screenshots, animation or a scene file are welcome.

Krakatoa is supposed to save the particles in world space exactly as calculated by Max. Of course, moving an emitter along a path does not automatically move the particles along the path (in the case of the legacy particles like SuperSpray, there is a space warp for that, for PFlow it is doable via scripting).

Once you have saved the PRT sequence, do the particles loaded by the PRT Loader when set to 100% in the viewport match the positions of the particles of the source system? (normally they should - show us a screenshot if they don’t align). You can also deform particles loaded by a PRT Loader using a Path Deform to create a particle cloud following a path after the saving which might be easier and would be a lot more flexible.

Ohh… I worked out the problem was that I had ‘Load First N Particle’ selected rather than ‘Load Every Nth Particle’ in the Viewport rollout. So it looked like it wasn’t moving… Silly me!

Yes I also tried your suggestion. It is more flexible and easier to manage too. Thanks for that.

One more question: I heard that ‘Particle Age’ maps can’t be applied to Krakatoa Particles. Is there a workaround to get particles to change color with age?

Thanks again!

[Bobo]

One more question: I heard that ‘Particle Age’ maps can’t be applied to Krakatoa Particles. Is there a workaround to get particles to change color with age?

Correct.

The Particle Age map has an artificial and very low limit to the number of particles it can affect, so we decided not to support it early on.

You can control the color of the particles with ANYTHING using MagmaFlow, but Color By Age is one of the most common requests next to Density By Age and Speed By Color.
See this tutorial for some ideas that go way beyond what the Particle Age map does:
http://software.primefocusworld.com/software/support/krakatoa/magmaflow_fading_off_particle_density_by_age.php

[xtremist999]

Correct.

The Particle Age map has an artificial and very low limit to the number of particles it can affect, so we decided not to support it early on.

You can control the color of the particles with ANYTHING using MagmaFlow, but Color By Age is one of the most common requests next to Density By Age and Speed By Color.
See this tutorial for some ideas that go way beyond what the Particle Age map does:

http://software.primefocusworld.com/software/support/krakatoa/magmaflow_fading_off_particle_density_by_age.php

Thanks for that, it was exactly what I was looking for and it works really well. Looks quite versatile too in what it can do.

Am I right in thinking that the KCM can’t be applied to Particle Flow emitters but instead my particles must be saved out first and reloaded via the PRT Loader before I can apply the KCM?

It’s just that waiting for particles to save is quite time consuming and I’m hoping there is a way to apply these settings without needing to always re-save particles after making changes to the particle movement.

Thanks again!

[Bobo]

Am I right in thinking that the KCM can’t be applied to Particle Flow emitters but instead my particles must be saved out first and reloaded via the PRT Loader before I can apply the KCM?

There is a way to apply KCMs to ANY particles being rendered regardless of their source.
We call these Global Channel Override Sets.
http://software.primefocusworld.com/software/support/krakatoa/global_render_values.php

In short, a special helper object is created in the scene when you make such a set, and you can add any number of KCMs on top of it. You can also have any number of these helpers (sets), but only one or none active at a time.

When Krakatoa loads the particles, it will run the KCMs found in the active (highlighted) set in WORLD space (so if you are using the Position channel in some way, you have to keep that in mind as KCMs on PRT Loaders operate in LOCAL OBJECT space on the stack). So these KCMs can be applied to particles coming from PFlows, Thinking Particles, Geometry Vertices, Legacy Particles and FumeFX sims in addition to PRT Volumes and PRT Loaders.

Obviously, in order to do the Age coloring, the particles must have Age and LifeSpan channels, so that wouldn’t work on vertices, but can work on PFlows without intermediate saving.

The other limitation of these global override KCMs is that they cannot be seen in the viewports, only in the final rendering. Otherwise they function like local KCMs and you can stack them and pass data between them, read and write channels data and so on.

Hope this helps.

[xtremist999]

There is a way to apply KCMs to ANY particles being rendered regardless of their source.
We call these Global Channel Override Sets.
http://software.primefocusworld.com/software/support/krakatoa/global_render_values.php

In short, a special helper object is created in the scene when you make such a set, and you can add any number of KCMs on top of it. You can also have any number of these helpers (sets), but only one or none active at a time.

Thanks I’m had a try with working from the help file right now. I’m using the same file as the Magmaflow tutorial and I’ve created a Global Channel Overide set with the same KCM settings (Density & TextureCoord) copied across into the set however they don’t seem to affect the appearance of the particles in either PFlow or PRT Loader.

I then tried applying a basic Color KCM and that works, however no matter what I try I’m still stumped about the others settings.

I’ve attached a Max 2010 file with my settings if it helps.

Thanks again!

[Bobo]

Here is what you were missing:

1. The PFlow needs Mapping Channel 1 to be pre-initialized to work correctly. We set that channel (TextureCoord) with the Global Override afterwards.
2. The Color KCM on the Global Override set should be set to Gradient or Gradient Ramp to show a variable color based on the Mapping Channel 1 value. I used Gradient Ramp with 3 colors. You can flip the direction by using U Tiling of -1.
3. To avoid wrapping around of the end colors, you should clamp the TextureCoord U value between 0.0 and 0.99 instead of allowing it to go up to 1.0.
4. Krakatoa Material works only on PRT Loaders and PRT Volume objects, not on PFlows. So assigning one does nothing (internally it runs a hard-coded KCM to set the channels, so it needs Krakatoa channels to start with!)

Here is the updated scene:

http://www.scriptspot.com/bobo/krakatoa/Krakatoa_Scene_07_Bobo.zip

Go to frame 60 and render - the Density will fall off before the particles die, and the color will go from blue through green to red over the life of the particles.

Hope this helps.

[xtremist999]

Here is what you were missing:

1. The PFlow needs Mapping Channel 1 to be pre-initialized to work correctly. We set that channel (TextureCoord) with the Global Override afterwards.
2. The Color KCM on the Global Override set should be set to Gradient or Gradient Ramp to show a variable color based on the Mapping Channel 1 value. I used Gradient Ramp with 3 colors. You can flip the direction by using U Tiling of -1.
3. To avoid wrapping around of the end colors, you should clamp the TextureCoord U value between 0.0 and 0.99 instead of allowing it to go up to 1.0.
4. Krakatoa Material works only on PRT Loaders and PRT Volume objects, not on PFlows. So assigning one does nothing (internally it runs a hard-coded KCM to set the channels, so it needs Krakatoa channels to start with!)

Here is the updated scene:

http://www.scriptspot.com/bobo/krakatoa/Krakatoa_Scene_07_Bobo.zip

Go to frame 60 and render - the Density will fall off before the particles die, and the color will go from blue through green to red over the life of the particles.

Hope this helps.

Hi Bobo,

Unfortunately the updated scene file settings don’t seem to work either. :S

When I click the Render button, an error window pops up saying 'Unable to get channel “TextureCoord”. Actually this error repeated popped up in tests that I was during last week.

I’m sure I’ve followed the info in the help files correctly, so its starting to do my head in a little bit!

Thanks again, really appreciate the help

[Bobo]

Hi Bobo,

Unfortunately the updated scene file settings don’t seem to work either. :S

When I click the Render button, an error window pops up saying 'Unable to get channel “TextureCoord”. Actually this error repeated popped up in tests that I was during last week.

Did you enable the Mapping operator in the PFlow? (somehow I got the scene saved with it off). When I enable it, it stops complaining. See the first point in my previous post.

I updated the ZIP, try it again.

[Strob]

Hi,

I just noticed we can use krakatoa just for caching pFlow to disk and it works great! what would max users be without you BOBO!!! Thank you so much for you hard work and your presence on this forum. I read you a lot!

I just have a little thing I can’t seem to be able to do. I want my particles to start fading on 16 frames just after a collision. I was able to do it by using the mapping operator and animating uv or color vertex. It is working when I render with SCANLINE my cached pflow in PRT files on a krakatoa PRT birth flow. But when I want to render with vray, it does not work…

It seems vray can’t read vertex color material and can’t neither read uv on particles. So with vray it did not work on the original pflow neither. What is working with vray is only when with the original pflow I create a multi sub object with 16 materials (one for each frame) and I animate the id in a material dynamic operator inside the post collision event. BUT this does not work in the krakatoa flow… It seems the animated material ID is not present in the krakatoa PRT update…

I was also able to fade krakatoa prt flow by age with vray by using my material dynamic with animated ID inside the krakatoa prt flow, but it fades only by global age and I would need it to fade only by the original post collision event.

Is there a way I could make vray see the material Id or vertex color or uv or anything else in prt in order to fade particles? Maybe by KCM? Or I would need a kind of reverse Age reading in the Krakatoa file ID test to send the particle who are 16 frames before dying in another event.

[Bobo]

I just have a little thing I can’t seem to be able to do. I want my particles to start fading on 16 frames just after a collision. I was able to do it by using the mapping operator and animating uv or color vertex. It is working when I render with SCANLINE my cached pflow in PRT files on a krakatoa PRT birth flow. But when I want to render with vray, it does not work…

I was quite surprised as I had not tried this before.
As usual, when something does not work right in PFlow or VRay, I created a Mesher compound and guess what? That works!

My test scene was simple:

*Created a default PFlow
*Added a Delete By Age 30
*Added a Mapping operator animated from 1,1,1 to 0,0,0, Sync By Age, Vertex Color
*Added a Material Dynamic with a Standard Material and Vertex Color in Opacity Map slot

Rendering this in Scanline produced fading off particles.
Rendering in VRay produced no particles at all (it used 0,0,0 for Opacity).

*I created a Mesher from the PFlow and assigned the same material to it

Rendering in VRay showed the Mesher with the correct fading off opacity.

Not sure if this helps in more complex cases, but it seems to be a possible solution.

[Strob]

Thanks a lot for that tip.

I will try it. I’m a bit afraid it will be too heavy though. Unless I can create a mesher out of the krakatoa flow and still get it working with vray.

Anyway if it doesn’t work I can still buy box 3 to cache my particles. I am testing it right now and it works great cause I can skip the shape operator that is slowing down my setup and vray obviously works great that way too. My initial problem was that the standard ram caching was too limited in memory, my max scene was around 5Gb and the last frames were not even cached.

[JohnnyRandom]

Cool spot w/ Krakatoa:

http://www.youtube.com/watch?v=Y4VstrHQDMw

[EricTT]

a question ,how to render particle with krakatoa like this :the particle’s color with a gradient ramp color from birth to death

[Bobo]

a question ,how to render particle with krakatoa like this :the particle’s color with a gradient ramp color from birth to death

http://forums.cgsociety.org/showpost.php?p=6366663&postcount=987

http://software.primefocusworld.com/software/support/krakatoa/magmaflow_fading_off_particle_density_by_age.php

[AdrianWilliams]

Awesome stuff bobo, would love to see more of the cloud stuff

[rhys24]

Did you enable the Mapping operator in the PFlow? (somehow I got the scene saved with it off). When I enable it, it stops complaining. See the first point in my previous post.

I updated the ZIP, try it again.

Hi Bobo,

Tried the zip file, as trying to do the same thing with a simulation bought in from realflow and trying to change the color based on vorticity, but nothing seems to change in the file you gave.

[Bobo]

Hi Bobo,

Tried the zip file, as trying to do the same thing with a simulation bought in from realflow and trying to change the color based on vorticity, but nothing seems to change in the file you gave.

So if you open the file I uploaded and render a frame, you see no colors?
Before there was an error. What do you see now?
(Don’t try to involve RealFlow particles before you have figured out the pure PFlow setup).

It works for me on my home machine, anybody else having a problem loading and rendering that sample file?

I just downloaded it and rendered on the office workstation too and it also worked, but I am using the latest internal build which might have fixed some errors. Will try to install 1.5.1 and try again…

[JohnnyRandom]

Guess you guys fixed it, it works for me too.

[rhys24]

It just red for me, and stays red.