<<Back To Release History

What Was New in Krakatoa v1.5.0

For the bullet points Change Log, see here.

The following is an overview of the changes and new features in Krakatoa v1.5.0 compared to v1.1.3. For all details on new features, please be sure to consult the corresponding documentation pages.

User Interface Customization

Let’s start with the User Interface.

Krakatoa 1.5.0 is assigned and opened the same way as its predecessor, but provides a large number of new UI customization features. For one, every rollout in the Krakatoa Floater can be hidden if not needed or used rarely. This can be done in three different ways – right-click the []> icon in the upper right corner of the rollout and select “Hide Rollout” from the context menu; Hold down Ctrl and left-click the same icon to hide the rollout; open the Manage Rollouts rollout (which is the only rollout that cannot be hidden), select one or more rollouts from the right list and move them to the left list to hide.

In addition to hiding rollout, Krakatoa 1.5.0 also lets you float any of the rollouts (again with exception of the Manage Rollout one) as an independent dialog. These dialogs can be arranged freely anywhere on the desktop or minimized independently from the Primary Floater. To float a rollout, either left-click the []> icon in the upper right corner of the rollout, right-click the same icon and select Float Rollout from the content menu, or use the Manage Rollouts rollout – select one or more rollouts in either list and use the corresponding “Float” button. The position of each floated rollout will be stored and reused next time you float it.

In order to provide a kind of two-column layout of the Krakatoa GUI, v.1.5.0 also introduces a Secondary Floater which can be used to place any rollouts into. The Secondary Floater can be linked to the Primary floater - right-click the []> icon and use the last option in the context menu to control this behavior. When enabled (default), the Secondary Floater will stick to the Primary one whenever the latter is being moved around the desktop. At the same time, you can move or minimize the Secondary Floater independently. If the Primary Floater is moved and the Secondary Floater is not minimized, the latter will automatically snap back to the right of the Primary Floater. The Secondary Floater will only be visible if at least one rollout has been placed in it. To move a rollout from the Primary Floater into the Secondary floater, hold down the SHIFT key and left-click the []> icon; right-click the same icon and select “Dock To Secondary Floater” or use the “Dock” button in the Manage Rollouts rollout.

The Manage Rollouts rollout lets you quickly select all rollouts with a given state using the [D]. [S] and [F] buttons (Docked, Secondary, Floating) and change the state of all selected rollouts at once. The location of the rollout (left or right list) defines the hidden/visible state. All these settings can be saved and restored using the controls on top of the rollout. This lets you specify combinations of rollouts used for specific tasks like Rendering, Saving and Partitioning Particles, Managing Particle Systems etc. which keeping rollouts that are rarely needed hidden to reduce clutter. For example, if you never need the Notes and About rollouts, you can hide them in all your preset configurations.

The last configuration of your rollouts and floaters will be stored automatically and restored next time you launch Krakatoa even if you have not saved it explicitly as a Preset. Also note that UI Presets are now stored in a centralized location under your account’s Local Settings, allowing you to reuse the same Presets in all versions of 3ds Max you have installed Krakatoa v1.5.0 into.

Fast Rollout Navigation

From the years of practical use of Krakatoa and Beta Site polls, it became obvious that some rollouts were used more often than others and that some important controls like the >Use Matte Objects or >Save Attenuation Maps were “burried” deep in far away rollouts and difficult to reach/keep track of.

To partially solve this problem, several important options found in other rollouts are now duplicated at the bottom of the Main Controls rollout. These include the four new Shader Override options (Color, Emission, Absorption and Density) currently found in the Global Render Values rollout, the >Use Matte Objects, > Multiple Matte Layers, >Use APME and >Save Attenuation Maps checkbuttons. Checking these options is identical to checking their counterparts in the corresponding rollouts. If you need to tweak detailed settings, these checkbuttons double-serve as quick links – right-clicking any of them will expand the matching rollout, for example right-clicking >Use Matte Objects will focus the UI at the Matte Objects rollout. If the rollout has been hidden, it will be unhidden. If it was docked to the Secondary Floater or floated, it will appear wherever it was left the last time. Note that the former “Open Online Help” button has been split into two buttons, with the larger portion now called “Back to Main Controls”. Pressing this button will close the current rollout and focus the UI at the Main Controls rollout, providing a very quick workflow for tweaking settings while working with the main area of the Krakatoa GUI. Just right-click one of the 8 buttons at the bottom of the Main Controls, change settings in the corresponding rollout and hit the Back To Main Controls button to return.

Local Rollout Presets Saving and Loading

