Krakatoa

#841

Dude, you are the artist, you decide. :slight_smile:
Here is the trick:

*Go to a frame you like.
*Check the Iterative Rendering button.
*Press the RENDER FRAME button.
*Check the PCache button.
RESULT: Particles will load and get cached in memory.
*Now tweak the Density value a bit and hit RENDER FRAME again.
RESULT: Particles won’t waste time loading, just light and render.
*Keep on changing the value, for example try 1.0/-1, 5.0/-2. 1.0/-2 etc., and hit RENDER FRAME again

Even without the PCache, PFlow will generally cache the frame in memory, so as long as you are not changing any PFlow settings and the Krakatoa Channels requested remain the same, you can re-render much faster.

Working with Krakatoa requires iterations and tweaking just like with any other renderer. Over time, you will get a better idea of the typical values you need, but it is still an iterative process. That’s what the whole monstrous UI is for :wink:

In Max 2009 and higher, we even allow an optional set of controlsto be enabled around the VFB for even more direct tweaking, including Interactive updates on value changes. So you just change the values and the image re-renders automatically (as long as the previous frame time was below a threshold). But AFAIK you are not using a Max version that supports that.

#842

Yeah I sure am! hehe its just I got a shit loads of things these days so my head is full.

I went and changed the density to 0.05 / -1 instead and the result is pretty nice i think.

http://thomaskc.dk/wip/krakatoa/3mill_krakatoa_render2.mov

slowmotion (12 fps):
http://thomaskc.dk/wip/krakatoa/3mill_krakatoa_render2_slow.mov

#843

hi,

here is my first results with fumefx driven pflowparticle render with kraka. this is only a rnd-test. i can’t render the hole seq because my harddrive is to small. i have to buy a new hdd. 1,8gb cache-file per frame…
http://www.vimeo.com/7435811

i asking the question before: it is possible to get the color from submaterial (emitter) for the particles?? (my test: with pflow+scanline it works, but krakatoa takes only the first submaterial for particles)

thx. tom.

#844

Nice one(s) Tom(s) :smiley:

#845

Hi Tom,

It looks like a (kind of) known bug - material IDs are not being used correctly as it seems.
I will make sure it is properly logged and I hope we will get it fixed in the future. The same applies to PRT sequences in a PRT Loader that contain a MtlIndex channel.

Looking at the output of the a PFlow saved with MtlIndex channel to CSV file, the MtlIndex channel is always assumed 0 so something is broken it the code that is supposed to read that, otherwise it would have been possible to use a KCM in 1.5 to assign textures or colors to particles based on their MtlIndex.

Sorry for the inconvenience. If you want to discuss possible workarounds, please feel free to post here.

#846

hey bobo, thanks for your information. it’s not so nice ;] but i could seperate all my 6 emitterobject, cache it as 6 different prt’s. and colorize with magmaflow. in this case i have a better control over the color.

tom

#847

If you happen to have Box #3, you could write an index into some of the other channels (like MXSInteger) to define which particle in PFlow is expected to use which material.
Then you could save a single PRT and use MagmaFlow with some Switch and == Operators to colorize based on the value in the MXSInteger channel.

It can be done with a Script Operator too, but will be a bit slower. Still, it might be faster than having to split the system manually…

#848

Hey

I’m back again! I have had a couple of weeks with really good results using Krakatoa, fumeFX and PFlow.

Right now im trying to render Krakatoa Voxels which follow a Fume sim on a per event basis using the phantom only option.

The reason i am doing this and not just rendering the fumefx fully in Krakatoa is I only want particles to be sent to the fume after doing some other stuff first.

1st problem is getting the particles that follow the fume to render like the fume or even the Krakatao version of the fume. Im guessing this is because when you use the Fumefx tick box in Krakatoa its actually using the voxels from Fume to guide the position of the particles.

But if you just get PFlow to follow a fume event and render it they dont seem to really “fill” the fume Grid it feels more like they “trace the outline of the vloume” or follow it (as the opereator implies)

IM getting OK results using lots of particles with fairly low density, set to voxel with some filtering, but not great results.

Secondly were having real trouble getting the DOF to render when using the Voxel renderer. It either crashes or is so slow its unsuable.

Any heads up would be great!

THanks

Mike

#849

Krakatoa renders FumeFX by creating one particle per Fume voxel, thus producing a regular grid. When you use the PFlow operator, particles “flow” through the fume grid using the velocities found in the Fume voxels and are thus not guaranteed to be distributed evenly, thus what you are seeing is to be expected - some Krakatoa voxels might get several particles, others might get none and this changes over time, potentially producing flickering.

As for the DOF, this was reported as a bug recently (I think esp. when particles are BEHIND the camera). The workaround until this gets fixed would be to enable the MultiPass Motion Blur of the Camera. Of course, 12 passes MBlur will take 12 times longer, but at least it won’t crash.

#850

Hello BObo would you please tell me if there is any way to control the voxel size by magmaflow?! i played with scale channel but noting happened!

Thanks :rolleyes:

#851

Hi,

