Previous Topic (None)

FAQ

The following questions and answers were taken primarily from the Frantic Films Support Webboard.

Particle Loaders

Moving Culling Volumes Along All 3 Axes

When using Culling Volumes, I can only move them along X but not Y and Z

This is a bug in the reference system of 3ds Max - when a node has a dependency to another object and its Position Controller is set to Position_XYZ, notifications only work for the X axis. Moving the object with the transform gizmo along Y and Z does not update the viewport correctly, although moving along X after that shows a change in the other two axes. Possible workarounds:
You can move the culling nodes using the Transform Type-In.
If you want to fix the reference notification problem permanently, you can switch the Position controller to Bezier_Position instead of Position_XYZ. That controller has no sub-controllers and updates correctly when the object is moved interactively.

The Particle Loaders Do Not Update In The Viewports

When I change settings in the Particle Loader's GUI, the viewport does not update unless I change the time slider.This is a display glitch which can be caused by some viewport driver settings.

Assuming you are running a graphics card with Direct3D or OpenGL driver setup in 3ds Max, follow these steps:
Go to Customize>Preferences>Viewports>Configure Driver...
Make sure that in the Windows Updates group of controls, "Redraw Scene On Window Expose" is UNCHECKED
Make sure that "Use Incremental Scene Updates" is CHECKED in the same group of controls.
Results may vary from card to card, but in general we have found these settings to work well with 3ds Max and Krakatoa. In addition, these are the DEFAULT settings 3ds Max ships with, so they should work in the majority of cases. Also note that there is a known issue with Software Z-Buffer not redrawing the PRT Loader in all 4 viewports. If you are using Krakatoa, you should not use Software Z-Buffer anyway (3ds Max 9 64 bit does not even support Software Z-Buffer!)

Hiding Particle Loaders by Category

I would like it if the PRT loaders would consider themselves particles under the display filters. So the Hide By Catagory would turn off the PRT loaders when Particle Systems was checked.

Unfortunately, the Particle Loader is a tandem of a scripted geometry plug-in extending a C++ plug-in. This makes the exposure of the Particle Loader as a particle system tricky as scripted geometry plug-ins cannot be registered with the main display filters - they are always assumed to be of geometry class. As a workaround, you can register your custom filter in the Hide By Category area to hide just PRT Loaders.
Go to Display tab.
In the area below the checkboxes, hit the Add button.
Scroll the list and find "PRT Loader" class.
Hit OK

If you would select PRT Loader in the list now, all Particle Loaders would be hidden.
To unhide, press the None button or deselect the PRT Loader by holding down Ctrl key.
Note that you can add any other object class to the custom filter list. It is an often overlooked feature of 3ds Max.

Every Nth Particle Is Much Slower Than First N Partices

I have a PRT Sequence with 10 million particles per frame. When I switch to Every Nth Particle loading, I cannot play back the animation in the viewport, regardless of my Viewport Percentage settings.

This is to be expected.
When using First N Particles loading mode with, say, 0.1% of 10 million particles, Krakatoa has to read the first 10,000 particles from the file. Then the same 10K particles are drawn in the viewport.
When you switch to Every Nth Particle mode, Krakatoa has to read through the whole file to collect every 1000th particle, then displays the collected 10,000 particles in the viewport.
In theory, the loading portion of this operation would be 1000 times slower in the worst case.
In practice, 10 million particles should load in about 7 seconds.
This is the reason for First N Particles to be the default mode.
If your particles have been generated with random positions and on a single frame, there would be almost no visual difference between First N and Every Nth.
If the particles come from geometry vertices or have been generated over a period of time with constant speed or force influencing them (like the default PFlow system), then displaying/rendering First N Particles would cut a contiguous part of the object, so using Every Nth to get a balanced distribution would be necessary.
When loading 100% of the particles, both modes require the same time.
Another possible solution to playback speed would be to write out multiple Partitions of the same particle system, then load all of them and set the Loading mode to First N, with a percentage reflecting the partition size - for example, if 10 partitions were created, load 10% of the particles. This will load all particles from the first partition (which will be distributed correctly representing every 10th particle of the combined particle cloud!). In other words, this approach will give you the speed of "Load First N" with the particle distribution of "Load Every Nth".
NOTE: If a frame is taking SIGNIFICANTLY longer to load (for example in the order of minutes), make sure the PRT file is not corrupted.

Rendering

Rendering Specific Particle Flow Events

I have a PFlow setup where an object emits particles on surface that spawn other particles when it hits the ground. I just want the secondary particles to render in Krakatoa not the first ones. I have deleted the display and the shape operators but they still render!