In addition to the global Presets controls that have always existed in the Presets and History rollout, Krakatoa v.1.5.0 introduces a Save/Load Preset button in the upper left corner of almost every rollout (to the left of the Open Online Help button). Clicking this button opens a context menu which allows you to save and load settings of only this rollout, as well as access all global Preset loading and saving features of the Presets and History rollout. The local options simply uncheck all other rollouts except for the one the feature has been called from, but still allow you to enable any of the other rollouts for saving if desired.

A Tale Of Two Renderers

The first commercial version of Krakatoa was described as a Volumetric Particle Renderer. Some people assumed incorrectly that it was voxel-based while it was technically a Point Renderer. Krakatoa v1.5.0 introduces two separate rendering modes – Particle Rendering and Voxel Rendering. They support similar feature sets but have unique Pros and Cons. It is up to the user to decide which method to use depending on the task at hand.

The Point-based Particle Renderer is faster and can represent particles with very high quality down to the last point, but when the camera is moving through the particle cloud, the particles remain pixel-sized and do not cover a larger volume. In other words, it is perfect for particle-based phenomena like dust and sand, but fail for dense clouds like smoke and vapour in close ups. The Voxel Renderer also uses particle data as the input, but encodes the particles on a grid and fills complete volumes with the accumulated density, color and other data values. Thus it can represent detail only down to the single voxel size which is specified in World Units, but when the camera is moving through such a cloud, it will appear dense regardless of the proximity. This approach is great for effects like smoke, clouds and vapour but would not be very suited for particle-based phenomena like sand and silt. The Voxel Renderer requires at least one light in order to be able to produce a result and does not support Omni lights and Spherical cameras.

Since the Voxel Renderer is one of the main new features in Krakatoa v1.5.0, let’s take a closer look at its controls and way of working.

To enable Voxel rendering, use the drop-down list in the upper left corner of the Main Controls rollout. A color swatch in front of the list gives a sub-conscious hint of the current mode – White stands for Particles, Blue for Voxels. Two new spinners become available – Voxel Size and Filter Radius.

The Voxel Size value defines the size in world units of the spatial box that will be rendered to represent a portion of 3D space filled with particles. The smaller the value, the closer the results will be to the Point-based Particle Rendering, but at a cost of speed. The voxel size is fixed within the rendering and should be selected depending on the scale of the scene, the distance from the camera to the particle clouds and the desired detail level.

The Filter Radius value controls the number of neighbor voxels to be considered when shading a single voxel. Krakatoa will interpolate over multiple voxels, resulting in blurred edges and larger more diffuse “voxel particles”. Of course, higher values result in longer renders.

New Shading Features

Both render modes provide more advanced shading options. In Krakatoa 1.1.x, the light attenuation was performed uniformly in R,G, and B always resulting in gray or black shadows. Krakatoa 1.5.0 introduces an Absorption channel which is similar to a Filter color and defines how the R,G and B components of light will be affected when passing through a dense volume of particles. The Absorption value can be specified not only globally, but also per particle, allowing for varying absorption within a volume defined by texture maps, materials or custom channel data. Similarly, each particle can now provide a self-illumination value (Emission Channel) and render as illuminated even if not lit by a light. If a particle provides no Scattering and Absorption but full Emission, it will effectively appear as Additive, which allows the mixing of additive and volumetric rendering within the same image, for example for the visualization of fire and smoke without additional compositing tricks.

Both rendering modes support various light scattering (phase) functions. In addition to the Isotropic and Phong Surface scattering (then called >Use Normals) in v1.1.x, the new Krakatoa version also provides Henyey-Greenstein and Schlick phase functions that vary the light scattering effect based on the viewing angle.

Environment Reflection Maps Support

Krakatoa v1.5.0 now supports maps applied to the environment slot of 3ds Max as an additional light source. The particles must provide a valid Normals channel for this feature to function correctly. When rendering in Voxel mode, the Reflections will be calculated in a second, camera-based pass.

Faster and Better Matte Objects

Matte Objects performance in previous versions of Krakatoa was arguably the weakest point of the whole system. There were two modes – one that performed brute-force raytracing of every particle against a kd-tree representation of the matte geometry, and the default option which generated a depth map by tracing a ray through every pixel of the output image and then performed a depth check against the resulting depth map for every particle.

Krakatoa v1.5.0 removes both these options in favour of a completely new geometry rasterizer which performs the depth map generation similarly to regular scanline renderers. This results in a vastly better performance, up to several orders of magnitude faster than the old methods. Using multi-million polygon matte objects is now completely feasible. In addition, the new Matte Objects rendering supports opacity-mapped objects, anti-aliasing and the output to two layers for better compositing of particles in front and behind semi-transparent occluding geometry. Typically, opacity-mapped geometry would use a black and white map to define the visible and invisible portions of the object. Particles in front of the object would be fully rendered and particles behind the opaque portions would be completely skipped. But in the cases where a particle is semi-visible either because the anti-aliasing has determined that it is partially occluded by solid geometry or because the opacity map is semi-transparent, particles in front of the matte object would be output to a foreground image while particles behind the semi-transparent opacity mapped object would be split into a background image. Sandwiching the solid geometry rendering between these two images will produce correct results since the background layer would be overlaid by the semi-transparent portions of the matte object rendering while the foreground image would be composited over the matte object rendering as expected. Currently only two layers are supported since most 3D renderers don’t provide useful output for compositing of more layers except possibly the Real Pixel Format of 3ds Max/Combustion.

