Rendering PRT Loader Objects

Introduction

• The Krakatoa PRT Loader object was designed specifically for the loading, combining, transforming, retiming, culling, deforming, rendering and re-saving of particle file sequences including the native PRT file format, the CSV text format and the 3rd party RealFlow particle BIN format.

Loading and Combining Particle File Sequences

• A 3ds Max scene can contain any number of PRT Loaders.
• Each PRT Loader can contain one or more particle files or file sequences.
  • When more than one sequence is being loaded, the content of the files will be combined into a single particle cloud.
  • In Krakatoa MX 2.0.0 and higher, loading multiple sequences in the same PRT Loader on a multi-core system can provide a significant performance boost assuming the storage medium (HDD, SSD, Network) can keep up with the demand. This is achieved through loading each sequence in a separate thread.

Position Channel and Transformations

• The Position channel of particle files including PRT, CSV and BIN contains world-space coordinates.
• The PRT Loader uses the data from the Position channel of particle files as LOCAL coordinates - a particle with coordinate [0,0,0] will appear at the Pivot Point of the PRT Loader, not at the World Origin, unless the PRT Loader IS at the World Origin.
  • Thus, a PRT Loader placed at the World Origin and aligned to the World Coordinate System with Scaling of 100% will place the particles exactly where they were when they were originally saved.
    • Note that holding SHIFT while pressing the PRT MacroScript / Create a PRT Loader item in the Krakatoa Menu will create a PRT Loader at the origin.
    • Pressing the Create New Loader… button in the PRT Loaders rollout of the Krakatoa Explorers floater will also automatically place the PRT Loader at the World Origin.
  • When saving a particle system to a particle file sequence, it is a good idea to place the emitter of a particle system at or close to the World Origin if it is expected the particles to align to the Gizmo of the PRT Loader used to bring them back into the scene.
    • For example, if you are creating a generic stream of particles to be used later in multiple PRT Loaders to be deformed along splines using Path Deform modifiers, create a Particle Flow Emitter at the World Origin, save the particles and load in the PRT Loaders - the particles will appear to be emitting from the pivot point of the PRT Loader.
• If the Use Node Transform checkbox of the PRT Loader is checked (default), placing the PRT Loader anywhere else than at the World Origin will also transform the particles.
• Both Position, Rotation and Scale information from the PRT Loader will be applied, allowing the offsetting, rotating and scaling of pre-saved particle systems.

Timing and Re-Timing

• As mentioned already, a PRT Loader can reference one or more files or file sequences.

Loading Single Frames vs. File Sequence

• The File List of the PRT Loader is meant to specify one representative frame of each file sequence to be loaded, or the exact file to be loaded, depending on the state of the “Load Single Frame Only” option.
• It seems to be a common misconception among new users that the list is supposed to include every frame of a file sequence, e.g. “particles_0000.prt”, “particles_0001.prt” and so on - this is not the case and only one file “particles_####.prt” where #### can be any frame number from the sequence and have any number of digits.
  • To make this clear, the display of the file name in the PRT Loader’s File List was changed in v1.6.0 to show as “partcles_####.prt” when “Load Single Frame Only” is unchecked and as “particles_0042.prt” (if that frame was picked) when “Load Single Frame Only” is checked.
• If the “Load Single Frame Only” option is checked, the exact file name listed in the PRT Loader will be loaded on every frame without modifying it to add/replace a frame number.
  • For example, if the file name “C:TempPartitionsParticles_0042.prt” is specified in the File List of the PRT Loader and “Load Single Frame Only” is checked, the file “Particles_0042.prt” will be loaded on frame 0, on frame 10, on frame 42 and on any other frame regardless of all the available timing settings in the PRT Loader or the current scene/render time.
  • In fact, the file name could not contain a frame number at all, e.g. “Particles.prt” and it will still be loaded correctly.
