Krakatoa

#1

Hi,

Hoping to catch Bobo again - can you (or somebody else that knows it) tell us a bit more about Krakatoa? What’s with the billions of particles? :smiley: Sounds too good to be true! Collecting the pieces of info, it seems like it can be used both as a normal and point renderer, but how is it going to manage billions of particles? Is it a particle engine, or just a renderer, that can multiply particle counts at render time? And frantic’s site tells of a ‘particle flow integration’ - how’s that going to happen? A brief description of what it is, how it works and what is the workflow like would be awesome!

Thanks again :wink:

#2

Check this:
http://www.orbaz.com/forum/viewtopic.php?t=872&highlight=

Now, only question when it will be released and what will be price…
And i’m still waiting for Frantic Films respond… :cry:

#3

Where did you send your question? :wink:

We intend to release Krakatoa in the first quarter of 2007. Anywhere between 1 month from now and when it is ready :wink: We are currently in beta and fixing bugs, polishing the UI to give you as much power as possible and even adding some more features requested by our testers.
The price has not been announced yet, but at Siggraph 2006 it was suggested that it would be rather affordable :slight_smile: I will let our marketing dept. deal with that though…

#4

Ok, here is a short version of what you need to know:

Krakatoa is a Volumetric Particle Renderer. It started as a Point Renderer in 2004 when we first had to work with the late Richard Dr. Baily, known for his Spore designs which you can still find on www.imagesavant.com
Dr. Baily worked on ancient SGI machines, writing his own code to procedurally generate millions of particles using complex multi-dimensional mathematical functions. Kevin Tod Haug, the visual effects supervisor of movies like Fight Club, The Cell, Panic Room and Finding Neverland, was a good friend of Doc. They envisioned a sequence for the Marc Forster movie “Stay” where the Brooklyn bridge in NYC turns into a fantastic glowing plasma world made of spore particles. They created some test scenes and while they looked gorgeous, it was clear that the propietary software running on an old SGI machine would not be able to deliver the quantities of frames and the quality needed for 2K images on time. So Frantic was hired to work on both the sequence as post production house and as RnD team to figure out how to render all these particles.
We tried every renderer out there, including Entropy and PRman. It was obvious that we needed our own version of a point renderer similar to what Dr. Baily was using, but running on Windows and much much faster. This first incarnation of the Frantic Particle Renderer did only point accumulation (additive or maximum shading) and was crunching about 50K particles per second. Since we used a DLL providing us with unlimited number of spore particles procedurally, we did not have to store the particles, just render them. The final frames featured multiple layers of particles, each layer with up to 500 million particles. Some frames had up to 50 billions! The renderer included DOF and motion blur support and created EXR files.

Over the following year, we used the renderer to shade smoke simulated with FLOOD for the movie Cursed and on some other projects. Eventually, both Frantic and Dr. Baily were hired to work together on Kryptonite effects for Superman Returns. Once again, we connected with his Spore and rendered both volumetrically and in 2D. But for the underwater and water sequences we were also awarded, we had to render clouds of silt that required more than just point shading - we needed full shading including lighting, self-shadowing, texture mapping support and so on. This is how Krakatoa was born - our RnD dept. took the knowledge from the previous incarnations and developed a new stand-alone point renderer that could do all this. We also expanded the pipeline by introducing a particle file format that could be used internally to load and save particles between Krakatoa, FLOOD and Particle Flow. At that point, we were still using 32bit software, so there were certain memory limits - the stand-alone version could crunch more particles without the overhead of 3ds Max, but we still had to generate multiple layers of particles to get the 1 billion seen in some shots in Superman Returns.

With 64 bit coming, we felt that a built-in 3ds Max renderer would be a great idea for any user, so we did just that. Krakatoa will be available for both 32 and 64bit Max and is used just like any other renderer, but it does not do regular rendering, only particle shading. Since it supports matte objects that can occlude particles and cast shadows on particles, it is possible to integrate the resulting frames into any scene. The results from volumetric shading are similar to what you would get from raymarching software like Afterburn, but the detail from fluid particle simulations could be actually retained as each particle is rendered as a point.

Krakatoa will support Particle Flow, Thinking Particles, Max Legacy Particles, Realflow BIN files and some more. You will be able to save particles to disk from any of these sources and load them again, even multiple times. It supports motion blur, DOF, texture coordinates (so you can map volumetric textures onto your particles), several shading modes, and a unique automatic history system that will keep books of any test renders you perform and will allow you to review and restore any settings used in the past to get the same results.