Deformation Motion Blur

In previous versions of Krakatoa, the native Motion Blur mode only supported particle velocities and matte object position, rotation and scale animation. The “>Deformation Motion Blur” checkbutton has always been there in the UI but used to be disabled. Now in v1.5.0, animation of matte objects caused by deformation modifiers or vertex animation is also supported. The Matte Geometry kd-tree will be updated on every substep, but since Matte Objects rasterization has been sped up significantly, the overall performance is not affected much.

When using Krakatoa’s native Motion Blur in Voxel Mode, light transformations (moving lights) will be sub-sampled. When rendering in Particle mode, the lighting will only be sampled at the center of the interval. The 3ds Max Multi-Pass Motion Blur could be used to perform correct light motion blur at the cost of reloading and relighting the particles for each pass.

Iterative Mode Scale Output Feature

The existing Iterative mode has been enhanced to provide optional scaling of the output image to quickly produce a 2x blowup or 1/2, 1/4, 1/8 or 1/16 of the final output size when using the Render button in the Krakatoa Main Controls rollout or the VFB Extension in 3ds Max 2009 and higher. In addition to scaling the output up or down, Krakatoa will also adjust the density proportionally, producing a final output that is very close to the actual density at full resolution.

Ignore Missing Particles Option

Krakatoa v1.5.0 adds a global override to Ignore Missing Particles from PRT Loaders. This is useful when test-rendering using PRT sequences that are currently being generated on the network and might be missing some of the partitions or single frames. When enabled, missing PRT files will be assumed empty and the scene will render without them instead of throwing an error message. The option is sticky so it allows the network rendering in this special mode, but the checkbutton appears in red to make it very obvious and avoid surprises during production.

New PCache Default Behavior In Network Mode

Krakatoa v1.5.0 changes the default behavior of the PCache when network rendering. By default, the PCache will be disabled while rendering in slave mode. This was requested by users to avoid errors during production where a scene would be sent to the network with the PCache checked by accident, resulting in static particles within a slave’s tasks. An option to modify this behavior for the current scene only (non-sticky between scenes or Max sessions, only sticky to the current file) has been added to the RENDER button's Right-Click Menu. It achieves the old behavior in the rare cases it is needed – for example to render a static particle cloud with optional static lighting through a moving camera on a single machine.

Filling Geometry Volumes With Particles

In the past, creating a particle cloud required the use of a dedicated particle system like Particle Flow, Legacy Particles or at least the vertices of a geometry object. Creating a solid volume of particles often involved the saving of a regular cloud (for example box-shaped) and cutting out a complex shape out of it using the PRT Loader’s culling feature, or filling the volume directly in Particle Flow which is a rather slow process, especially with complex multi-million polygon models. Krakatoa v1.5.0 introduces a new dedicated PRT Volume object which can fill the volume of arbitrary geometry objects with particles. The geometry doesn’t even have to be fully closed, for example a teapot is far from being fully closed, and even slicing it horizontally with a Slice modifier to remove half of it does not affect the PRT Volume processing. Even a plane produces usable particle clouds.

The PRT Volume uses level set technology borrowed from the Flood fluid simulator which can convert geometry objects into level sets. The Voxel Size value in the PRT Volume defines the size of the voxels to generate. Then each voxel is filled with exactly one particle which also acquires some properties from the closest surface point including surface normal and texture coordinates. The particle is only created if it is inside the surface. The distance to the closest surface point is encoded into the SignedDistance channel which provides a value with a negative sign for particles inside the volume.

The particle count can be reduced for viewport display – by default, each PRT Volume is set to a limit of 1 million particles in the viewport, and the count can be further reduced using a Percentage spinner to show only every Nth particle. Instead of filling the whole volume of an object, the PRT Volume can optionally fill only a band with a starting distance from the surface and a given thickness. For example, when the Shell feature is enabled and the Start value is 0.0 and Thickness is 1.0, only voxels between the surface and one unit below the surface will be filled with particles. Both Start and Thickness are animatable, allowing for animated growth and reveal effects.