• If the “Load Single Frame Only” option is not checked, the file names listed in the PRT Loader will be modified using the current time, offset and the other Timing options to load a specific frame from a numbered sequence.
  • For example, if the file name “C:TempPartitionsParticles_0042.prt” is specified in the File List of the PRT Loader and “Load Single Frame Only” is unchecked, by default moving the time slider to frame 0 will attempt to load the file “C:TempPartitionsParticles_0000.prt” instead, and moving the time slider or rendering at a different time will replace the frame number in the file name accordingly.

Combining File Sequences

• The File List of the PRT Loader can contain an arbitrary number of files or file sequences.
  • It is allowed to mix file formats (e.g. PRT, CSV and BIN) or files for different sources (e.g. Particle Flow, Thinking Particles, Legacy Particles etc.) in the same PRT Loader.
  • Each of the file sequences can be shown in the viewport, in the renderer, or in both with individual controls.
• The main purpose of the PRT Loader’s File List is the combining of Particle Partitions created from the same source with varying Random Seeds into a single dense particle cloud.
• The same mechanism can be used to combine completely unrelated sequences that require to be loaded, transformed, retimed, deformed, modifier, culled or shaded in the same way using a single PRT Loader object as the host.
  • It is of course possible to create multiple PRT Loaders and load one sequence in each, but then the control over the timing, transformations etc. would require changing values in multiple objects.
  • Thus, using separate PRT Loaders is only advisable when the particles have to be manipulated separately in unique ways, for example if they require different material assignment, or different timing, or different modifiers on the stack.

Velocity and Load Single Frame Only mode

• By default, when “Load Single Frame Only” is checked, the same particles will be loaded on every frame and since they are not moving over time, their Velocity channel will be automatically reset to zero magnitude, removing the ability to produce motion blur.
• While this is a logical behavior, sometimes it is useful to preserve the Velocity channel even if the particles are not moving.
  • Possible usage cases are when applying one or more Krakatoa Channels Modifiers (KCMs) which need access to the original Velocity data, or when rendering a static particle cloud with extreme Motion Blur to produce a kind of fuzzy hair effect from static particles.
  • A KCM could also be used to manually reset the Velocity channel to zero if needed.
• Thus, the option “Keep Single Frame Velocity” was introduced in Krakatoa v1.6.0 to override the default behavior.
• See the tutorial Single Frame Constant Motion Animation for an example of possible usage.

Offsetting The Timing

• The Offset value in the PRT Loader defines a negative offset in time (in that a positive value moves the sequence backwards in time by adding the offset to the current frame).
  • In other words, it could be interpreted as the answer of the question “What frame will be played on frame 0?”
  • For example, if the file “particles_0000.prt” is specified, the time slider is on frame 0 and the offset is set to 10, the file “particles_0010.prt” will be displayed on frame 0.
  • If the time slider is moved to frame 10, the file “particles_0020.prt” will be loaded and so on.
  • Note that the frame number to be loaded will be displayed in the PRT Loader’s UI to make it easier to figure out what the result of the retiming will be.
• Obviously, using negative values in the Offset field will move the sequence forward, so a value of -10 will attempt to load frame “particles_-0010.prt” on frame 0, and on frame 10 the file “particles_0000.prt” will be loaded.

Keyframing The Timing Using The Graph Value

• The Playback Graph control in the PRT Loader is very similar to the one found in the 3ds Max Point Cache modifier.
  • It allows you to specify the exact frame to be played at a certain scene time by using a TrackView controller’s animation curve.
  • It also allows the scaling and reversing of time and the interpolation of particle values at sub-frame steps, as long as the particle files contain Position and Velocity channels.
• When the Graph checkbox is checked and the Graph value is 0 (default), the PRT Loader’s time will freeze at 0 and no animation will be played.
  • If there is a Velocity channel, it will be loaded as zero because a particle that is not moving between frames cannot have a velocity.
  • If the Graph value is changed to a different value, e.g. 42.4, the particles will be loaded from frame 0042, their positions will be shifted forward along the Velocity vector loaded from frame 0042 and using 40% of its magnitude, but then the Velocity will be reset to zero because the particles won’t move as time changes since the Graph value is still constant.
