Krakatoa Rendering Process

Overview

The following topic discusses the major phases of the KRAKATOA general workflow, and of the KRAKATOA rendering process.

Particle Generation And Caching

KRAKATOA needs particle data to be rendered.

As a first phase of the Krakatoa workflow which is separate from the actual rendering process, particles need to be generated, and optionallu cached.

• The particles can come from various sources, including
  • Particle systems native to the host 3D application
  • Mesh and spline vertices
  • Particle data files on disk previously cached by KRAKATOA, or other applications
  • Particle data generated procedurally by one of KRAKATOA’s built-in objects.
• In the case of the integrated KRAKATOA MX, KRAKATOA MY and KRAKATOA C4D, all particle sources except for disk files can be rendered directly without first caching to disk.
• When rendering in KRAKATOA SR using the C++ API, particle data can also be sent directly to the renderer without caching to disk first.
• The actual saving of particles can be performed either using the Save Particles mode of the KRAKATOA renderer, or using a dedicated exporter function implemented in the native scripting language of the host 3D application.

Pros of Particle Caching

• Caching long particle simulations ensures that data can be computed once and rendered many times with less overhead.
• Caching also allows direct access to any data on any frame without time-expensive pre-rolling to compute the requested frame’s content.
• Caching can be extended to Particles Partitioning, allowing the saving of multiple variations of the same simulation with slightly different coniditions to produce a much larger number of particles than the system could handle in one go.
• Cached data can be repurposed in one of many ways, for example particle caches can be
  • Cloned, repositioned, rotated and scaled to produce multiple instances of the same particles in 3D space.
  • Retimed to speed up, slow down, invert timing, create ping-pong effects etc.
  • Modified and deformed to change the look and appearance of the particles without simulating again.
• Particle caches can be reused between projects, turning into libraries of particle assets.
• Cached particles can be shared between the various versions of KRAKATOA, allowing particle simulations to be simulated in 3ds Max, Maya, CINEMA 4D, or any other application that can save PRT files (incl. RealFlow, Naiad, Bifrost, Houdini etc.), and to be loaded and rendered in any version of KRAKATOA (3ds Max, Maya, CINEMA 4D, Stand-alone).
• Particle caches can be read partially (First N particles, Every Nth particle, Limit particle count) to provide a quick viewport preview of very large sequences.
• Alternative low-resolution particle caches can be saved and only loaded for even faster viewport previews, while rendering the full version of the cache.

Cons of Particle Caching

• While PRT files are compressed, long particle data sequences with many millions of particles per frame can use up a log of disk space.
• If the particle simulation if changing a lot due to tweaks to the source system, each time a new version is simulated, the PRT files need to be resaved.

Particle Loading

The first step of the actual KRAKATOA particle rendering process is the loading of the particles into memory.

• Currently, all particles must fit in RAM for KRAKATOA to be able to render them.
• The amount of memory a single particle will use depends on the number of channels KRAKATOA needs to allocate.
• The number of channels depends on the features enabled by the user:
  • The Position, Densit and Color channels will always be allocated.
  • If lighting is enabled (it is by default), a Lighting channel will also be allocated.
  • If the Emission and Absorption options are enabled (by default they are not enabled), Emission and Absorption channels will be allocated.
  • If Motion Blur is requested, a Velocity channel will be allocated.
  • If the shading mode (a.k.a. Phase Function) is set to Phong Surface, a Normal channel will be allocated.
  • If the shading mode is set to different shader than the default Isotropic or Phong, additional channels might be allocated as required or requested by the user via the UI.
  • Further additional channels might be required by other features and render passes.
• The actual memory layout and memory allocation amounts will be reported by KRAKATOA in the log.

Matte Objects Rasterization

If Matte Objects are enabled and defined in the scene, they will occlude light and cast shadows onto the particles, and will also occlude particles from the camera view.

• The Matte Objects are rendered into a Z-depth pass by KRAKATOA, which is then used to determine the occlusion by comparing the Z-depth of the particle to the Matte pass buffer.
• An initial Z-depth pass generated in any other renderer can be loaded and used the same way, or it can be combined with the scene’s Matte Objects.

Particle Sorting And Lighting

The next step of the KRAKATOA rendering process is the illumination of the particles.

• The lighting of the particles is performed for each light source in the scene, and consists of two sub-steps:
  • In the Sorting sub-step, all particles are sorted relative to the light source front to back.
  • In the Attenuation calculation sub-step, shadowing of particles by matte objects, and self-shadowing of particles by other particles is calculated.
  • The sorted particles will be split into multiple slices based on the number of CPUs/Cores and available RAM, and will be processed on multiple threads.
  • The resulting partial attenuation maps are then combined into the final attenuation solution.
• The results of the lighting calculations will be stored in the Lighting channel of the particles.
• This lighting step will not be performed if the Ignore Scene Lights option or the Force Additive Mode option is enabled.

Particle Sorting And Drawing

The last step of the KRAKATOA rendering process is the drawing of the particles.

• The drawing of the particles is performed by
  • Sorting the particles back-to-front relative to the camera,
  • Splitting the sorted particles into multiple slices based on the number of CPUs/cores and available RAM,
  • Drawing each particle of a slice back-to-front into the output image buffers and render passes,
  • Compositing the resulting image buffers and any background color or image into the final output.
• If Matte Objects are enabled and an OccludedParticles pass is requested, the RGBA data of the particles will be split into either the beauty pass if the particle is in front of all occlusions, or into the OccludedParticles pass if it is behind.

Voxel Rendering

• The above steps described the particle rendering mode process.
• When in Voxel mode, the process is slightly different:
  • The particles are still loaded into memory and their channels are registered on the voxel grid.
  • For each spot or direct light, the voxel grid is drawn from the camera view back to front at a half-angle between the viewer’s direction and the lighting direction.
  • Omni/Point lights are not supported.
  • If Emission is enabled, the Emission will be drawn in an additional lighting pass.

Compositing

• In most cases, the render output of the KRAKATOA renderer needs to be composited in a post-processing step with other imagery rendered in another renderer, or captured using other means (e.g. real camera footage).