Since the voxels define a thee-dimensional grid, all particles are placed at identical intervals along the X, Y and Z local axes of the filled object. To add randomness to their positions, you can use a high-frequency Noise Modifier. Since the Noise modifier provides a Seed parameter, PRT Volumes can be effectively partitioned – a new option to affect Seeds of modifiers applied to PRT Volumes was added to the Partitioning rollout.

Particle Channels Editing – A Whole New World Of Possibilities

Earlier versions of Krakatoa allowed the user to save and load particle channels provided by Particle Flow, Thinking Particles, Legacy Particles and Meshes – these included Position, Velocity, Color, Density, Normals etc. In v.1.5.0, the ability to modify these channels or even create new channels using the existing ones, mathematical operations, texture maps and more has been introduced through the addition of a powerful node-based editor called "MagmaFlow". Magma Flows can be applied directly to PRT Loaders and PRT Volumes to modify particle data of specific objects, or globally to any particles regardless of their source via the Global Channel Overrides exposed in the Global Render Values rollout of the Krakatoa GUI.

A MagmaFlow "lives" inside a dedicated Krakatoa Channels Modifier (short: KCM).

A MagmaFlow has exactly one Output node which cannot be removed and which defines the Channel that will be modified. The Output node has only one Input Socket and can be connected to exactly one other node.

An arbitrary number of KCMs can be added to the modifier stack of the same object and can pass data up the stack as well as respect data modified by other modifiers (for example Position and Normals Channel data modified by deformation modifiers below the KCM). A KCM must also contain at least one Input node which defines the source data that flows through the modifier. An Input node has exactly one Output Socket and no Input Sockets. One of the simplest examples of a functioning MagmaFlow would be a flow with one Input node whose output socket is connected to the input socket of an Output node. The Input is set to Normals Channel and the Output is set to Color Channel. The result would be all particles colorized based on the direction of their normals.

The default MagmaFlow of a newly created KCM features simply a Color Channel Input connected to a Color Channel Output. This passes through the original color data without modifying it, while giving a good starting point for more complex flows.

A KCM can contain more than one Input node. In that case, the inputs must be connected via a third type of node – the Operator. An Operator always has at least one input socket and exactly one output socket and performs certain mathematical, conversion, logical or transformation operations onto the passing particles. For combining two Input nodes, an Operator with two input sockets like Addition, Subtraction, Multiplication etc. would be required.

To add a KCM, either select a PRT Loader or PRT Volume and select the Krakatoa Channels modifier from the modifiers list, or select one or more objects and use the dedicated KCM MacroScript provided in the Krakatoa category of the Customize User Interface dialog on 3ds Max.

To edit the flow, hit the Open MagmaFlow Editor button in the KCM’s UI. The MagmaFlow editor uses the Helium schematic control developed by Kees Rijnen of Lumonix.net. The editor implements several conventions found in other similar environments including Eyeon Fusion, Particle Flow Box #3 and Thinking Particles and might feel familiar from the beginning. The MagmaFlow editor was designed to be operated very quickly either with keyboard shortcuts or through drag&drop from the nodes Depot. To reduce the time spent connecting nodes, MagmaFlow makes several assumptions about default connections when creating a new node with one or more nodes already selected in the editor. For example, if an Input node that is connected to another node is selected when an Operator is created, the new node will be inserted between the Input node and its previous upstream node. If an unconnected Input node is selected and another Input node is created, the new node will be added to the existing selection resulting in two Input nodes being selected. If a two-input Operator like Addition would be created with these two Input nodes already selected, both nodes will be automatically connected to the two inputs of the new Operator and so on. In many cases, it is possible to create a whole flow without the need to connect nodes at all.

Flows can be saved to disk and loaded for later use. The KCM provides a drop-down list with all saved flows for quick access in addition to the File>Open menu item in the editor itself.

The MagmaFlow Operators are generally low-level basic building blocks. You can combine them into complex systems and save these are so-called BlackOps (or BLOPs) compound operators that can be dropped like regular operators into any flow. Once inserted into a flow, BLOPs become independent of their disk source and can be further edited to match the current needs, saved to disk again, replaced from disk etc. A BLOP can expose an arbitrary number of input sockets which can be renamed, reordered, added and removed as needed. MagmaFlow provides UNLIMITED Undo within the current modifier’s editing session (from opening the editor to closing it or switching to another modifier). Virtually all operations including node creating, selection, connecting nodes, editing properties etc. are recorded and undoable. The Undo buffer can also be saved to disk as a MacroRecording - a form of an interactive presentation that performs all steps saved in the buffer to demonstrate new concepts and flow designs to others. A saved MacroRecording can be edited, commented and retimed via a dedicated presentation editor at any point later on.

MagmaFlow is fully multi-threaded and scales well with large number of operators and particles. Typical speed for an average shading flow running on an 8 core 64 bit machine is about 10 million particles per second. This means that the results of the processing can be seen in real time in the viewports and remove the need for often re-rendering of the full scene.

