Next Topic (None)

Partitioning Existing File Sequences in Krakatoa v1.1.1

1 Partitioning Existing File Sequences in Krakatoa v1.1.1

IMPORTANT NOTE

 The following tutorial was intended for users of Krakatoa v1.1.1.
 In Krakatoa v1.1.2 and higher, you can achieve the same results using a high-frequencly
 Noise Modifier and the new options in the Partitioning rollout for randomizing Seeds of
  modifiers assigned to PRT Loaders or Geometry.

Introduction

In general, Partitioning in Krakatoa is performed by saving the same dynamic particle system - Particle Flow, Thinking Particles or 3ds Max Legacy Particles - with varying Random Seed values to randomize parameters such as Position, Speed etc. Unfortunately, this method cannot be used when the particles in question have been saved to file sequences, for example from RealFlow to a BIN file sequence, or from 3ds Max to a single PRT file sequence. Furthermore, Geometry Vertices from a scene object have only positions but no velocities and cannot be directly randomized by Krakatoa when saving or when loading a PRT file saved from them.

The following tutorial introduces a workflow featuring the Krakatoa 1.1 Particle Flow Operators which will allow you to perform Partitioning on existing particle file sequences which cannot be partitioned the usual way. This workflow could be used for example to increase the density of a RealFlow simulation without the need to simulate and save the same RealFlow set up with varying parameters.

The Idea

As explained in the previous tutorials, when loading particle file sequences into Particle Flow using the Krakatoa 1.1 File Birth and File Update operators, after the particle positions and/or velocities are loaded, Particle Flow will perform an integration step which applies the velocities to the positions and causes a slight offset as compared to the positions saved to the source particle file sequence.

We can use this fact to our advantage to introduce a randomness in the positions of the loaded particles on each frame by either modifying or completely replacing the velocity of the particles with a random value using regular Particle Flow operators which DO support Random Seeds.

Randomizing Static Particle Positions

Let's start with the simplest case - a static particle cloud saved from the vertices of a Teapot Primitive to a PRT file. The following is of course just for the sake of demonstrating the concept, as it is much easier to use a geometry object in a Position Operator to distribute particles randomly on its surface.

Rendering and Saving the Geometry Vertices

Let's create a teapot with a radius of 50.0 generic units and 32 segements (32898 vertices).
The particles have regularly spaced positions across the surface of the object and no velocities at all. When rendered, they look like this:

Switch Krakatoa to "Save Particles To File Sequence".
Specify a PRT file name to save to.
Save a single frame to disk.

Loading the PRT File in Particle Flow

Let's create a simple Particle Flow with
- Geometry Render operator in the Emitter,
- A Krakatoa File Birth operator loading the PRT file containing the Teapot vertices generated in the previous step.
- A Krakatoa File Update operator loading the same PRT file with "Single Frame Only" checked
- A Speed Operator set to 100.0 +/-50.0 and Random 3D
- A Display Operator set to Lines.

Set the Integration Step for rendering to 1 Frame.
Switch Krakatoa to "Render Scene Particles" mode and pick "PFlow Geometry" as the only source.

Rendering frame 0 will still show the original positions since the velocities have not been applied yet. Rendering frame 1 or higher though will show a completely randomized but static cloud of particles - this is because the Krakatoa File Update operator does not load any Velocities and the Speed operator is applied just once on entering the event. Thus, the particle positions are updated on each frame from the same PRT file and the same random velocities are used to integrate the new random positions:

Partitioning the Teapot

Since the Speed Operator uses Random 3D mode and DOES have a Seed parameter to control the randomness, generating partitions from this Particle Flow system will result in DIFFERENT particle clouds based off the same particle positions but with random offsets in each partition.

Set Krakatoa to "Save Particles To File Sequence" mode.
Specify a valid partition name (or use the previous file name)
Set the number of partitions to 100
Press the "Generate Partitions Locally..." button
Confirm the Single Frame prompt with Yes to save only two frames per partition.

The following is the result from saving 100 partitions and loading them using a PRT Loader. The Final Pass Density was set to 1.0/-3 to account for the increased number of particles - 3,289,800 particles to be exact.

Partitioning RealFlow Simulations

Now let's take a look at a real practical use of this approach by partitioning a single RealFlow simulation.

Previewing the BIN Sequence

We start with a BIN file sequence containing a simple RealFlow splash with only 160K particles.
When loaded using a PRT Loader and rendered, it looks like this:

With 16 passes Motion Blur, it looks like this:

Loading the BIN Sequence in Particle Flow

To create partitions from this BIN file sequence, let's load it into Particle Flow.
- We use a Krakatoa File Birth Operator to load the initial positions. To turn the Y-up into Z-up, the Particle Flow Emitter can be rotated and if necessary scaled and the "Link To Object TM" checkbox can be checked to use the transformation of the Emitter.
- A Speed Operator set to Random 3D and 20.0 +/- 10.0 will provide a random offset to the particles.
- A Krakatoa File Update loads the same particle sequence and sets only the Position and ID channel (for now).
- A Krakatoa File ID Test sends out any particles with negative IDs to remove dead particles (if the sequence has any particles killed during the simulation)

The resulting randomized Particle Flow system renders like this:

Partitioning the Sequence

To partition the RealFlow BIN sequence, we can now simply
- Switch Krakatoa to "Save Particles To File Sequence" mode
- Set an output PRT file name
- Set the desired number of partitions and
- Press the "Generate All Partitions Locally..." button to process the partitions. (alternatively, if you have Deadline and the files are accessible over the network, you could use the options for network partitioning).
The BIN sequence in question contained 70 frames and tool about 18 minutes to generate 10 partitions. This is a lot faster than the time that it would take to simulate in RealFlow even just once.

Loading and Rendering the RealFlow Partitions

Now we can create a PRT Loader and select any of the saved partition files.
Confirm the prompt to load all partition sequences.
Reduce the Final Pass Density Per Particle value a bit to take into account the higher particle count (1.6 million particles instead of 16 thousand)
Switch Krakatoa to "Render Scene Particles", set the source options to load only from PRT Loaders and render.
The result looks like this:

Generating Correct Velocities For Motion Blur

So far, we used the Random 3D Speed to jitter the positions of the particles, but we did not load and preserve the original velocities stored in the file sequence.

To get a stable and fast updating Particle Flow, we will generate the offset Speed just once.
Then we have to store the initial velocities in a channel. We can use either Particle Flow Tools Box #3 Data Operator or a simple Script Operator to copy the velocities from the Speed channel into the Scripted Vector channel.
Then we send out the particles to a new event where another Data Operator or script does exactly the opposite, copying the content of the Scripted Vector channel into the Speed channel.
Then we use a Krakatoa File Update operator to load Positions, IDs and Velocities from the particle sequence. We have to set the Velocity channel to Add 100% of the velocities, resulting in both the offset vector and the original speed co-existing.
Finally, we send out the particles with negative IDs to an event with a Delete operator.

After partitioning this system, we get the following result (16 passes motion blur, 32 partitions, 5.2M particles):