• If the Graph value is keyframed to change between frames, the particles will start moving and their velocities will be scaled respectively to represent the resulting speed.
  • For example, if a keyframe with a value of 0.0 is set on frame 0 and a keyframe with a value of 100.0 is created on frame 50, the particle animation will play back twice as fast and the velocities will be scaled two times, too.
  • Similarly, of the keyframe on frame 50 has a value of 25.0, the particles will move twice as slow.
  • If the first key on frame 0 has a value of 100.0 and the second key on frame 50 has a value of 0, the animation will be played backwards and twice as fast.
  • Using keys creatively, all sort of retiming tricks like Ping-Pong animation effects, gradual slow downs and speed ups etc. are possible.
  • The >> menu next to the Graph and Offset values provides some animation presets which create keys in the current animation segment.
• Note that the Offset value will still be respected when using the Graph curve - the Offset value will be added to the value of the animation controller at the respective frame.
  • This is equivalent to shifting all keys of the Graph controller left or right, but is much easier to apply.

Interpolating Sub-Frames

• In versions prior to 2.0.0, the retiming would always use the closest full frame from the sequence and extrapolate the particle position based on the Position and Velocity channel of that single file.
• In Krakatoa MX v2.0.0 and higher, the option to interpolate the position using the two closest full frame files.
  • This is especially useful when the Velocity is changing significantly between the two samples (e.g. a particle is moving on a curve and not a straight line) and when the retiming requires a significant slow down, producing multiple new samples.
  • When the option “Interpolate Sub-Frames” is checked, the two surrounding frames’ files will also be read and the particle will be matched by its ID channel.
  • The the Position and Velocity samples will be loaded and a curve will be interpolated based on them, thus producing a smooth transition over time, avoiding the position discontinuity produced when the option is off.
  • Note that this finer retiming is achieved at cost of performance, so it is advisable to resave the retimed particles once to a new PRT sequence and load that in the PRT Loader instead.

Custom Range Limit and Start/End Behaviors

• Using the Offset the Graph values, or even moving the time slider or rendering the wrong frame could cause the request for a non-existent particle file to be made to the PRT Loader.
  • In general, it was a conscious design decision to make Krakatoa refuse the rendering of missing frames to ensure no “bad frames” could be produced if a file is corrupted or not rendered yet.
  • There is a special override to this behavior in the Main Controls of Krakatoa to allow the silent rendering with missing frames, but by default if a PRT Loader cannot find a requested frame from the animation, an error will be thrown at render time.
• To allow the definition of a “valid interval” to load particles from, the “Limit to Custom Range” option was added to the PRT Loader.
  • Using the Start and End values, it is possible to define what frames actually exist and can be loaded and what frames are “off limits”.
  • Note that the “Range” button next to the Start and End values can be pressed to attempt to determine the optimal range based on the existing frames in all sequences currently loaded in the PRT Loader.
  • For example, of a file sequence is saved to disk that contains all frames from “particles_0010.prt” to “particles_0042.prt”, entering 10 and 42 in the Start and End value fields (or using the “Range” button to set them automatically) and then enabling “Limit to Custom Range” will ensure that no frame outside of the interval from 10 to 42 will be requested.
• The two drop-down lists below the Start and End spinners define what to do if a frame outside of the Custom Range is requested.
  • The default behavior is “Hold First” and “Hold Last”, so if frame below the Start value is requested, the Start value will be used to clamp that request, and if the frame is above the End value, the End value will be used instead.
  • In the above example case, if the frame 5 is being rendered, the file “particles_0010.prt” will be loaded because the Start value is 10 and “Hold First” is selected.
  • Similarly, if frame 50 is requested, the file “particles_0042.prt” will be loaded instead because the End value is set to 42 and “Hold Last” is selected.