We have much bigger plans for post-1.0 release, our aim right now is to provide a first iteration of something you could use easily.

If you have any technical questions, please ask!

#5

Some more thoughts regarding Krakatoa 1.0:

*When we say “Volumetric Particle Renderer”, we mean just that. The user has control over the density per particle, which means that the shading is performed with a consistent density regardless of the particle count. So you can create 10K particles, render a quick test to adjust lighting and shading, then bump up the particle count to 10 million and render, knowing that the result will be of much finer quality, but the volumetric density would be the same.

*The shading itself is really fast, the slow portion is usually waiting for a particle system to give the renderer enough particles to shade.

For example,
I just created a default Particle Flow, set the viewport display count to 0.1%, set the System Limit to 1 Million, created 1 million particles from frame 0 to 30 with speed of 30.0 and rendered frame 30. Particle Flow calculated the particles and then Krakatoa rendered them in 37 seconds. Once the particles have been calculated though, PFlow has them cached and does not need to recalculate again unless you change some operator. So one can change the view, add lights, change materials, tweak any Krakatoa-specific settings in the Render Dialog and rerender without waiting for PFlow to rebuild again.
So I hit render again and got the same result - 1 million particles - in only 6 seconds. Half of the time was shading, the other half was getting the data from PFlow.
So I bumped up the Motion Blur segments to 10 and rendered with 10 passes motion blur in 30 seconds, which means that the average time per shading pass was really less than 3 seconds for 1 milltion particles. Then I added a light to the scene and rendered again with 10 passes mblur - the time went up to 34 seconds…
Later I tried bumping up the System Limit and the Particle Count to 2 Million - after calculating the particles once, the shading with 10 passes mblur took exactly 60 seconds, which shows that Krakatoa scales linearly (as long as physical memory is not a limitation).

*To avoid the constant waiting for particles to be delivered, we allow the user to save to a PRT file instead of rendering to the frame buffer. Once you like your particle system, you can write it to disk once and then load from disk straight into Krakatoa for rendering.

*Since Particle Flow and most other systems have a certain limit of particles they can handle at once which is generally much lower than the number of particles Krakatoa can shade, you can generate multiple files from the same PFlow but with different Random Seeds for Position, Speed and Spawn operators, then load any number of these “partitions” and render at once as a single particle cloud. We provide tools to generate these files manually or automatically via our Deadline network manager. Deadline provides a free two slaves mode so anyone using Krakatoa could also use Deadline for running partitioning jobs.

*Since any particle system can be saved to a PRT file and any file can be loaded any number of times using special Particle Loader objects, Krakatoa can be used as an extended particle system design tool.
For example, let’s say you want to model a galaxy of stars. You can design dozens of animated suns using PFlow and spherical emitters, assign mapping and play with densities, sun flares and whatever, then save each star as a PRT file to disk. Now you could create ANY number of loaders (by hand or via MAXScript), each one loading one of the PRT files. (A loader can load any number of PRT files, even Realflow BIN files). You can even overwrite the colors using the material assigned to the loader object, keyframe the PRS of the loader to have each sun moving in space, offset the animation to randomize their look, control the number of particles to be loaded per loader and basically design a whole new scene consisting of hundreds of pre-saved particle systems without any calculation overhead (execpt for disk IO). Then Krakatoa can render the scene by simply loading all PRT files referenced by the scene loader objects…
Then you could save the WHOLE new scene with all its stars to a single PRT file and repeat the process to make an even larger universe! :bounce:

*The GUI of Krakatoa is written completely in MAXScript, so anyone who does not like it can basically rewrite it or change it at will. The Scripted GUI already provides some management tools that will save you from writing your own scripts to mass-change properties of particle loaders, create selection sets for matte objects and so on.

*The History system I already mentioned is the most advanced Render Presets system available for any renderer in 3ds Max (and possibly in any 3D application). Each time you hit the Render button, a complete record of all settings in the UI is saved, together with an optional copy of the final frame for thumbnail browsing. You can also load and save presets manually at will, with full control over each single setting to be saved or loaded. A sophisticated comparison system will show you the differences between ANY two history records, presets or the current settings and allow you to simply copy any of the saved settings to your current setup. For example, you can browse through your history list and find a thumbail that shows just the effect you need. You select that history record and you are shown a list of all the differences between your current settings and the settings used to achive that result. You can double-click each one of these differences to copy the history settings into your current GUI, or load the whole preset. Chances are your new rendering will look just like the one stored in the history :slight_smile:

Are You Hyped Yet? :twisted:

#6

Hyped? EXTATIC… C´mon stop the teasing , Bobo :slight_smile:

#7 
    If Krakatoa is separate render, i'm just wondering how will be workaround when matte objects must have other renders Motion Blur. As example if my original scene is rendered with Vray or Mental Ray motion blur and some objects (motion blurred) must pass through particles....

Anyway, Krakatoa sounds very cool :thumbsup:

#8

Most VFX houses rely heavily on compositing various passes using a package like Digital Fusion, Shake, Combustion, After Effects etc. (We use mainly Fusion). But even with the simple Video Post in Max, you can combine your Krakatoa Particles with your Mental Ray, Scanline, Brazil, VRay or whatever rendering…

Here is the simplest example I could come up with:

*I created a default PFlow system with a box emitter
*Set the particle emission to 4 million particles
*Set the Speed to 50.0
*Created a default Teapot
*Animated the Teapot from frame 0 to 10 to move a lot to generate some exteme motion blur. On frames 3 to 6, it is inside the particle cloud.
*Rendered with 16 time samples in Mental Ray.
*Then I set the Krakatoa rendered to Additive shading (no volumetric effects), defined the teapot as a matte object and rendered frame 4 with 16 passes motion blur.
*Finally, I loaded the Mental Ray and the Krakatoa frames in Video Post, selected both and added Alpha Compositor on top of them.
*Executed the Video Post and got the final result (scaled down 50% to save bandwidth):

Teapot_MentalRay_Krakatoa_MBlur.jpg322x724

*Next I created an Omni light, enabled Shadow Casting, set Shadow Map to 1024.
*Assigned a Standard Material to the teapot.
*Rendered a frame of the teapot only.
*Assigned a Standard Material to the Particle Flow.
*Set the Self-Illum. Color of the material to blueish-gray.
*Assigned a default Noise map to the Opacity Map channel, set to Turbulence
*In Krakatoa, I set the shading to Volumetric Density.
*Set Density Scaling mode to “Material Opacity”.
*Set the Particle Color source to “Material Self-Illumination”.
*Rendered the 4 million particles - note that the particle cloud’s density shows the Turbulence Noise map and the teapot is casting a volumetric shadow into the particle cloud.
*Finally, I combined the two images using the same Video Post setup - the volumetric shading produces a correct alpha channel so combining with the main pass is a no-brainer:

Teapot_MentalRay_MPassMBlur_Volume.jpg322x722

#9

Now that’s what I’m talking about, thanks Bobo!

Hyped?! I’m hysterical! And what you described about the UI - the preset management and the thumbnail comparison, etc - this should one of the smarest interface paradigms ever! Totally wow-ed!

:eek:

#10

Thanks!
The original idea for the comparison came from our simulation TD Marcus Steeds (I wish it was my idea ;)). He is a very organized guy and used to write down all settings in a text file by hand doing the silt simulations for Superman Returns. Having an automatic system to keep track of all settings was a logical thing to do…

