What Was New in Krakatoa v1.6.0
For a detailed bullet list of changes, please see here.
Krakatoa v1.6.0 was initially planned as a minor point release under the version number 1.5.2, but sudden demand for additional features from the in-house production teams caused these plans to change dramatically.
Not all features developed in this cycle are included in the 1.6.0 release, some of them will need some more polishing before making it into a commercial version. Regardless, what is in final build is quite useful and should improve both existing workflows and performance and provide new tools in several areas.
In short, the major improvements in Krakatoa v1.6.0 can be grouped in the following categories:
- Increased Performance of particle loading, lighting, matting and rendering;
- New Shadow Generation Workflow introducing OpenEXR-based Deep Opacity Maps;
- Render Elements Support using the 3ds Max workflows;
- MagmaFlow improvements including new Surface Operators for geometry data lookup;
- New FumeFX direct rendering workflow via a dedicated PRT FumeFX object and FumeFX 2.0 support;
- Improved UI Startup Performance;
- Optimized User Interface Navigation;
- MAXScript Reading Access to Particle Data;
- Major Bug Fixes and
- Workflow improvements across the board.
The following topic provides a more detailed overview of the new features and changes introduced by Krakatoa v1.6.0:
Particle Mode Final Pass Drawing Performance
In previous releases, the drawing of particles to produce the final output image was single-threaded. On typical 2.5GHz CPUs, the drawing performance was measured at around 2 million particles per second (MP/s).
In Krakatoa v1.6.0, the final pass will use all available Cores, resulting in nearly linear speed up when rendering large enough particle clouds. For example, on a Dual Quad-Core Xeon E5420 2.5 GHz system with 16 GB of RAM, the drawing performance was measured at over 16 MP/s - the pure drawing of 100 million particles took slightly more than 6 seconds. Taking into account that the rest of the processing (loading, sorting, lighting) remain the same as in v1.5.1, the total render times can see a speedup between 1.3 and 1.8 times. With the PCache and LCache enabled, performing multiple iterations to tweak settings like Global Density, Motion Blur, View or Matte Objects placement is now many times faster. In fact, on an 8 Core system, rendering with 8 passes Motion Blur will now take about as long as without Motion Blur in the previous version!
Particle Mode Lighting Pass Performance
In previous releases, the generating of Attenuation data for particles self-shadowing and shadow casting from matte objects was also single-threaded, except for the particle sorting portion which has been multi-threaded since v1.1.0.
In Krakatoa v1.6.0, the lighting pass will use all available Cores, resulting in a significant speed increase, but generally less pronounced than the final pass improvements (usually 3 to 5 times on 8 cores). This is because the attenuation map generation has to be performed in two passes and not all of them can be performed in parallel. Still, in typical scenes with a lot of particles and multiple lights, this speed increase can reduce the total render time between two and three times.
The following table shows a benchmark using 10 PRT Loaders with 9.5MP each created from the Happy Buddha Statue using a PRT Volume saved to disk with only Position and Normal channels. The rendering mode was set to Particles and the Shader to Phong Surface. Rendered using 8 cores on a Dual Quad-Core Intel Xeon:
|v1.1.3, 10 PRT Loaders, 1 Spot, PCache OFF, 95MP||135.188s||30.688s||90.250s||32.375s||66.672s||360.907s|
|v1.5.1, 10 PRT Loaders, 1 Spot, PCache OFF, 95MP||138.922s||13.204s||81.218s||13.640s||77.594s||329.843s|
|v1.6.0, 10 PRT Loaders, 1 Spot, PCache OFF, 95MP||139.984s||13.313s||14.109s (5.75647x)||13.688s||12.844s (6.04126x)||197.968s (1.66614x)|
|v1.1.3, 10 PRT Loaders, 3 Spots, PCache OFF, 95MP||134.859s||107.047s||274.047s||48.172s||67.187s||637.219s|
|v1.5.1, 10 PRT Loaders, 3 Spots, PCache OFF, 95MP||138.172s||45.312s||243.047s||19.844s||77.328s||528.891s|
|v1.6.0, 10 PRT Loaders, 3 Spots, PCache OFF, 95MP||140.094s||43.921s||44.094s (5.51202x)||12.375s||12.625s (6.12499x)||257.282s (2.05569x)|
|v1.5.1, 10 PRT Loaders, 3 Spots, PCache ON, 95MP||N/A||44.437s||244.048s||12.890s||77.750s||383.031s|
|v1.6.0, 10 PRT Loaders, 3 Spots, PCache ON, 95MP||N/A||45.234s||43.172s (5.65292x)||13.297s||12.640s (6.15111x)||120.094s (3.18943x)|
As you can see, the lighting time is about 5.5 times faster, the drawing time over 6 times faster, and the total rendering time between 1.6 and 3 times faster depending on the settings.
Note that if the 95MP are created directly using a PRT Volume, v1.6.0 is 15 times faster thanks to the improved memory handling when loading unknown particle counts:
|v1.5.1, 10 PRT Volumes, 3 Spots, PCache OFF, 95MP||2765.25s||44.470s||243.108s||18.469s||77.343s||3169.2s|
|v1.6.0, 10 PRT Volumes, 3 Spots, PCache OFF, 95MP||96.469s (28.6646x)||40.859s||44.203s (5.49981x)||14.219s||12.437s (6.21878x)||212.312s (14.9271x)|
Matte Objects Depth Map Performance
The drawing of the Z-Depth map generated from matte objects by the Matte Objects Rasterizer introduced in v1.5.0 has been accelerated significantly by using all available CPUs/cores. Below is a benchmark using 50 million self-illuminated particles occluded by a grid of 100 teapots with 64 segments and one iteration Turbosmooth for a total face count of 104 million.
|v1.5.1, 1 PRT Loader, 50MP, 100M Triangles||21.719s||37.547s||8.250s||43.109s||112.609s|
|v1.6.0, 1 PRT Loader, 50MP, 100M Triangles||22.156s||8.219s (4.56832x)||7.890s||8.469s (5.09021x)||47.86s (2.35288x)|
Saving Particles Performance Improvements
Earlier versions of Krakatoa saved particles by requesting one particle at a time and passing it to the compression function to write to the PRT stream. This made the saving process practically single-threaded.
In order to improve the performance of the saving process, Krakatoa v1.6.0 will request a pool of 50,000 particles at once before saving them to the PRT file, thus allowing for parallel computing of mutli-threaded portions of the process. For example, particles assigned materials with procedural maps and complex Krakatoa Channels Modifiers can see a significant speed up from this change. The actual improvement will depend on the complexity of the performed operations - the heavier the shaders and KCMs, the faster the new version will save compared to previous builds.
|v1.5.1, PRT Volume, 10MP, No Material||37.547s|
|v1.6.0, PRT Volume, 10MP, No Material||35.031 (1.07182x)|
|v1.5.1, PRT Volume, 10MP, Standard Material, Cell Diffuse Map||55.00s|
|v1.6.0, PRT Volume, 10MP, Standard Material, Cell Diffuse Map||39.875s (1.37931x)|
|v1.5.1, PRT Volume, 10MP, Standard Material, Cell Diffuse and Opacity Maps||58.547s|
|v1.6.0, PRT Volume, 10MP, Standard Material, Cell Diffuse and Opacity Maps||38.422s (1.52379x)|
|v1.5.1, PRT Volume, 10MP, No Material, Bend Modifier||55.719s|
|v1.6.0, PRT Volume, 10MP, No Material, Bend Modifier||46.250s (1.20474)|
|v1.5.1, PRT Volume, 10MP, Standard Material, Cell Diffuse and Opacity Maps, Bend Modifier||81.469s|
|v1.6.0, PRT Volume, 10MP, Standard Material, Cell Diffuse and Opacity Maps, Bend Modifier||54.937 (1.48295x)|
|v1.5.1, PRT Volume, 10MP, Mo Material, Push Position Along Normal KCM||42.438s|
|v1.6.0, PRT Volume, 10MP, Mo Material, Push Position Along Normal KCM||37.469s (1.13262x)|
|v1.5.1, PRT Loader, 10MP, Mo Material, No Culling||22.547s|
|v1.6.0, PRT Loader, 10MP, Mo Material, No Culling||21.297s (1.05869x)|
|v1.5.1, PRT Loader, 10MP, Mo Material, Culling By Geosphere||48.109s|
|v1.6.0, PRT Loader, 10MP, Mo Material, Culling By Geosphere||14.859s (3.2377x)|
|v1.5.1, PRT Loader, 10MP, Standard Material, Cell Diffuse and Opacity Maps, Culling By Geosphere||59.578s|
|v1.6.0, PRT Loader, 10MP, Standard Material, Cell Diffuse and Opacity Maps, Culling By Geosphere||18.031 (3.3042x)|
As you can see from the above benchmarks, the culling of particles in the PRT Loader gets the strongest boost from the multi-threading improvements during the saving of particles, but adding more complex materials and shader trees, Krakatoa Channel Modifiers and deformation modifiers will also load the cores better and potentially increase the gap between v1.5.1 and v1.6.0...
PRT Volumes Performance Improvements
The Memory Management of Krakatoa v1.5.1 and earlier had issues with procedural particle sources like PRT Volume objects whose final particle count is unknown. This has been addressed in two ways:
On the one hand, the Memory Management has been improved to double the memory allocation when the current memory is not enough to fit all particles. The result is fewer memory allocations that adapt to the demands of the incoming particles, while providing a significant speed up. The drawback of this method is that the final memory usage could overshoot the actual memory needs significantly and that the doubling the memory causes short spikes of memory usage that can exceed the available memory in extreme cases.
The second improvement comes in the form of a user-defined minimum amount of particles to allocate memory for when the final count is unknown. In typical scenes where each particle source reports the correct particle count, memory will be allocated like before - just once and in the right amount. In scenes containing particle sources with unknown final particle count, Krakatoa will ask the source for an estimate. If the source cannot provide an estimate because it does not implement any estimation logic (as is currently the case with the PRT Volume), Krakatoa will query the user-defined Pre-Allocation particle count found in the Channels and Memory rollout and will allocate memory for the specified number of particles. If the pre-allocated memory is still not enough to accommodate all particles, the memory pool will be grown as needed like described above.
The results of these improvements are impressive to say the least. It now takes only 17.5 seconds to load 50 million particles from a PRT Volume vs. 11+ minutes in the old build. This is over 38 times faster and the speedup gets more pronounced as the particle count increases - loading 100 million particles is even faster - namely 92 times!
New Krakatoa Shadows Generator
The process of casting shadows from particles onto geometry in other renderers than Krakatoa has been arguably the weakest point of Krakatoa since its first release. Some of its biggest shortcomings were the fact it used Light Projection Maps to fake shadows, the inability to handle color shadows and volumetric attenuation correctly and the artifacts caused by the exclusion of Matte Objects from the shadow - depending on the map resolution, the shadow volume could spill onto the matte object, while the geometry and the particle shadows could show a gap between them.
The new approach does not fake shadows, it produces them according to the rules of 3ds Max shadow generators. It works with all 3ds Max lights that support 3ds Max shadow generators (this excludes VRay's own lights which do not support the 3ds Max shadow generators) in all renderers except for mental ray which requires a reimplementation of a mental ray shader for each shadow generator.
A new Krakatoa Shadows type will appear on the list of shadow generators in 3ds Max lights. It provides a filename field where the location of the attenuation map data can be specified, as well as some other settings like the shadow map size, the number of layers and the distance between the layers, and the shadow generator to use for Geometry-On-Geometry shadow casting.
When rendering in Krakatoa with >Save Attenuation Maps checked, the Attenuation Map data will be saved as Deep Opacity Maps in a layered OpenEXR file for each light and each frame of the animation. The Map can contain one or more depth and attenuation layers at a user-defined step to capture the attenuation within the volume when working with geometry intersecting with particle clouds.
When rendering the same lights in Scanline or VRay, the data from the Attenuation Maps will be read from disk and will be combined with the Geometry-On-Geometry shadow generator specified within the Krakatoa Shadows rollout. The combined shadows of the two generators will produce correct shadowing from both particles and geometry objects. The Krakatoa Shadows will respect the Absorption of light when using the Absorption channel in Krakatoa and will produce correct colored shadows from particles onto geometry.
To simplify the assignment of Krakatoa Shadows and the setting of the unique output paths for all lights, the Krakatoa Shadows On Geometry Utility has been replaced with a new Krakatoa Shadows Explorer Utility. The new tool provides a list of all supported lights in the scene together with their light and shadow casting status, the shadow type and, in the case of Krakatoa shadows, the secondary shadow type, samples, step, map size and shadow file name. The tool allows for quick switching of one or more lights' shadow generators to and from Krakatoa Shadows as well as the selecting of lights and the mass-adjusting of Krakatoa Shadows parameters.
Krakatoa Render Elements
In previous releases, Krakatoa could generate a limited number of special passes in addition to the regular RGB and Alpha output. In v1.1.x, two types of Z-Depth passes could be generated. In v1.5.x, the use of Global Channel Overrides opened a door to custom render output using the regular RGBA rendered image. This approach had several drawbacks - it required a separate rendering for each pass, the data that could be output had to be available to the renderer as a Memory Channel and some passes like Z-Depth required a drawing method different from the available pixel lookup methods.
Krakatoa 1.6.0 addresses these problems by adding support for the native 3ds Max Render Elements sub-system and implements multiple Krakatoa Render Element types. Using this system, particles can be loaded and illuminated just once and then multiple Render Element images can be drawn and saved in one go. Some of these Render Element types allow the output of data available only to the Renderer but not accessible through the Magma system - these include the output of the Matte ZDepth, Specific Light contribution, as well as internal Shader information like the Diffuse and Specular components of the Phong Surface shader.
A special CustomData Render Element type allows the creation of custom Render Elements using the MagmaFlow editor and the output of any channels available to Krakatoa to a color bitmap. Some typical Render Elements that could be implemented as CustomData ones have also been provided to speed up the process, including Normal, Tangent, Velocity and ZDepth.
A dedicated OccludedLayer Render Element replaces the previous built-in OpenEXR-only saving mechanism for particles found behind Matte Objects - when the >Save Multiple Layers option is checked in the Matte Objects rollout, this render element will be added automatically to produce the background layer and save it to any format supported by 3ds Max.
Krakatoa PRT Objects
Krakatoa PRT FumeFX Object
Similar to the PRT Volume object, the PRT FumeFX object can be used to convert a voxel grid to particles, but in this case the grid is taken from a FumeFX simulation. One or more particles can be created in a regular grid, jittered or randomly distributed in each voxel or sub-divided region. The object provides seeding thresholds for both Smoke and Fire channels and even allows the Emission channel to be populated directly based on the Fire channel. A usable Normal channel can be generated based on the Density Gradient for Phong Surface shading or other calculations involving particle normals. The PRT FumeFX accepts deformation and Krakatoa Channel modifiers, particle soft-selections and deleting particles using the Krakatoa Delete modifier. It can be transformed in the world and in general supports the same workflows as the PRT Volume object. In addition to FumeFX 1.2, the Krakatoa PRT FumeFX object now supports FumeFX 2.0.
Krakatoa PRT Volume Object
The existing Krakatoa PRT Volume object has been improved by adding a faster random distribution method and explicit controls over the Random Seeding (total number of random positions and a seed value). In addition, a context menu was added to the pick button to provide a large number of useful functions for selecting, hiding and controlling the display of the source object, renaming the PRT Volume based on the source's name, aligning and acquiring the material of the source object and so on. The Uset Interface was also redesigned to group related controls in separate rollouts and mimics closely the UI layout of the new PRT FumeFX object. Under the hood, both objects share significant amount of code.
Krakatoa PRT Source Object
The new Krakatoa PRT Source object is aimed at 3rd party developers who would like to take advantage of all typical Krakatoa PRT object features like deformation, selection, culling and Krakatoa Channels Modifier support without having to implement them in their own objects. The PRT Source object will search for implementation of the IMaxKrakatoaPRTSource interface (whose header file is publicly available) in a 3rd party loader object and will load its particles in the viewport and the renderer, while supporting all advanced features mentioned above.
Custom Viewport Display Channels
All three PRT objects (PRT Volume, PRT FumeFX and PRT Source) support a pair of data channels that can be populated using Krakatoa Channel Modifiers in order to control the color of the viewport particles or turn them from points into vectors. These channels are called PRTViewportColor and PRTViewportVector and are already available on the channels list of the Output node. The PRT Loader implements its own display mode controls and does not support these channels yet.
PRT Loader Object
The PRT Loader object now provides an option to preserve the Velocity information when the "Load Single Frame Only" option is selected. This is to allow Krakatoa Channels Modifiers to read and use the Velocity data from the single file to produce continuous motion along these velocity vectors as shown in this example.
On some very slow networks, or when the network is heavily overloaded in production, updating the particle count could take very long time. To avoid slowing down the whole scene, the "Particle Counts" rollout of the PRT Loader has been set to rolled up by default and will only update particle data if open.
When loading particles from the RealFlow .BIN format, they will be converted into 3ds Max Z-up space, eliminating the need for manual transformation to match the scene. Similarly, when saving particles to the RealFlow .BIN format, they will be automatically converted into RealFlow Y-up space.
Krakatoa Channels Modifiers and MagmaFlow
New MagmaFlow Nodes
A new category of Surface Operators has been introduced to MagmaFlow, together with a dedicated Input node for selecting geometry objects. The Surface Operators perform fast Nearest Point Lookup and Ray Intersection against arbitrary geometry objects using the Prime Focus kd-tree acceleration already employed by the PRT Loader culling and the PFlow Geometry, Lookup and Collision tests. Various values can be extracted from a single lookup operation, including the Point's Position, Normal, Validity, Mapping Coordinates, Barycentric Coordinates, Face Index, Material ID etc.
A number of additional Operators have been added to the MagmaFlow Editor. They include a dedicated SquareRoot Operator node which is faster than the Power Operator, several Quaternion Operators (ToQuat, FromQuat and TransformToQuat) for performing conversion of vectors into quaternions and back and the transformation of vectors and other quaternion values by a quaternion, a (Natural) Logarithm Operator, a Ceil Operator to complement the existing Floor one, an ATan2 Operator and a ToView operator which respects the current view transforms regardless of their source, specifically at render time. A couple of BlackOps were also introduced to implement operations like LogB and Log10.
The Keyboard shortcuts system has been expanded with a new Two-Stroke mode which provides a context menu at the first keystroke and an operator at the second. This allows for a much larger number of operators to be created via the keyboard than before. The first keystroke letters are also listed in the Depot as underscored characters, and the second letters are underscored in the menu. For example, hitting I (for Input Channels) and P will create a Position Channel Input node, while I+D will create an ID Channel Input node, F+N will make a Function>Noise operator and A+B will create an Arithmetic>Absolute operator and so on.
Custom Output Channels
The ability to fully specify the Type and Arity of custom Output channels in MagmaFlow has been implemented. If a standard channel is selected, only the data depth can be changed (type and arity will be preserved). Note that when an Input in KCM higher on the stack references that channel, the type of the channel will now be shown as [Custom] as it cannot be easily determined by the UI, but the compiler will handle it correctly.
The behavior of Input Nodes Drag&Drop was changed - when a new Input is dropped from the Depot using the mouse, the existing selection will be removed to allow the Input's Parameters to be displayed immediately. This does not apply to Keyboard creation where existing selections will be preserved to allow for faster flow auto-connecting.
A new Notes Input Node has been added. It can be used for adding general notes that are visible without having to select anything. In addition, the notes of any node can now be displayed in a popup-like field by holding Ctrl while rolling over the flow. This is disabled for Note Nodes which display their notes text anyway.
The Connect button in Input Nodes will now show the correct connection expression. A connected Input will attempt to reconnect if the connection expression is valid in the context of the current scene when loading a saved flow.
The Input Node controllers are now stored as children of a List Controller, thus allowing the preservation of a keyframe animation when connecting and disconnecting a scene track. In addition, this works around a bug in the release version of Autodesk 3ds Max 2011 which prevents custom tracks from changing their controller. An option in the File menu of the MagmaFlow editor allows the collapsing of the controllers to the original layout for passing the scene to users of Krakatoa v1.5.x. This collapsing option might not work in the release version of 3ds Max 2011 though.
New conversion buttons have been added to most Input nodes' UI, allowing the fast conversion of Floats to Vectors, Integers to Floats and Vectors to Components, as well as the transformation of Vector channels to World and View Space.
When connecting a Transformation node to a Vector input, the Transformation mode will be set according to the input type, for example if the input is Normal channel, the mode will be set to Normal automatically, if it is Position channel, the mode will be set to Point etc. The mode will also be shown in brackets next to the output name as (P),(N) or (V) for Point, Normal or Vector.
Interactive updates support for Script Inputs containing $ node references has been added. For example, if an expression like $Box01.pos is used in a script, moving the box will cause the Script Input and the MagmaFlow to reevaluate if the Editor is open with >AUTO checked or if >Interactive Mode is enabled in the KCM's user interface.
Texture Map Inputs
Support for saving and loading of texture maps used by a KCM has been added. A material library with the same name as the MagmaFlow .KMF file will be created in the save folder. When loading a flow, if the KCM already contains enough maps to satisfy the flow, a prompt will be issued asking about replacing or reusing the existing maps. In the case of reusing existing maps, the saved maps will be appended to the list so they can be switched to later if desired.
A preview thumbnail was added to the TextureMap Input node's rollout to visualize the content of the map used in the flow. The TextureMap Input now supports three modes - Color, Mono and Perturb, the latter allowing for native Bump Mapping support in Krakatoa. The Mode will be shown in brackets next to the output socket of the node as (C), (M) or (P).
MagmaFlow User Interface Enhancements
A new "Explore Presets Folder..." button was added to the KCM's UI, and a similar File menu item "Explore Flows Folder..." was added to the MagmaFlow editor. These can be used to quickly open a Windows Explorer at the default saving location of the MagmaFlow files.
The MagmaFlow Editor will now store the last Pan and Zoom settings used at every editing level (top level and nested BlackOp levels). These will be stored with saved flows and BlackOps, preserving the last view when loading a flow or entering Edit BlackOp mode. This also prevents the panning inside a BlackOp from affecting the view in the higher editor levels.
The Debug mode now lets you provide a value range for any Input node and then graph the resulting output to visually represent the influence of a value over the particle data in the flow.
Saving and Loading KCMs
Two new MacroScripts related to KCM management have been added to the "Krakatoa" Customize User Interface Category: SaveModStack and LoadModStack. The former saves the modifiers of one selected object to disk. The latter loads a selected saved file onto one or more selected objects. This can be used to move KCM setups and other related modifiers around.
A bug preventing the storing of the Depot width setting to the INI file has been fixed.
A button to manually refresh Exposed Parameters has been added to the KCM's UI. In v1.5.1, copying a PRT Loader or PRT Volume with one KCM updated the Exposed Parameters would update them correctly, but if there were two or more KCMs to update, their flows would get mixed up due to the Editor being closed. Fixing this automatically would be tricky, so we let the user fix it with a click. Opening the Editor will also fix the current modifier's exposure if needed.
The exploding of BlackOps nested within other BlackOps was not implemented correctly in previous versions - only top-level BlackOps could be exploded. This has been fixed for arbitrary depths of nested BlackOps.
A duplicated IDs problem arising when merging objects containing KCMs on their modifier stack has been fixed. This issue could lead to two or more KCMs with different flow definition referencing the same TrackView animation controllers. On Save or AutoSave, the one KCM would request the clean-up of its own "unused tracks", causing the other KCM to lose some its tracks. To solve this, incoming KCMs are now forced to regenerate a unique ID on merge.
Matte Objects Improvements and Anti-Aliasing
The Matte Objects rendering was reimplemented as a scanline renderer in v1.5.0, but some errors in the perspective transformations survived the 1.5.1 update and caused some particles in front of matte objects to be occluded incorrectly as if behind the objects. This issue has been fixed.
In the Matte Objects Rollout, the SuperSampling spinner introduced in v1.5.0 will now be used when set to a value greater than 1 even if the >Save Multiple Layers is turned OFF. It will produce pseudo-anti-aliasing to smooth out the edges of the matte object. Previously, increasing the SuperSampling value had no effect unless two layers were saved.
The >Save Multiple Layers option used to trigger internal saving code that was limited to OpenEXR files only. In Krakatoa 1.6.0, a dedicated Krakatoa_OccludedLayer Render Element will be created to handle the saving of the background layer and will support any 3ds Max output file format.
Rendering very large polygons with one or two vertices behind the camera were causing holes in the matte Z-Depth pass in prior versions. Krakatoa v1.6.0 will now clip the polygons to the view frustum to avoid such problems and only rasterize the portions of the faces that are in front of the image plane.
The Matte Objects Rollout also contains a color indicator showing whether all specified Matte Objects will actually render based on their object and layer settings. A new Matte Objects Explorer dialog that can be opened from the rollout displays all relevant settings of all Matte Objects and shows correct Matte Objects in green and non-renderable in red. The same info is also available through the Krakatoa Schematic Flow's 'Object Mattes' node.
Saving and Partitioning Particles
The particle saving code was improved to perform the PRT file generation locally in a temp. folder and to copy the resulting file to the network on success. This was necessary in order to avoid potential orphaned locked files in the case of a crash, but it could potentially improve performance depending on the network setup.
The incrementing of Particle Flow Tools Box #3 operators' seeds in local and network partitioning was broken due to changes in the Name access syntax in the latest version of the Orbaz Tech. plug-in. Krakatoa now attempts to access sub-operator names using both methods and should would with all versions of Box #3.
Particle Input Stream and Particle Data Viewer
A new KrakatoaParticleIStream MAXScript Value can be created using a new method in the FranticPaticles interface to acquire particle data from a PRT Loader or PRT Volume object. It provides methods to read the channels layout, particle count and particle data from the stream, skip over a number of particles and close the stream.
A Krakatoa Particle Data Viewer scripted utility based on the Particle Channel Input stream was added. It can be used to visualize the render-time (top of the stack) data of PRT Loaders and PRT Volume objects on the current frame using a ListView. Selecting particles in the ListView highlights the corresponding particles in the viewport. Only a user-defined sub-range is displayed at once, with the ability to show every Nth particles, filter by the selection channel or by custom filters. The min, max and average values of each channel will be calculated for the the displayed range.
Particles highlighted in the Viewer will be marked in the viewport with a red circle and a yellow number showing the index value from the first column of the Viewer. This feature can be useful to determine the correspondence between particles in the list view and particles in the scene.
User Interface Changes, Improvements and Bug Fixes
Rollout Count Reduction and GUI Speedup
Over the years since v1.0.0, the number of Krakatoa GUI Rollouts had increased dramatically. This caused the time to open the Krakatoa GUI to rise to several seconds - typically longer than it takes to render a frame of several million particles! The changes to v1.5.0 where the display of rollouts became customizable did not improve the startup times because even when hidden, the rollouts had to be kept around, albeit out of sight, for technical reasons.
To solve this growing problem, the Krakatoa GUI had to be put on a diet. The number of rollouts was halved and any rollouts not directly related to the renderer's settings have been moved to separate Utilities or floating dialogs. These include the Preferences dialog, the Notes dialog, the About dialog, as well as the Explorer tools like Scene Particles, Particle Loaders and Thinking Particles rollouts. The Shadows On Geometry rollout has been removed completely, leaving the >Save Attenuation Maps in the Main Controls rollout and adding the button to open the new Krakatoa Shadows Explorer next to it.
Some changes were also made to the way Rollouts are opened and closed on startup to reduce the time to redraw rolled up rollouts.
Changes to the Main Controls Rollout
The quick navigation buttons on top of the Main Controls rollout have been updated to include the jump destinations left in the UI.
The Motion Blur and Depth Of Field groups of controls have been split visually into two groups to break the apparent but non-existent logical connection between them.
The >Post-Divide By Alpha option has been moved from the Main Controls to the Global Render Values because it is barely used and is more relevant to the global behavior of the Renderer. The >Save Attenuation Maps button has been moved to its place to be closer to the RENDER button.
Another row of quick navigation buttons has been added to the bottom of the Main Controls rollout - these buttons open various Floaters and Dialogs that are not part of the Krakatoa GUI. These include the Schamatic Flow, the new Particle Data Viewer, the PRT Scanner Utility, the new Krakatoa Explorers floater hosting the old Scene Particles, Particle Loaders and Thinking Particles rollouts, and the old Preferences, Notes and About rollouts as floating dialogs.
Changes To Various Rollouts
The Shader Parameters controls have been moved to a dedicated dynamic rollout which will change depending on the Phase Function selected in the Main Controls rollout. The new rollout can be docked, floated and will load and save as all other rollouts. It will allow for more complex shaders to be exposed in the Krakatoa GUI in the future.
Supported property types currently include:
- Channel with >Per-particle checkbutton and Float or Color/Vector type;
- Boolean Property (Checkbutton);
- Float Property (Spinner);
- Integer Property (Spinner);
- Color/Vector Property (Color Picker);
- String Property (Drop-Down List);
- Group Control (no property connection) and
- Label Control (no property connection).
The existing shaders have been converted to use this new system for their controls. This also required a small change to the Extended VFB controls - the shading controls previously shown there are now replaced by a button to open the Shader Parameters rollout. Pressing that button will float the Shader Parameters dialog if it is currently docked.
The >Allocate [ChannelName] Channel buttons in the Shaders rollout have been renamed to >Per-particle [ChannelName] Channel to better reflect what they do.
A new Presets Management [>>] button has been added to the Save Channels list. It allows the saving and loading of channel configurations and the setting of a default set of channels to save. It also stores the data depths specified in the rollout. The Save Channels controls themselves have been moved from the old Channels rollout to the existing Save Particles rollout.
The "Channels" rollout has been renamed to "Memory Channels" since it is now responsible only for the channels allocated in memory and the forced pre-allocation of memory at render time.
The Krakatoa Schematic Flow Utility has been updated to display the node info dynamically and to highlight the nodes on roll-over.
The new Krakatoa menu under the 3ds Max Main Menu bar contains all important features normally accessible through the Krakatoa Toolbar icons. When 3ds Max is launched for the first time after Krakatoa installation, the Krakatoa menu will be added automatically to the Main Menu. In the Preferences rollout of Krakatoa, a new option >Show Krakatoa Menu Item in Main Menu will be checked by default. Unchecking this Preferences option will instantly remove the Krakatoa menu, discarding any changes made to it manually. Checking the Preferences option will add the Krakatoa menu to the end of the Main Menu. Note that the actual location of the menu might might change because the number of menu items at startup time might be different due to plugin and scripts loading order.
MacroScripts and Icons
A new icon set that is better visible in both light and dark UI color schemes has been introduced.
The new "F!" MacroScript can be used to bring the Krakatoa GUI floaters and dialogs to front when occluded by other 3ds Max windows. Note that it does not affect minimized dialogs due to certain technical limitations.
Due to the fact that many rollouts have been removed from the Krakatoa GUI to separate floaters or dialogs, several new MacroScripts and Icons had to be added. These include
- The "EX" icon which opens the Krakatoa Explorers floater with the Scene Particles, Particle Loaders and Thinking Particles rollouts;
- The "MX" icon which opens the Krakatoa Matte Objects Explorer floater showing what objects are specified as Mattes and whether they will render or not;
- The "Eye" icon which opens instances of the Krakatoa Particle Data Viewer dialog for peeking into the particle data channels of Krakatoa PRT objects;
- The Save and Load Modifier Stack icons for the new saving and loading tools;
- The "Wrench" icon representing the old Preferences rollout, now shown as a floating dialog with 3 rollouts for System, Behaviors and User Interface Colors Preferences;
- The "Scroll" icon for opening the old Notes rollout as a floating dialog;
- The "?" icon for opening the old About rollout as a floating dialog.
All these MacroScripts are also available through the Krakatoa Menu.
Presets and History Rollout Improvements
The RenderTime and SaveTime entries in the scene info lists in the Presets and History rollout now include a time comparison - if two records contain a time stamp, the difference will be shown in brackets next to the absolute time.
The frame number on which the image was rendered will now be saved in the scene info - double-clicking it will change the time slider to that frame (if it is within the current scene range).
Tooltips were added to the drop-down lists in the Presets and History with the full file name and data since it is often too long to see. These are supported in 3ds Max 2009 and higher.
Left and Right Thumbnail Strips were added for browsing multiple thumbnails at a time and for fast scrolling through the history. Left-clicking a strip thumbnail will load the corresponding record in the left or right slot. Right-clicking a strip thumbnail will open the original image.
In addition, thumbnail caching was implemented in the History rollout. In the past, the left and right thumbnails of the rendered image were using a rescaled version of the saved rendered image. This rescaling happened on the fly and could slow down the update if the original image was quite large. This slowdown became even more pronounced with the introduction of the Left and Right Strips. Thanks to the new cache, a JPG rescaled version will be saved the first time a thumbnail is requested and will be used for future display of the history record. The same cached JPG will be used for faster display in the Left and Right Strips.
A display issue causing thumbnails with white pixels to appear transparent has been fixed.
Rendering in Voxel Mode with Depth Of Field enabled could cause a crash when a voxel was found behind the camera, for example when flying through a particle cloud. This has been fixed.
A crash when saving attenuation maps in Max 2009 and earlier was fixed (this worked only in the 2010 build). This was caused by incorrect compiler settings and wasn't directly related to the Krakatoa code.
There was an instability in v1.5.x causing KCMs to crash 3ds Max randomly while changing Input values. This was most likely caused by excessive script calls from inside the C++ compiler plugin while resolving paths to TrackView controllers. The code has been refactored to access the controllers without using script calls.
In the past, network rendering would randomly fail due to an attempt to initialize the Krakatoa UI. This has been finally fixed by disallowing any UI operations when in network rendering mode.
Missing or Broken Feature Fixes
Krakatoa v1.5.0 added support for Cebas Thinking Particles 4 based on an earlier Beta version of the plugin and its SDK. Later versions of the TP4 Beta broke the SDK and caused incompatibility with Krakatoa. This has been fixed for now by compiling against the latest TP4 SDK.
The 3ds Max Volume Select modifier is now supported as a source of particle selections and soft-selections. In previous versions, it was not selecting correctly. Note that Mesh-based selection is not supported but will not cause a crash anymore as it is being actively ignored. Geometry-based selection by arbitrary volumes can be performed using the Surface Operators of MagmaFlow as shown here.
Attenuation Maps Saving is now supported in Voxel mode.
The Color swatches in the Krakatoa Material were not animatable due to missing flags in the Parameter Block. This has been fixed.
Minor and Cosmetic Issues
An old property for "Use Lighting" was still used deep inside the renderer. The property still exists at UI level for backwards compatibility and is being set by the "Ignore Scene Lights" button, but it could get out of sync under some circumstances, causing particles to render without illumination. This has been fixed.
A popup message will be shown at 3ds Max start up time if the Helium DLX was not loadeded and the Magma Flow and Schematic Flow User Interfaces could not be created. In the past, Krakatoa would fail to load with lots of MAXScript errors in the Listener, now the loading of the respective modules will be skipped, making Magma Flow and Schematic Flow
The Krakatoa Channels Modifiers added to the Global Channel Override sets were evaluated incorrectly from top to bottom instead of bottom to top in v1.5.1. This has been fixed.
A bug in the motion blur calculations where the wrong units were used for the time value has been fixed.
The PRT Loader object was producing an empty native channel map when the stream contained no particles, causing problems with Particle Flow. This has been fixed to always return the correct channel map even when the PRT file is empty.
Wire color support on streams that don't have a color or material has been fixed (for example PFlow which was showing as white instead of wirecolor).
Added flags for Absorption and Emission channels so caching them does not force their use. Previously, caching these channels then turning off the Use Absorption or Use Emission caused the data to still be used. Now, the options control whether the channels will be used. If unchecked, they will be ignored even if already in Cache.
Picking a new object in the Krakatoa Geometry Test was not causing a kd-tree update (the old geometry was used) due to notification issues. This has been fixed.
The function FranticParticles.MakePartitionFilename() was not handling directories with periods correctly. This has been fixed.
The Iterative Mode would cause Save Particles To File Sequence to save a single file in Max 2009 and higher. Now Iterative mode will be turned off when switching to Save Particles mode to avoid this.
Using the InterActive Mode and Resize Output options from the the extended VFB would cause a FULL version of the rendering to be generated in previous versions. This has been fixed.