• The alternative mode to holding is “Blank” and simply outputs no particles.
  • This is useful when the first or last frame of the sequence contains non-zero particle count but you want the sequence to start and/or with no particles at all - instead of actually saving the first or last frame with no particles, it is possible to assume any frames outside of the custom range as empty and thus introduce these blank files at any time without actually saving them to disk.
  • Note that the “Loading Frame” field in the PRT Loader’s UI will respect the Custom Range and correctly display the clamped frame number in “Hold” mode or “Blank” in “Blank” mode.

Modifying, Deforming, Selecting and Culling Particles

Modifying Particle Channels

• The PRT Loader can host one or more Krakatoa Channels Modifiers (KCMs) which can be used to read, modify and write particle channel data coming from the bottom of the stack (starting with the data loaded from file sequences by the PRT Loader itself) and passing through the modifiers.
• The data channels loaded from the file sequence depend on the channels that were saved to the file sequence when it was generated.
• A KCM can only input channels that have been found in the file sequences of the PRT Loader or have been generated by other modifiers below it on the stack.
• If two sequences contain different particle channel layouts, a union of all channels from all sequences will be provided, but particles that do not have a channel defined will return a default value from that channel.
• For more information on modifying particle channels, please see the MagmaFlow Editor documentation and related tutorials.

Deforming Particles

• The PRT Loader supports particle deformations applied by the standard 3ds Max gizmo-based modifiers and Space Warps like Bend, Twist, PathDeform as well as the dedicated Krakatoa SkinWrap World Space Modifier.
• For more details, see the dedicated topic on deforming particles.

Selecting Particles

• The PRT Loader supports a Selection channel which is equivalent to the Soft Selection channel of 3ds Max Meshes.
• The Selection can be used to control the influence of deformation modifiers on particles or to delete particles via a dedicated Krakatoa Delete modifier.
• A value of 0.0 in the Selection channel means no selection, a value of 1.0 means fully selected, values between 0.0 and 1.0 are soft-selection weights, and negative and greater than 1.0 values can be used to invert or boost the influence of the selection on modifiers.
• The Selection can come from one of the following sources: * Pre-saved Selection channel in the particle file; * Krakatoa Channels Modifier with Output set to Selection channel; * 3ds Max VolumeSelect Modifier in gizmo mode (except the Mesh mode which will cause a crash when used on a PRT Loader).

Deleting Particles

• PRT Loader’s particles can be deleted using two different methods:
  • Delete by Selection channel using the Krakatoa Delete modifier and existing or KCM-generated selection - this can happen anywhere on the stack.
  • Delete using the Culling volumes of the PRT Loader itself - this is performed after the full evaluation of the particles after all modifiers, transformations and material evaluation.
• Deleting particles can be very useful to
  • Create complex-looking clouds out of simpler ones by removed (carving) particles
  • Remove particles that wouldn’t render anyway, for example those with Density of 0, outside of camera view etc.
  • Remove particles that are out of interest at the current point, leaving just the relevant portion to the renderer.

Culling Particles

• The Particle Culling feature uses arbitrary geometry volumes to determine which particles to delete and which to keep.
• The Culling is performed in world space on top of the stack after modifiers, transformations and space warps are applied.

Normal Acquisition From Culling Geometry

• The same Geometry used for Culling can also be used to acquire Surface Normals and assign to the Normal channel of the particles.
• Again, the acquisition happens on top of the stack after all transformations and deformations, so the results cannot be visualized in the viewport as, say, color using an object-space Krakatoa Channels Modifier, but will be visible to the Renderer and eventual Global Channel Modifiers.

Rendering PRT Loaders

Renderable Conditions