The values of the Float, Vector and Integer Input nodes can be keyframed or connected to parameters of other scene objects, but this information is not saved and loaded with the MagmaFlow file, only with the MAX scene file. These controls can also be exposed to the UI of the host KCM for faster access by artists without the need to open the MagmaFlow Editor.

Keep in mind that MagmaFlow is not another particle system editor like Particle Flow Box #3 or Thinking Particles. MagmaFlow only operates on existing particle data within the current frame and cannot control particle behavior, process particles in history-dependent manner or implement general rules. It is closer to a kind of a visual shading editor and post-processing suite for massaging existing data channels. Since it is typically used with pre-saved particles from PRT files, it expands the abilities of Krakatoa to deal with particle caches and create new looks and effects without recalculating a complete particle system again and again. Thanks to the full access to the channels like Position, Velocity and Normals within the current frame though this kind of data can be modified to achieve displacement and push effects or even completely rearrange the particle cloud by setting new Position values.

The MagmaFlow Editor provides some basic debugging functionality. Errors, mostly due to incorrectly connected nodes, will be reported and highlighted in the Editor. In addition, the user can switch the flow into a special Debug mode and specify manually test values for all Input nodes – the results in all Operator nodes as well as the final Output value will be displayed in the Editor. At this point, it is not possible to see live data from the actual particle system being modified.

Global Overrides

During the development process of Krakatoa v1.5.0, some exciting new capabilities to modify channel data in every particle were added via the MagamFlow Editor, which prompted the development team to temporarily remove the Color Override option found in the previous version. The negative reaction from the Beta testers was so strong that the Override feature not only had to be returned, but it was also significantly expanded to provide the simplest workflow possible without sacrificing flexibility.

In the new Global Render Values rollout, you will find four new Override options – one for each of the four main Shading Channels – Color (Scatter), Emission, Absorption and Density. Each provides a fixed color value and an optional texture map slot with the ability to blend the two using a Percentage spinner. As mentioned already, the enable checkboxes of these Overrides are exposed at the bottom of the Main Controls rollout. The Overrides are applied to all particles after they have been loaded, overwriting any data provided by one of the various other means including Global Channel Modifiers, Materials and PRT file data.

One step below the Global Shading Overrides are the Global Channel Overrides. They have lower priority than the above-mentioned overrides and are based on KCMs running MagmaFlows over all scene particles in world space after they have been loaded. The implementation features simple holder objects that can have one or more KCMs on their modifier stack. These holders appear as “Global Override Sets” in the UI. Only one (or none) can be active at any given time, but any number of such sets/holders can exist in the scene, letting the artist quickly switch between them to test out various looks without losing previous attempts. The Global Values Rollout controls provide full access to the modifier stacks of all data holders and let you toggle modifiers on/off, add new modifiers, remove modifiers, edit modifiers’ flows by double-clicking them on the list and so on.

Channel Defaults

In previous versions of Krakatoa, some particle data like the Glossiness and Specular Level were available only globally for the whole scene. Now, these values can be specified either globally without using additional memory, globally by allocating a modifiable channel with a default value, or per particle. Other than Global Overrides which specify the final value to be used by the renderer, these Channel Defaults define a starting value to be either used by the renderer or modified by MagmaFlows.

Currently there are three shading channels that support this new approach: SpecularPower (also known as Glossiness), SpecularLevel and Eccentricity (Phase Eccentricity). The former two are available when the scatter mode is set to Phong Surface, the latter is available in the Henyey-Greenstein and Schlick modes. By default, a default value will be specified but no channel will be allocated for the data, causing particles to use the value explicitly without using up any memory for it. This is similar to the way Krakatoa 1.1.x worked. When the corresponding >Allocate option is checked, a dedicated channel will be allocated for each particle. The channel will be initialized to the default value and if not modified underway by local or global KCMs, it will be used as is by the renderer. A KCM can either read and modify the value or overwrite it with a completely different value, for example based on a texture map or some mathematical function. In that case, every particle will have its own value for this property, allowing for complex effects like varying phase eccentricity within a volume or changing the specular properties of surfaces and volumes.

Enhanced Material Support

Krakatoa v1.5.0 adds a new dedicated Krakatoa Material which provides ONLY the few relevant controls - Scatter (Diffuse) color, Emission color, Absorption color and Density, all with Map support and Multiplier spinners. This material uses simple internal MagmaFlows under the hood to set the corresponding channels of the particles. This makes the modifying of shader-related channels more straight-forward as it removes the need to set up multiple Krakatoa Channel Modifiers for every object that needs them.

