Rendering Particle Flow Particles

Introduction

Particle Flow (PFlow for shot) has been the main particle system of 3ds Max since Release 6.0 and can be considered the primary source of particles for Krakatoa rendering. Krakatoa has been specifically optimized to work well with Particle Flow and includes bonus tools and workflows not available for the other particle sources. These include the ability to load particles saved to disk back into Particle Flow, the ability to use PFlow Script Operator channels in Krakatoa, as well as several high-performance Particle Flow operators for interaction with scene geometry objects.

Particle Flow Overview

  • PFlow is an Event-Driven Particle System.
  • A particle in PFlow is a described by several Particle Data Channels, stored in so-called Particle Containers represented by the Events in the User Interface.
  • Particle Flow can apply Operators to the Particle Data Channels to change the appearance and behavior of particles, to create new particles and to move particles between Containers.
    • Dedicated PFlow Birth Operators can create new particles by adding Data Records to the Particle Data Channels.
    • Other PFlow Operators can read and write Particle Data Channels and change their content, thus affecting particle properties like Position, Velocity, Rotation, Shape etc.
    • Special PFlow Operators called Tests can be used to read Particle Data and compare to user-defined values or conditions and either modify Particle Data when these conditions are met, send the Particles out to another Event, or both.
  • PFlow has two states - one for displaying particles in the viewports, another for rendering particles.
    • The particle count and particle appearance can be controlled independently in these two states.
  • When rendering in a renderer other than Krakatoa, PFlow generates one or more Meshes to be rendered.
    • Creating one million particles with Cube shape would result in 12 million triangles and 8 million vertices to be passed to the non-Krakatoa renderer.
    • In the case of Krakatoa though, no meshes are created or needed, thus only the relevant data (Position, Velocity) will be used, and the memory requirements will be much lower.

Particle Flow Limitations

  • PFlow is currently single-threaded. This means that it will update in approximately the same time on a single CPU or 8 core machine.
  • PFlow, like most particle systems, is history-dependent. This means that in order to produce results for frame 100 of particles created on frame 0, it has to pre-calculate all preceding 99 frames.
  • PFlow was designed in the days of 32 bit Operating Systems and has several limitations built-in.
    • It defaults to 100,000 particles limit - Krakatoa has an option to increase this limit to 100,000,000 and this option is enabled by default.
    • It cannot assign more than 100,000,000 unique particle IDs in a system.
Example: If you create a PFlow system that emits particles at a Rate of 100,000,000 per second and delete the particles at Age of 1, you will get only 3.3 million particles per frame, but after 30 frames you will run out of the available 100 million IDs and no more particles will be generated (Krakatoa will get 0 particles to render)!

Particle Flow Render Operator

  • The rendering of the Particle Flow system is controlled by a dedicated Render Operator.
  • The Render Operator is located by default in the global PF Source event, thus affecting all Events in the flow.
  • A Render Operator placed locally in an Event will override the settings of the global Render Operator!
    • Krakatoa will only render particles from Events that have a valid Render Operator - either a global Render Operator for the whole system or a dedicated local Render Operator.
    • If an Event has neither a global nor a local Render Operator, its particles will NOT be visible to Krakatoa regardless of the Krakatoa Source Settings.
  • A Render Operator can be set to Geometry, Bounding Box, Phantom or None mode - Krakatoa provides Particle Source options to enable individually the first three types, so you can have events set to Geometry rendering while Events set to Phantom would be ignored.
  • The “None” Render mode will never produce particles, but Krakatoa will force an update of these particles. This is useful when other particles depend on them indirectly (e.g. a Proxy Particle System driving another Particle System).

Particle Flow Render Modes

  • The Render Operator currently has four modes: Geometry, Phantom, Bounding Box and None.
    • Krakatoa supports the first three modes as distinct sources and will acquire only particles from Events that are set to one of these modes.
    • Krakatoa does not produce different results from the three different modes, it just uses them as “filters” to group particles into three different categories.
  • The fourth, None mode, is not supported as a group filter, instead it causes the Particles with that Render Mode to still update at render time, but without being rendered.
    • This is useful when using complex inter-dependencies between Particle Flow Systems where the particles of the one system depend on a second system, but only the particles of the first system have to be visible to Krakatoa.
  • The Particle Source options are located in the Main Controls rollout of Krakatoa, to the left of the Render button.
    • The first three checkbuttons (top row) are dedicated to Particle Flow Modes.
    • These options are also available in the Extended VFB Controls in 3ds Max 2009 and higher.
    • The >PFlow Geometry and >PFlow Phantom options are checked by default (when using Factory Defaults) since these are the most likely PFlow Modes to be rendered (PFlow defaults to Geometry Mode when a new Render Operator is added)

Supported Data Channels

  • PFlow can contain an arbitrary number of Particle Data Channels, but there are several channels that are vital to the particle.

