Interoperability with Particle Flow

• 1 Interoperability with Particle Flow
  • 1.1 Introduction
  • 1.2 Interactions With Particle Flow
  • 1.3 Operators Affecting Krakatoa
  • 1.4 Operators Not Affecting Krakatoa
  • 1.5 Particle Flow Evaluation Order

Introduction

Krakatoa provides advanced support for Particle Flow particles because it is the built-in event-driven particle system of 3ds Max and has been available to every 3ds Max user since Release 6.

Interactions With Particle Flow

• Reads particle information like position, velocity, orientation, color and material.
• Can use the custom Scripted Vector channel as particle color source. The channel can be defined either by scripted operators or by Orbaz Particle Flow Tools Box #3 DataFlow operators (see example here).
• Can use the custom Scripted Float channel as particle density multiplier. The channel can be defined either by scripted operators or by Orbaz Particle Flow Tools Box #3 DataFlow operators.
• Particles created by Particle Flow can be saved to one of the supported particle file formats - PRT, BIN or CSV.
• Particle Files saved from Krakatoa (PRT, BIN, CSV) can be loaded into Particle Flow via custom Krakatoa Operators.
• Particle File Partitioning supports Random Seed manipulation at operator level with exclusion at type level via options in the Partitioning rollout, as well as at global (emitter), local (event) and per-operator exclusion using the "NOSEED" flag that can be added to the emitter, event and operator names.

Operators Affecting Krakatoa

Particle Flow operators can be divided in several groups based on their effect on the flow:

• Birth Operators - these operators create new particles. There can be exactly one such operator in the initial event of a flow (no more, no less). While some operators can Spawn new particles based on old particles, those are considered Fertile but not Birth operators.
• Particle Data Operators - these operators change particle data in the particle channels
• Tests - these operators compare data from particle channels with thresholds and send out particles based on the test
• Utility Operators - these operators modify all particles in the EVENT they are placed into. If placed into the Emitter's event, they modify the whole flow. For example, Render and Display operators change the way an event or flow will be displayed or rendered without changing particle data in channels.

Krakatoa reads data only from certain particle channels. This means that only operators modifying data in these channels can be seen as affecting Krakatoa.

• All Birth Operators - Krakatoa needs particles to render, so any operator creating particles is supported.
• All Operators affecting one of these channels:
  • Position channel (incl. Position Icon, Position Object)
  • Velocity channel (incl. Speed, Speed By Icon, Speed By Surface, Force, Find Target etc.)
  • Rotation/Orientation channels (incl. Rotation, Spin etc.)
  • Material channel (incl. Material Dynamic, Material Static etc.)
  • Scripted Vector channel (incl. any Script Operator or DataFlow operator affecting that channel)
  • Scripted Float channel (incl. any Script Operator or DataFlow operator affecting that channel)
• All Test Operators moving particles between Events
• Render Operator - only the Type property is being used to determine whether particles will be rendered or not based on the options provided in the Main Controls rollout.

Operators Not Affecting Krakatoa

• Any Operators affecting the Shape channel - Krakatoa does not need a particle shape, it only reads particle positions as points in space. Thus disabling the Shape channel can speed up Particle Flow processing without affecting Krakatoa in any way. These include Shape, Shape Facing, Shape Instance, Shape Mark etc.
• Any Operators affecting the viewport display like Display operator - Krakatoa does not care whether particles are being displayed AT ALL in the viewports, it acquires particles from the render state of the Particle Flow. This means that while you can use the Display operators to preview your particle effects in the scene, you could also turn the display completely off (using Type:None or even by setting the Emission>Quantity Multiplier>Viewport % to 0.0 or close to 0.0) to speed up viewport redraws and still render millions of particles in Krakatoa. An exception is the Color of the Display Operator which defines the color of particles if no material is assigned.

Particle Flow Evaluation Order

Particle Flow distinguishes between local and global operators - global operators are placed in the Emitter, local operators are placed in the Events connected to the Emitter. The behavior can be switched in Particle View > Options > Action Order > Globals First / Local First.

• By default, Particle Flow is set to evaluate local operators first, then global operators. For example, if a Position Operator is placed in an Event AND in the Emitter, the Emitter's operator will overwrite the positions set in the local event. This is really useful if you want to apply a force, say, Gravity, to the whole particle system - instead of instancing the same operator to each event, you can place it in the Emitter and it will affect all particles in the flow.
• Optionally, the evaluation order can be switched to evaluate global operators placed in the Emitter first, then local ones. This makes sense when the majority of events in the flow require the same operators to be applied with only few operators in few events needing a tweak via local settings. In this case, all global operators could be placed in the Emitter to affect all particles, then the local operators could be placed in the specific events to provide different behaviors overriding the global ones. This would simplify the flow significantly, avoiding the need to clone the same operators to all events over and over again.
• Operators affecting the Events themselves like the Render operator DO NOT take this order into account though. It has been designed to always evaluate globals first because, most probably because it makes more sense and makes it easier to tweak the render behavior of a complex flow without adding too many operators. For example, if you have a flow with 10 events and want ONE event to render as Phantom while all other 9 would use the default Geometry type set in the global operator, it is sufficient to add a local Render operator to the one event and switch it to Phantom and the flow will be transformed to do what you want. If PFlow would take the action order into account in this case, you would be unable to override the render type of an event - the only way would be to add 9 Render>Geometry operators and one Render>Phantom operator to all events in the flow tho achieve the same result.