The support for the Standard Material has been enhanced with the ability to acquire the Emission (Self Illumination Color) and Absorption (White minus Filter Color) as well as SpecularPower and SpecularLevel data per particle in addition to the already supported Scatter (Diffuse) color and Density (Opacity Map) scaling.

3ds Max Falloff Map Support

Kraktoa v1.5.0 now fully supports the 3ds Max Falloff Map including the Fresnel Mode, the Object-based modes (Distance Blend with Object Falloff) etc. The Normal channel must be present for most Falloff modes like Fresnel to work correctly. The Falloff Map can also be used correctly in KCM MagmaFlows. Since the local object KCMs operate in Object space, an Object-based Distance Falloff would measure the distance relatively to the world origin and not relatively to the object. This can be overcome by using the Falloff map in a Global KCM since it operates in world space.

User-Defined Channels Saving

Previous versions of Krakatoa provided a hard-coded list of channel names supported for saving to PRT file sequences. With the addition of the MagmaFlow / KCMs which let the user define arbitrary channels to store arbitrary data in one of the supported formats, the Save Particles rollout had to be expanded to provide means for adding User-Defined channels to the list of channels to save. These new channels will be saved to an INI file and will also appear on the list of pre-defined Channel names in the MagmaFlow editor.

Lighting Channel Saving And Relighting

Krakatoa v1.5.0 provides the ability to save the content of the Lighting channel normally used by the renderer to store the illumination data per particle resulting of the calculation of all lights in the scene. When Krakatoa is switched to Save Particles To Disk mode and the option to copy the Lighting channel into the Emission channel is enabled, the particles will not be dumped to disk in the order of loading but will be sorted against each light and illuminated first. As result, the order of particles in the PRT file will be the order relatively to the last processed light.

As a side effect, if you want to sort the particles relatively to the Camera or View, you could align and parent a spotlight to the Camera, enable the Lighting channel saving as Emission option and generate your PRT files – the order will be relatively to the Light and since it was aligned and parented to the camera, the order will be also in camera space. The Emission channel can be rendered directly by enabling >Use Emission or accessed and modified in MagmaFlows to perform particle relighting without the use of scene lights.

Once the Lighting is saved as Emission, particles can be rendered in a fraction of the original time, completely skipping the Lighting Pass. The saved lighting information can also be manipulated interactively using Krakatoa Channels Modifiers implementing various color correction and light manipulation MagmaFlows.

Partitioning Improvements

Krakatoa will now check for used Map Channels in Particle Flow operators before partitioning. It will scan for Mapping operators, Box #1 Mapping_Object operators and Output_Standard sub-operators in Box #3 Data Operators and collect their Mapping channels. Then it will check whether these mapping channels have been specified for saving in the Channels rollout and warn the user if they are not. The user can pick to add these channels automatically, ignore the warning or cancel the Partitioning before it starts and fix the problem manually. This check does NOT apply to other types of objects like Mesh Vertices.

In addition, the partitioning of PRT Volumes with Noise (or similar) modifiers applied that provide a Random Seed value is now supported. The Partitioning rollout implements a separate switch for toggling PRT Volumes seed changing on and off.

Presets and History Enhancements

Some small changes have been made to the Presets and History rollout and its functionality.

The filter fields now provide [>>] options buttons displaying a menu that allows the name of the current preset or the name of the current MAX file to be added to the filter field or to be removed from there.

The History records now contain the version number of both Krakatoa and 3ds Max, as well as the number of particles in memory and the RAM used at the end of rendering based on the PCache stats.

The History and thumbnail files will now be stored at a central location in the User's Local Settings. This means that all records will be shared by all versions of 3ds Max installed on that particular machine.

The History and the Presets lists now use separate caching – if one of the caches is outdated, the other does not have to be rebuilt anymore, resulting in some speed up in cache processing.

PRT Loader Changes

The PRT Loader now provides two modes for the start and end behavior of particle sequences when using Custom Range. In addition to the old method which would hold the first or last frame when the time was outside of the range, you can now request no particles to be loaded.

The former Edit… button has been replaced with an options [>>] button which provides a menu with several options to select sequences and populate the list from the Saving Particles and/or Partition rollouts without picking files from disk, as well as the option to copy selected paths to the Windows Clipboard.

Another options [>>] button has been added to the Playback Graph controls. It provides some useful keyframe presets including Linear, Acceleration, Deceleration and Ping-Pong curves and the abilities to invert or delete all keys in the current time segment.

The controls to replace the content of the Density channel with 1.0 and to copy the Density channel into a specified Mapping Channel have been removed since they (and a lot more) can now be implemented using KCMs and MagmaFlows.