Native PFlow Channels

  • Krakatoa can acquire only a sub-set of the possible Particle Data Channels.
  • These include:
    • Position channel - this channel maps directly to Krakatoa’s Position channel.
    • Orientation channel - this channel is currently not used by Krakatoa, but can be saved and loaded through PRT files.
    • Scale channel - this channel is currently not used by Krakatoa, but can be saved and loaded through PRT files.
    • Velocity channel - thus channel maps directly to Krakatoa’s Velocity channel.
    • VertexColor channel - this channel maps directly to Krakatoa’s Color channel.
    • TextureCoord channel - this channel maps directly to Krakatoa’s TextureCoord channel (Mapping Channel 1).
    • Mapping2-Mapping99 - these 98 channels are not used directly by Krakatoa for rendering, but could be required by maps or could be used to pass custom Vector data from Script operators to Krakatoa MagmaFlow.
    • ID channel - this channel is not needed for Krakatoa rendering, but is used by other Krakatoa components, for example for loading saved particles back into PFlow, for gradually deleting particles by soft-selection etc.
    • Age channel - this channel is not used by Krakatoa for rendering but can be accessed in Krakatoa Channel Modifiers for age-based data operations.
    • LifeSpan channel - this channel is not used by Krakatoa for rendering but can be accessed in Krakatoa Channel Modifiers for age-based data operations.
    • MtlIndex channel - this channel contains a zero-based pointer at the sub-material of a Multi/Sub-Material to be applied to the particle.
    • MXSInteger, MXSFloat, MXSVector channels - these channels are not used by Krakatoa but could be set by Script Operators in PFlow and saved by Krakatoa for passing arbitrary Integer, Float and Vector values around.

Implicit Data

  • Normal - this channel does not exist as such in PFlow, but is extracted from the X axis of the particle’s Transformation Matrix.
  • Tangent - this channel does not exist as such in PFlow, but is extracted from the Y axis of the particle’s Transformation Matrix.

Inaccessible

  • Custom Channels created using Particle Flow Tools Box #2 are currently not accessible.

Particle Color and Materials

Default Display Color

  • PFlow uses a dedicated Display Operator to define the color of particles per Event (or optionally for the whole system if placed in the Emitter’s Event).
    • The Color specified in the Display Operator is used by 3ds Max to define the Wireframe (Object) color of the PFlow Event.
    • This Color value will be used by Krakatoa as the Color of the particles to render if no other color source is specified via Vertex Color channel, PFlow Material Operators of Krakatoa Color Overrides.
  • In the example below, the only color source is the Display Operator which sets the particles to green color (which is also the color shown in the viewport):
../../../_images/krakatoa_particleflowrendering_objectcolor_pview.png ../../../_images/krakatoa_particleflowrendering_objectcolor_render.png

Vertex Color Channel

  • Krakatoa considers the 3ds Max Vertex Color channel (Mapping Channel 0) used normally in Meshes to be equivalent to the Color channel used internally by Krakatoa.
  • If the PFlow contains a valid Vertex Color channel set for example by a Mapping operator, a Script Operator or a Particle Flow Tools Box #3 DataOperator, the Vertex Color channel will be used as the Color source.
  • In the example below, a Mapping Operator with a static value of 1,0,0 has been applied to all particles, resulting in all particles turning red despite the Display Operator being green:
../../../_images/krakatoa_particleflowrendering_vertexcolor_pview.png ../../../_images/krakatoa_particleflowrendering_vertexcolor_render.png

PFlow Material Operator

  • If an event contains a Material Static, Material Dynamic or Material Frequency operator using the Standard Material of 3ds Max, the Diffuse Color of the Standard Material will be used on the particles.
    • The various other channels affected by the Standard Material like Density (from Opacity value), Emission (from Self-Illumination value), Specular Power and Level (from Glossiness and Specular Level) and Absorption (from Filter color value) will also be set if required by the Krakatoa rendering settings.
  • In the example below, a Material Static operator has been applied to all particles, setting their color to the Diffuse color of the Standard Material references by the operator, in this case cyan with RGB value of [0,212,255].
    • Despite the Display Operator being green and the Mapping Operator setting the Vertex Color channel to red, the particles render as cyan:
../../../_images/krakatoa_particleflowrendering_materialstatic_pview.png ../../../_images/krakatoa_particleflowrendering_materialstatic_render.png
  • In the example below, a procedural Cellular Map was added to the Diffuse Map slot of the Standard Material assigned to the Particle Flow.
    • This causes the particles to be colored according to the procedural map:
../../../_images/krakatoa_particleflowrendering_materialstaticmapped_medit.png ../../../_images/krakatoa_particleflowrendering_materialstaticmapped_render.png

Global Overrides

  • Krakatoa provides several ways to override the color of all particles regardless of their source.
  • As result, enabling the >Override Color option in the Global Render Values rollout of the Krakatoa GUI will also override the Particle Flow color regardless of the previously mentioned color sources.
  • In the example below, the Particle Flow still has its green Display Color, red Vertex Color map, cyan diffuse color overridden by a green-cyan Cellular procedural map, but the particles render in yellow because of the Global Color Override:
../../../_images/krakatoa_particleflowrendering_coloroverride_rollout.png ../../../_images/krakatoa_particleflowrendering_coloroverride_render.png