Hey Thinkbox Community,
I’m German and new here, so I don’t really have much knowledge what you need to know. I tryed to render a little scene with the Demo-Version of Krakatoa in 3DS Max 2014. Its just a moving ball emmitting particles and a there is a wind for some turbulence… The Ball spawn 50 000 000 particles in 300 frames (1Frame = circa 7Mio). In Krakatoa I use a Lighting densety of 5^-2 and a Final pass densety of 5^-5. When I try to render a still image with F9 it takes forever and there is like this “PF Source Update” i cant do anything, while Krakatoa is doing this stuff… After that it renders pretty fast. When i render the, whole video with F10 it render 1Frame in circa 15 seconds. Why? Can anyone help with that?
An the next question is: When i render sth the CPU (i7 4770K) is only like 25% used and the Ram only uses like 3GB (I got 16GB). Can i push it a little bit further, so it doesnt take so long?
I hope, that you got enough information now.
Thank you very much, I trust in you guys
Matthias.
If you would follow the introductory tutorials on our website, thinkboxsoftware.com/krakatoa-tutorials/
you will learn that rendering a frame from a PFlow simulation can take a while. You are basically telling Krakatoa to ask PFlow to calculate millions of particles from frame 0. The whole waiting time is Krakatoa just sitting around, waiting for the (single-threaded) PFlow to pre-roll the whole animation and deliver the frame. Once the frame is calculated, rendering the same frame again takes no time because PFlow keeps the last particles in memory. On top of that, Krakatoa has its own optional caches to rerender the last frame with different camera or density settings without even asking PFlow…
The workflow solution we have come up with is this:
We allow the user to bake particles to a disk file format. Each frame saves its own .PRT file, giving you direct access to every frame. Of course, you still have to wait for the particles to be saved first. But we also allow you to process only a fraction of the particles for a test render, and then produce so-called partitions (multiple variations of the same simulation with slightly varying random seeds in key operators). Combining these multiple versions produces the multi-million final cloud to be rendered. Also, the saving of these partitions can be offset to a network of computers using Thinkbox Deadline or Backburner network manager.
So the typical workflow is: Create a PFlow. Set the count to something that does not take forever, and render at a relatively low image resolution to get good pixel coverage from the fewer particles. Tweak the simulation look, taking the delay of PFlow into account. Once you like the basic motion, run Partition Saving of the same simulation multiple times (e.g. if you tested with 5 million particles, but you need to render 50 million, save 10 partitions). Increase the output resolution and get the Density down by one order of magnitude to adjust for the increased combined density. Use a PRT Loader to load all 10 partitions at once, in almost no time, on any frame. Then use Magma (a.k.a. KCM) modifiers, deformer modifier like Bend, Twist, FFD, Path Deform, Max and Krakatoa Materials and so on to modify the cached particles further to get the look you are after without resimulating.
This is how all companies like Pixomondo or Scanline VFX (to stay with the German examples ) create their magic.
In addition, we developed Stoke MX, a product that speeds up particle simulation driven by velocity fields (e.g. FumeFX). On 8 threads, it is over 6 times faster than PFlow start-to-end thanks to multi-threading, but subjectively it is orders of magnitude faster because it lets the user do other things while the simulation is running. In fact, you can even render in Krakatoa an already simulated frame while the next frames are still being simulated…
You can see a glimpse of Stoke at time 12:30 in this Siggraph demo: thinkboxsoftware.com/news/20 … rview.html
Regarding the memory and CPU usage:
If you have 4 cores and no Hyper-Threading, 25% would be one CPU fully loaded. If you have HT on, that means about 2 cores fully loaded. I have an i7 with HT on, 8 threads in total. When waiting for PFlow, you should see only one core at 100%. As I mentioned, it is single-threaded. When the actual rendering (Sorting, Lighting, Sorting, Drawing) occurs, you should see a spike of 100% of all cores for a few seconds - for as long as it takes Krakatoa to process the particles. Krakatoa itself is VERY VERY fast and very efficient, and sometimes Task Manager might not even have enough time to capture the full CPU usage spikes depending on the speed of the refreshes…
As for the memory usage, you should NEVER complain that something is using little memory. Krakatoa was optimized to use as little memory as possible, and also gives you a Memory Calculator under Memory Channels rollout that can tell you based on the currently enabled features how many particles you can fit in your existing memory, or how much memory a specific number of particles will require. On a 16 GB machine, using the default settings (Position, Color, Lighting, Density), you could fit over 600 million particles!
) create their magic.