A new option has been added to the Viewport controls to ignore the assigned Material when displaying the particles in the viewport. This is useful when a material is assigned to the PRT Loader but a KCM is used to visualize channels and results in the Color channel. When a Material is assigned to a PRT Loader, it will ALWAYS override the Color, Emission and Absorption settings that might have come from a saved PRT file or KCM on the stack. You can use a Vertex Color Map to pass through these shading channels into the Material though.

Particle Culling Improvements

Krakatoa v1.5.0 improves the precision of the inside/outside check for particles relative to geometry volumes, giving better results in some special cases where the particle happened to be in the same plane as some of the faces to check against. The new code might perform some additional tests in these cases, but since the process has been multi-threaded (testing multiple particles in parallel), the overall culling speed is still higher than in previous versions.

The User Interface implementation of the Culling feature in the PRT Loader has been improved since it was misleading in previous versions – many users believed that only one object could be specified as culling volume. Instead of a pick button selecting a single object to add to a Named Selection Set with the same name, the button now opens a Select By Name dialog which allows the user to multi-pick any number of objects to be used as culling volumes. The resulting Named Selection Set will have the name of the first object picked followed by the number of additional objects in brackets, for example “Sphere01(+2)”. When no Named Selection Set is specified, the list will show the more descriptive text “No Culling Named Sel.Set”.

Advanced Particle Deformations - Particle Skinning

In previous versions of Krakatoa, all gizmo-based modifiers including Bend, Twist, PathDeform and FFD were supported, but the most advanced deformation modifier, Skin, not only did not work but could crash the system if added to a PRT Loader. In v1.5.0, a new Krakatoa Skin Wrap World Space Modifier (KSW) allows the deformation of particles or other meshes using arbitrary deforming geometry, thus indirectly allowing skinned characters to be filled with particles and the particles to follow all deformations of the original skin mesh.

Other than the SkinWrap modifier shipping with 3ds Max which performs a long initialization process and does not allow topology changes of the deformed object, the Krakatoa Skin Wrap calculates all relationships dynamically and on the fly and can thus deform point clouds or meshes with changing count from frame to frame as long as the source deforming mesh has consistent topology. The Krakatoa Skin Wrap lets you specify a Base Frame taken as the time to initialize the influences of the source geometry on every particle or vertex to be deformed. Then on following frames the influences are applied and the particles or vertices are moved to new positions while preserving the same relationships to the surrounding faces as on the Base frame.

There are two influence modes – by distance and by face count. In the former case, the distance of the particle to the closest face is determined first and then the influence of all faces within that distance multiplied by a factor (default is 1.5) are taken into account, affecting the point proportionally to their distance to it. Obviously, if a particle is deep in the middle of a volume, a large number of faces will be found to potentially affect it, resulting in slower calculations. The second approach defines the number of closest faces to be taken into account – the default is 4, but could be set to 1 to perform so-called “rigid deformations” where each particle picks the closest face only and follows it. This is recommended for testing as it speeds up the process significantly. Some more parameters control the falloff and the tessellation of the source geometry.

As mentioned already, the Krakatoa Skin Wrap can also be applied to regular meshes as a replacement/alternative to the built-in SkinWrap modifier, especially when driving an object with topology that changes over time.

Note that the teapot primitive has some invalid faces in its default form and is a bad test case for the Krakatoa Skin Wrap – it will generate errors if used with it. If you have to use the teapot, be sure to add a Cap Holes modifier on top of it to cure its problems and make it usable with the KSW.

Better Krakatoa Particle Flow Operators

Krakatoa v1.5.0 adds some new dedicated and general-purpose Particle Flow operators.

The new Krakatoa PRT Loader Birth and Krakatoa PRT Loader Update operators are meant as a replacement of the Krakatoa File Birth and Krakatoa File Update operators from previous versions. Instead of selecting files from disk, the new operators let you pick an existing PRT Loader in the scene as the source of particles, timing etc. All settings including Playback Graph timing, render percentage, deformations, culling, as well as Channel Modifiers are taken into account, providing more flexibility than before.

In addition, these new operators support the Particle Flow Viewport multiplier. This makes it possible to preview fractions of the particles without clogging Particle Flow with many millions of particles that can slow it down to a crawl.

A new bonus Krakatoa Collision Test operator based on the same kd-tree acceleration structures used by the Krakatoa Geometry Test, Krakatoa Geometry Lookup and the PRT Loader’s Culling code provides significantly better performance when testing million particles against millions of polygons. In fact, it can be up to 2500 times faster than the Particle Flow Collision operator with a UDeflector.

Creating PRT Files Using MAXScript

Krakatoa v1.5.0 exposes a MAXScript Interface for creating a PRT file stream with arbitrary named channels and outputting particle data to it. This opens the door for some amazing new scripted tools where particle clouds could be generated procedurally based on mathematical functions, scene geometry or other systems like the Hair&Fur modifier of 3ds Max. Several example scripts ship with the product to showcase these abilities.