Assuming that you are sending out the spawned particles to a new event, do this:
Keep the Render operator in the PF_Source emitter - it is by default set to Geometry.
Add a new Render operator to the event containing only the Spawned particles.
Set this new Render operator to Phantom instead of Geometry.
Open Krakatoa Scripted GUI and at the bottom of the Main Controls, uncheck the >PFlow Geometry option, while leaving >PFlow Phantom checked.
If you would render now, Krakatoa will only get the particles set to Phantom Render Mode which are the spawned ones you want to render. Note that the Shape and Display operators have no effect on Krakatoa. The Shape operator is completely ignored so it could be disabled or deleted, the Display operator only controls the viewport display of Particle Flow itself so it should be there but does not affect rendering.

Can I use Particle Flow Particles as Matte Objects?

I have two PFlows - one generates millions of particles, the other just a few with relatively large geometry shapes. Can I use the geometry of the second PFlow as Matte Object to occlude the first PFlow?

Yes, you can.
Create a Mesher Compound Object at [0,0,0] and pick the second PFlow as the source node.
Hide the emitter of the second PFlow - hidden Emitters will not be rendered, but the Mesher will still force an update when evaluated.
Add the Mesher object to a Matte Named Selection Set.
Render as usual.
The Mesher will reflect the exact shape of the Particle Flow while appearing as geometry object to Krakatoa.

Can I specify Particle Color and Density Per Particle?

I tried using a Particle Age map to define the color and density of particles over time but it does not seem to work. Can I make the color or density dependent on the particle age or other properties?

Yes, when using Particle Flow, you can control the color of each particle freely, but support for the built-in 3ds Max Particle Age map was removed early in the development of Krakatoa for various reasons. We are working on a clean solution to allow Particle Age maps (and potentially other maps written to support particle systems in 3ds Max).
In the mean time, here is how you can control the color and density and your particles:

Krakatoa can use the values written to the Script Vector Channel as particle colors and the values from the Script Float Channel as density. You can set these values using a Script Operator and calculate the colors based on ANY particle properties or even external objects accessible to MAXScript which gives you virtually unlimited shading capabilities compared to the limited Particle Age map. To enable the Script Vector Channel as Color source in Krakatoa, simply add a Krakatoa Operator to your flow and check "MXSVector-->Vertex Color".
To achieve the same results faster, you can use the 3rd party extension to Particle Flow - Toolbox #3 by Orbaz Tech.

You can see examples of both approaches in the following examples:
Particle Color By Speed Using Dataflow
Particle Color By Speed Using MAXScript

Partitioning

Few Large Partitions vs. Many Small Partitions

What is more efficient? Having smaller but lots of PRTs or filling the PRTs as full as your computer can handle.

Krakatoa loads particles into one big pool before rendering them. It does not care much where they came from. So having few huge PRTs or multiple small ones should be the same for the RENDERER, but it would be slower to load many PRTs (esp. from the network) because it involves opening, unzipping and closing a lot more files. If running on Deadline, creating lots of partitions with fewer particles is generally faster - the workload can be split between as many slaves as available, thus more particles are saved at the same time.

Benchmarks

Here are the results of some internal benchmarks.

Rendering 50 Million particles - 3ds Max 9 64-bit.

Saving 5 partitions, 2 frames each, with 10 million particles each using a simple PFlow with Box Icon Type: 300 seconds.
Saving 500 partitions, 2 frames each, with 100000 particles each using the same PFlow: 440 seconds.

Loading the 5 partitions in one PRT Loader and rendering with no lights, no cache: 144 seconds.
Loading the 500 partitions in one PRT Loader and rendering with no lights, no cache: 476 seconds.

This huge difference is caused mainly by memory management overhead (virtual memory etc.). A second attempt right after the first took "only" 253 seconds because Windows X64 already increased the virtual memory and had less to do. Still, a lot slower.

Also note that with 500 partitions, the Particle Loader in the Command Panel is really slow - changing viewport percentage for example could take almost a minute to update, while with 5 partitions it is very fast as fewer files have to be accessed, uncompressed and loaded.

In short - more partitions with less particles are better for speeding up calculations using Deadline, but too many partitions can slow down processing in both the viewport and the renderer due to I/O overhead. There is a sweet spot somewhere between 5 and 50 partitions, 500 is an overkill and a really bad idea, but technically possible.

In Krakatoa v1.1.0, the maximum number of partitions that can be saved at a time has been reduced from 1000 to 100.