I took the loading / saving code I wrote for Amaretto and expanded it to support automatic saving, thumbnails, scene info etc. Here is a screenshot of the respective rollout in 0.9.4 (the 0.9.5 version has some additional buttons to let you delete thumbnails later for saving space - the thumbnails you see are saved as full-sized EXR files, so you can hit the image button and see a copy of the ACTUAL rendered frame incl. Alpha channel etc.

Note that the two history records shown only differ in their motion blur and sampling settings and, as seen in the Scene Info windows at the bottom, in the particle count (4M vs. 800K). If you want to use the settings from a history record, you can either double-click the lines in the comparison list (which will take the LEFT value), click either of the “Make This Value Current” buttons to take the left or the right value, or use the “Load From History…” button which opens a tree view with all saved settings that correspond to settings available in the current version (the presets/history records are backwards and forward compatible, so if a control is added or removed in a new build of Krakatoa, you can still load what is relevant):

Note that you can uncheck whole rollouts to not load any of their controls, or uncheck any value specifically to load just what you want. The stored value is shown in [] brackets.

There are some added goodies like double-clicking the MAX scene name in the Scene Info will open Windows Explorer at the path that file was saved when the history record was created, double-clicking any other line would copy the text to the listener for easier copy&pasting etc.

There is also a User Notes rollout with a large text field where you can enter anything other users might need to know about your scene and setup…

#11

Since this thread looks like the place to talk about Krakatoa until it is released, I guess I could provide some more simple examples to give you an idea how it works and what it does.

As mentioned before, there are several shading modes, including Additive and Volumetric Density. 

The following is a Teapot rendered as a particle cloud (each vertex is taken as a particle, the max. number of vertices of a teapot primitive with 64 segments is slighly more than 130K). I used the default custom particle color (white) and a density of 0.005  (which in the UI is expressed as two values - Density 5.0 and Density Exponent -2. This way, changing the Exponent (10^X) to -3 gives you quickly another zero after the decimal point, going up with positive exponents can increase the density quickly by orders of magnitude like 10, 100, 1000 and so on.
[img]http://www.scriptspot.com/bobo/krakatoa/Teapot_Vertices_Customcolor_Additive_5_minus2.jpg[/img]

This is the same rendering, but using the wireframe color of the mesh:
[img]http://www.scriptspot.com/bobo/krakatoa/Teapot_Vertices_Wireframe_Additive_5_minus2.jpg[/img]

The following used the self-illumination channel of the material assigned to the teapot. I added a Cellular map to show that the channel is fully evaluated incl. any textures in it. Note that you have to check the "Use Color" for the Self.Illumination color to be used correctly.
[img]http://www.scriptspot.com/bobo/krakatoa/Teapot_Vertices_MatSelfIllum_CellularMap_Additive_5_minus2.jpg[/img]

Now we switch to Volumetric Density - same setup and density values, but still no lighting. Thus, the teapot is self-illuminated:
[img]http://www.scriptspot.com/bobo/krakatoa/Teapot_Vertices_MatSelfIllum_CellularMap_Volumetric_NoLighting_5_minus2.jpg[/img]

Then I added an Omni Light and turned Lighting on in Krakatoa. 
You can see the shadow casting, but also that light is passing through the particles (since only about 130K) and illuminating the backside (inside, bottom left) of the teapot:
[img]http://www.scriptspot.com/bobo/krakatoa/Teapot_Vertices_MatSelfIllum_CellularMap_Volumetric_Lighting_5_minus2%20copy.jpg[/img]

Now it is time to use Particle Flow to emit particles from the surface of the Teapot. All the other settings are identical. To avoid heavy self-shadowing of the particles when placed on the same surface, I used an offset of -1 to give the "particle teapot" a bit of thickness. The flow uses only 1M particles.
[img]http://www.scriptspot.com/bobo/krakatoa/Teapot_PFlow_MatSelfIllum_CellularMap_Volumetric_5_minus2.jpg[/img]

Note that we can control the density globally by changing the Exponent to -3 while keeping everything else identical (including the particle count of one million). Now we can see through the volumetric cloud:
[img]http://www.scriptspot.com/bobo/krakatoa/Teapot_PFlow_MatSelfIllum_CellularMap_Volumetric_5_minus3.jpg[/img]

The Volumetric Density mode only makes sense with lighting. Here is what you would get from 1M particles with volumetric density but no lighting and no material:
[img]http://www.scriptspot.com/bobo/krakatoa/Teapot_PFlow_Customcolor_Volumetric_NoLighting_5_minus2.jpg[/img]

Enabling the Lighting shades the particles as before. Note that version 1.0 of Krakatoa will also support normals per particle and will thus feature specular highlights, too.
[img]http://www.scriptspot.com/bobo/krakatoa/Teapot_PFlow_Customcolor_Volumetric_Lighting_5_minus2.jpg[/img]

Why would you want to render anything as a cloud of particles? 
Here is a possible situation illustrating what you could do with it...

(Click Here For a Quicktime 7 movie, 1.4 MB)

This example contains 100 frames of 1 million particles. Rendering time on single CPU Athlon64 2.1 GHz with just 1GB of RAM was 22 seconds per frame incl. PFlow calculations, lighting and shading with 4 passes of motion blur. (each pass shaded in approx. 3 seconds, so 12 seconds was shading, the rest was calculating the flow and the lighting).

#12

Just for reference, here is what the same 1 million particles used in the previous post shade like in Additive mode with density of 0.0005. (CGTalk does not allow more than 10 images in a
post):

This is the same animation shown in the previous post, but using the Additive settings and Density of 0.0005. This time, I disabled the Motion Blur. The frame time was consistently 9 seconds, approx 6 seconds for PFlow calculation and data transfer and about 3 seconds for rendering 1 million particles.

Click here for the Quicktime 7 Movie (1.5 MB)

#13

wow. Thanks for the awesome preview bobo, we all know you’re going out of your way to show us what this is about. Looks very very very useful for a lot of situations. Can’t wait to get my hands all over it! Of course when that happens depends on the price!

#14

Wowww!
Very interesting stuff Bobo, thanks a lot for sharing.

QUOTE:“This example contains 100 frames of 1 million particles. Rendering time on single CPU Athlon64 2.1 GHz with just 1GB of RAM was 22 seconds per frame incl. PFlow calculations, lighting and shading with 4 passes of motion blur. (each pass shaded in approx. 3 seconds, so 12 seconds was shading, the rest was calculating the flow and the lighting).”

:eek: Awsome!

#15

Glad you like the times :slight_smile:
I rendered to 320x240, but unlike normal renderers, the frame resolution does not affect render times - the factor here is the particle count. Of course, if you increase the frame resolution, you might need more particles to get the same look, so it would render slower. But as I mentioned already, Krakatoa scales in a linear fashion.

Since the lighting and shading incl. materials and maps can be completely separated from the PFlow calculations, the typical workflow could look like this:

*You create your Particle Flow
*In Kakatoa, instead of Rendering Scene Particles, you select Save Particles To Disk.
*You specify a disk location to write the particles to.
*When you hit Render, instead of creating images, Krakatoa writes a sequence of PRT files (one file per frame).
*Now you can disable your PFlow, load the PRT sequence as the particle system to render (in 0.9.4 this still happens in the Render Dialog, in the upcoming 0.9.5 build one would create a Particle Loader object in the scene and pick the PRT file there).
*At this point, you can start playing with adjusting the shading and texturing - the particle animation is pre-cached to disk and any frame can be loaded as often as needed in very short time (for the 1 million particles, in just about a second). So if you want to tweak frame 50 of the above animation, instead of waiting for almost 3 minutes (the time needed by PFLow to calculate all 50 frames before it), you can just go to that frame and render instantly.

PRT files can be created by other Frantic applications like FLOOD, so we provide a Particle Loader operator for PFlow too. This means that you can load a particle file created in Krakatoa or somewhere else (or a Realflow .bin file!) and drive Particle Flow particles with it… For example, instead of emitting particles per vertex using Position Object+, one could save the Teapot vertices to a PRT file and load them in PFlow as the source, then animate using regular PFlow operators…

At Siggraph, we were showing a frame from an animation of a Mini from The Italian Job made of about 20 million particles and of course we were loading from disk, so people were really blown away by the rendering times… The trick is to work around the calculation speed of the particle system - Krakatoa supports some scripted channels, so if you want to script the color or density of your particles using a Script Operator, the flow might become rather slow, but the results are worth it. Or one could use a Data Operator from Box #3 to get the same results in shorter time…

#16

Hahah, well, that’s about it for the disintegration challenge… :smiley:

This is really turning out to be a serious particle player - looking forward to it!

#17

That volumetric render looks seriously useful especially if you need to do tidal wave type renders - Particle count is somethign that always catches me for these effects…

#18

Getting some very interesting results using fume to simulate movement. P flow to follow the fume movement, and Krakatoa to render it .

Fun stuff.

very cool tool!

I think we are going to see a nice jump in quality of what we can accomplish.

yay fun new tools!

#19

In-house, we use Krakatoa mainly for things that are physically made of particles anyway - like smoke, dust, debris of exploding stars, silt, water droplets and white caps on waves and so on. The exception were the additve effects that started it all thanks to Doc. Baily’s Spore. For massive amounts of water, we use FOOD, with particles used mainly as enhancement.
For “Cursed”, we used FLOOD to simulate the air flow and its interaction with the actors and emitted smoke particles that were affected by the simulation.
http://www.exocortex.org/siggraph/BattyHouston2005_VisualSimulationOfWispySmoke.pdfFor “Superman Returns”, once again we simulated the water flow with FLOOD and added particles underwater for silt and on the surface for droplets (about a billion of them in the pier shot where the waves start hitting Metropolis). In the Red Sun explosion, there were 700 million (I am sure Allan McKay mentioned that in the main PFlow thread).

That being said, it is up to you to find new creative ways to use the tool! We have a long list of things we would love to add post 1.0 release and we hope to get enough feedback and ideas from our users to let them do any magic they want. The next beta build 0.9.5 is so much better than the current one I just cannot wait to see what 2.0 will look like! :bounce:

#20

Bobo, its been said already but, your such an amazing guy! for sure!!