Thinking Particles Support

Krakatoa v1.5.0 supports the Beta version of Thinking Particles 4 in addition to TP 3 and 2.5.

In addition, any named Data Channel defined in a TP Group that has a type of Float, Int, Point3 or Color can now be saved to PRT if the same name and type is defined as Custom Channel definition in the Channels rollout of Krakatoa. If the channel name matches the Shading Channels of Krakatoa like Emission, Absorption, Eccentricity, SpecularPower and SpecularLevel, the Data Channels will also be seen by the renderer.

Rendering FumeFX Simulations

Krakatoa v1.5.0 adds the ability to convert every populated voxel of a FumeFX simulation to a particle (similar to the way FumeFX previews its data in the viewport) and render these particles as either points or voxels using a fraction of the memory the 3ds Max Scanline renderer or 3rd party renderers would require. During the production of a major motion picture a very long missile trail produced with FumeFX turned out to require about 64GB of RAM to render successfully in a raytracer – the size of the voxel grid was too large to accommodate all the necessary motion although most voxels were empty. In contrast, the Krakatoa Voxel rendering of the same data required less than 600MB per frame due to the fact that Krakatoa processes only one 2D slice of the grid at a time and does not have to keep all voxels in memory.

Krakatoa will load and can save most FumeFX channels like Smoke, Fuel and Fire. They can be processed using MagmaFlows to control the final shading.

Last But Not Least – Performance And Stability

Since the beginning of the v1.5.0 development , improving performance through multi-threading and code optimizations has been one of the main priorities. Various areas of the program now take advantage of modern multi-core CPUs. These include particle loading, material evaluation, particle culling, KCM evaluation, particle sorting (which was multithreaded in previous versions already) and voxel rendering. The only major area that could benefit from parallelization but has not been improved yet is the particle drawing.

PRT Loading Benchmark

For example, here is a simple benchmark comparison between Krakatoa 1.1.3.36616 (1.1.2 recompiled with Max 2010 support) and Krakatoa v1.4.8.36774 (RC1). 10 million particles in the shape of a cube had to be loaded and rendered with one spot light in Particle mode in 3ds Max 2008 64 bit running on an 8 Core Intel Xeon E5420 2.5GHz with 16 GB of RAM. YMMV.

Standard Material and Maps Shading

	1.1.3.36616		1.4.8.36774
	Loading Time	Total Time	Loading Time	Total Time	Loading Speedup	Total Speedup
No Material	4.668	21.015	4.282	22.937	1.09	0.92
Standard, Opacity Cellular Map	25.953	42.203	6.360	25.078	4.08	1.68
Standard, Diffuse and Opacity	26.031	42.515	7.375	26.188	3.53	1.62

In short, on this particular machine the new Krakatoa version will finish rendering 10M particles with two Cellular Maps in the same time the old version would finish loading them. Tests with 4 core machines show that they provide similar speedup since the bottleneck is now the loading and unzipping of the particle stream.

 

Particle Culling

The following benchmark used the same 10M particles as in the previous example but culled by a Geosphere with diameter approximately equal to the side of the particle box, resulting in 3.861M particles:

	1.1.3.36616		1.4.8.36774
	Loading Time	Total Time	Loading Time	Total Time	Loading Speedup	Total Speedup
No Material	42.968	49.334	15.313	22.703	2.81	2.17
Standard, Diffuse and Opacity	53.016	59.328	16.735	24.109	3.17	2.46

Note that pure Particle drawing is slightly slower in v1.5.0 because of the added support for Absorption and Emission, but is more than compensated by the loading/shading/culling speedup in most cases.

Major Bug Fixes

Several important bug fixes have been rolled into the new Krakatoa version:

• When acquiring particles from heavy geometry vertices, the memory usage will be kept much lower than in previous versions. In the past, all meshes were kept in memory until all particles were acquired. Now every object is processed and its mesh released from memory before the next is processed.
• Particles from Vertices now correctly acquire the vertex normal for Phong shading and Environment Reflections.
• The creation of a PRT Loader used to cause an invalid Undo record which required the clearing of the Undo buffer when creating a PRT Loader to avoid a potential crash on undo. This has been fixed.
• Particles with invalid positions (usually at infinity) will now be skipped and not rendered. Such particles used to accumulate at the world origin, causing visual artifacts.
• Render Elements assigned to other renderers will be automatically removed when Krakatoa is assigned as the current renderer. In the past, these Render Elements would stay hidden in the background and produce undesired output files unsupported by Krakatoa.
• Rendering with the Hair Effect on the Effects List would cause a crash of 3ds Max. Krakatoa will now disable internally all effects (since they are not supported anyway) during rendering to prevent this.