• A PRT Loader with one or more valid file sequences will be considered by Krakatoa for rendering or saving if:
  • The “>PRT Loaders” option is checked in the Main Controls rollout of the Krakatoa GUI
  • The PRT Loader is not hidden in some way (Hidden, Hidden By Layer, Frozen while “Hide Frozen Objects” option is checked);
  • At least one sequence is enabled for Rendering via its “Render” checkbox;
  • The PRT Loader’s checkbox next to the “Percent [a]” button in the Rendering rollout is checked;
  • The Percentage value is higher than 0.0 and the Limit is not enabled or higher than 0.0 if enabled;
  • The Renderable property of the PRT Loader’s Object Properties is checked;
  • The “Visible To Camera” property of the PRT Loader’s Object Properties is checked;

Note: These conditions can be checked for automatically using the “Krakatoa Particle Explorers” > “PRT Loader Objects” > “Test Renderable State” mode.

Color Sources

• The Color of PRT Loader’s particles will be determined as follows:
  • The Color Channel from the particle files will be loaded, if present.
  • If some sequences in the PRT Loader do contain a Color channel and others do not, the latter will default to white [1,1,1] value.
  • If the Color Channel is not present, the particles will default to the PRT Loader’s Object color.
  • If a Krakatoa Channels Modifier is applied to the PRT Loader and outputs to the Color channel, that value will override any Color coming up the stack
  • If a Material is assigned to the PRT Loader, its Diffuse Color output will override any color coming up the stack.
  • If a Global Channels Override KCM is modifying the Color channel, it will override any color values coming from the sources listed above.
  • If the “>Override Color” option is checked in the Global Render Values rollout, this color will override any color values coming from the sources listed above.

Note: In versions prior to v1.5.0, in the case of “>Override Color” on, it was possible to tweak the color interactively while the PCache was enabled since the color would be taken directly from the Color Override value. With the addition of mapping support in v1.5.0, it became necessary to store the override value in the Color channel in memory, thus tweaking the color with PCache on is not possible anymore and will require the reloading of the particles.

Color Channel

• For example, the following 1 million particles were originally saved with a Color Channel and a constant blue color from the Particle Flow’s Display operator:

Krakatoa Channels Modifier

• Adding a Magma Modifier and setting it to a flow to load the Position, take the Absolute value, multiply it by 0.04 and output as Color overrides the blue color coming from the file:

Material

• Applying a Standard Material with a Cellular Map with Red, Green and Blue colors in Object Space overrides the above two color sources:

Global Channels Override

• Creating a Global Channels Override Set and setting the KCM’s flow to load the Velocity, take the Absolute value multiplied by 0.1 and output it as Color overrides all the color sources above:

Color Override

• Enabling the >Override Color option and setting the Color to yellow overrides all above color sources:

• Keeping the >Override Color option checked and adding a Noise Map will override the particle color with the map’s color output:

Density Sources

• The Density of the PRT Loader’s particles will be determined as follows:
  • The Density Channel from the particle files will be loaded, if present.
  • If the Density Channel is not present in the files, the Density will default to 1.0
  • If a Krakatoa Channels Modifier is applied to the PRT Loader and outputs to the Density channel, that value will override any Density coming up the stack
  • If a Material is assigned to the PRT Loader, its Opacity channel will be multiplied with the Density coming up the stack.
  • The Density will then be multiplied with the Visibility track’s value (this includes values outside the 0.0 to 1.0 range, if set via the TrackView curves).
  • If a Global Channels Override KCM is modifying the Density channel, it will override any Density values coming from the sources listed above.
  • If the “>Override Density” option is checked in the Global Render Values rollout, this value will override any Density values coming from the sources listed above.
  • The resulting particle Density value at this point will be stored in the renderer’s Density channel and will be multiplied on the fly at render time with the Final Pass Density value and optionally by the Lighting Pass Density value to produce the actual Density seen in the final rendering.

Note: Since the Final Pass/Lighting Pass Density multiplier operates on the Density on the fly, it is possible to lock the Density Channel via the PCache and manipulate the global Density scale without having to reload the particles.