The voxel size defines a uniform grid with size in world units. It is a renderer property, not a particle data channel and thus cannot be controlled with MagmaFlow.

What we intend to add in the future is some form of Radius Data Channel that would allow you to easily register a single particle over a large number of voxels (think of a spherical shape converted to PRT Volume like in this example

So you could fill millions of voxels with just a thousand particles or so…

In the current implementation, each particle registers with exactly one voxel (when Filter Radius is set to 1). If the Filter Radius is increased, every voxel will sample a larger volume of neighboring voxels and get a portion of their particles’ influence. So we intend to add a feature where a single particle will register with multiple voxels automatically, but I cannot tell when this might become available.

Right now, you could work around in various ways:
*You could load your PRT into PFlow, assign Spherical (or other) shapes, convert the PFlow to Mesher, convert Mesher to PRT Volume and thus fill large volumes with few particles (as on the image above which uses this approach).
You could load your PRT file with M particles into PFlow and spawn N new particles for each loaded particle, while killing the original one. This will leave you with MN particles that you could distribute in a random or gaussian sphere around the original position while inheriting all other channels like velocity etc. Then on the next frame, you would have to delete all particles you created on the previous frame by sending them to Delete by ID. Since the next PRT frame will contain the IDs of the original deleted particles, they would be created again, then they would spawn again while dying in the process and so on, potentially producing a PRT sequence that has the particles multiplied in large clouds around the original source positions. I have not tested this myself yet (although I have tried something very similar with big success), so I could be wrong.
*You could partition a PRT with the original PRT system loaded in a PRT Loader with either a KCM or a simple scripted modifier that shifts the particle position based on a random seed and a Radius or other Data Channel. The KCM would need an Input to control the seeding and a DNoise Operator using that Seed Input to change the “random” pattern. Add a Noise modifier with no Strength and connect the Input control to its Seed spinner so that Krakatoa would control the Seed of the KCM via the Noise’s value. If you would partition this, you would get PRTs with particles shifted randomly based on the MagmaFlow, producing larger spherical particles. (there is also a global MAXScript variable to get the current seed that could be used as input via a Script Input node, see the documentation).

Hope you get the idea, there is a large field for improvisation with all the tools available, I am sure I have missed some options…

#852

some objects i made consisting of particles, its not that advanced yet but cool possibilitys krakatoa offers for that stuff.
http://www.youtube.com/watch?v=m0CmKORf5Vc&hd=1

#853

I really loved the last, hm, thing :smiley:

#854

Nice Matthias, looking like some nice Box#2 integration if I am not mistaken, for emitters anyway :slight_smile:

#855

hey johnny, my box#2 and 3 trial already expired so its just basic pflow but the boxes are reeeaaaly cool anyways :slight_smile:

#856

Cool stuff once again Matthias. Loved the previous ones as well, synced with music and all…really nice to just sit back and look at.

#857

Hi everyone,

I’m new to Krakatoa and I’m looking for the way to apply different colors to differents PRT loaders for example. The override color button acts for all particles…
I must miss something very simple but I don’t see.

#858

you can apply krakatoa materials to the prt loaders with different scattering (diffuse) colors. But dont forget to turn of the override color again.

#859

eh hello Matthias, it’s funny that you are the one who answered me because I’m fan of your YouTube videos with Krakatoa and in particular, your “Beyonce Halo” is my reference.
I try to reproduce such double sources with different colors…
In which part of the Krakatoa GUI do I access to PRT materials? here again, it’s perhaps a stupid question for experts like you… sorry

#860

Every PRT Loader is a separate scene object and controls the color as follows:
*If the particle file (PRT) does NOT contain a Color Channel, the particles will display/render with the wireframe (object) color of the PRT Loader.
*If the particle file contains a Color channel, it will be loaded and displayed/rendered (so if it was saved from PFlow or other systems, each particle could bring its own color along).
*If a Krakatoa Channels Modifier is assigned to the PRT Loader and modifies the Color channel, the changed colors will display/render.
*Unless a Material is assigned to the PRT Loader in which case the color of the material (including any supported maps) will define the colors of the particles. By default this overwrites the colors in both the Viewport and the Renderer. To ignore the Material’s colors in the viewport, there is a checkbox “Ignore Material”.
*If a Global Channels Override with color-related KCMs is defined in the Global Render Values rollout, this will modify ALL PRT Loaders (and other renderable particle systems) at RENDER TIME.
*If a Color Override is enabled (solid color or Map) in the Global Render Values rollout, it overrides ALL the above sources.

As you can see, this is a hierarchical systems with the later options overruling any of the higher on the list options.

So in your case, your best bets for coloring individual particles are Krakatoa Channel Modifiers and Materials. The KCMs can do things like color a particle based on various channels like Velocity, Position, Normal, Age and LifeSpan and many more -see the example in the documentation like here and here.
The Material is usually applied either in 3D object space (procedural maps like Cellular) or to explicity UV coordinates (which should be present in the PRT file or must be generated by a KCM).
The last fact also lets you apply Marerials and Maps by manipulating the UVs of particles, for example see this example of a color gradient based on Age/LifeSpan calculations.