Here is a “short” rundown of how the new operators can be used:
VERY IMPORTANT: In order to be used in the new system, the particle sequence MUST contain an ID channel (which represents the Born IDs in PFlow, but is also available by default in RealFlow BIN files, and can now be saved from Thinking Particles correctly without gaps).
To test, create a simple PFlow that emits particles over multiple frames and add a Delete operator to delete particles after some time. To get variable speed, set the Speed operator to reverse so the particles move up, then add a Force and select a Gravity space warp so the particles resemble a fountain…
Open Krakatoa, set to Save Particles To File Sequence, specify a location, right-click the SAVE button and set the time range to 0-100 and press SAVE to save the sequence.
NOTE that by default, the ID channel is now included in the Channels To Save list. If you don’t intend to load a particle sequence into PFlow again, you could remove it before saving, but we feel it is a better idea to have it there by default. You can change the default list by opening a fresh Max scene, opening Krakatoa GUI, removing the ID channel from the list and saving the settings as new defaults via the “Save Current Settings As Defaults…” in the Preferences rollout.
So now you have a particle sequence containing particle birth, death and IDs. The old set of Krakatoa PFlow Operators would not be able to correctly recreate such a flow. The new ones can:
*Create a new default system.
*Drag a Krakatoa File Birth (1.1) operator and replace the default Birth operator.
*Remove the Position, Speed and Rotation operators, leaving just Shape and Display.
*Select the file sequence in the Krakatoa File Birth operator.
*Drag the time slider - you should see the particles getting born at the original place. New particles will be born at the correct times, but no particles will die yet. The initial position and speed will be set, but no further updates of position or speed would be applied, so if you had variable speed and forces throughout the animation, they would not match. If the particles had constant velocity throughout the animation, the result would be pretty close to the original.
*Now let’s apply a Krakatoa File Update(1.1) to the event and select the same file sequences.
*By default, the operator will load only Positions (which are typically always available in a PRT or BIN file) and the IDs.
If you drag the slider now, the positions will be updated on every frame.
*To also update the Velocity channel of the particles, press the Channels Setup button in the Krakatoa File Update operator - a large floater will open, showing all available channels:
The checkbutton shows the name and data type of the channel. You can check the button to load the channel or uncheck it to skip it.
The color indicator to the right of the button shows the arity -
Red = [1] (Float16, Float32, Int16, Int32 like ID and Age)
Green = [2], (currently none)
Blue = [3], (Float16[3], Float32[3] like Position and Velocity)
Yellow = [4] (Float16[4] like Orientation)
The drop-down list shows the target channel to load the data into. By default, it will be the same channel that was saved, so Position loads into Position and so on. You can use the list to retarget the data into ANY other channel of the same type, so you can load Velocity into Color, Position into Mapping42 and so on.
The next drop-down list defines the type of mixing operation between the existing data and the loaded data - either Blend or Add. It works together with the spinner value. For example, if the settings are the default Blend and 100, 100% of the incoming data are placed into the channel, replacing all existing values. If set to Blend and 60, 60% of the file data will be mixed with 40% of the existing target channel data. If set to Add and 10.0, 10% of the file data will be ADDED to the existing value in the channel, increasing its value on each frame.
The spinner is animatable and will be stored in a Bezier Float-controlled channel in the File Update operator, visible and editable in TrackView.
The >> button currently has only one menu option - delete all keys, which removes any animation in the channel’s controller and resets the value to 100%.
Any changes made in this dialog apply immediately to the operator - it is not modal so you can tweak settings and play back the animation to watch the result instantly.
You can use multiple File Update operators to load the same channel into multiple target channels, as needed. You could have one operator loading just the Position, Velocity and ID into the same channels, while another loading only Velocity into a Mapping channel for example.
NOTE that the ID channel will be loaded and used even if the ID channel button is disabled, because it is needed internally for generating a special FileID channel to control the death of particles!
Let’s check the Velocity channel in the setup dialog - the speed of the particles will also be applied to the flow. (There is a slight difference in the particle positions between source and reloaded system caused by the way integration is performed by PFlow after the operators have been processed which will be addressed in the next build).
NOTE that when you save a PFlow to disk, you are saving the RENDER settings, so by default the saved particles will use Half Frame step, while the viewport is set to Frame by default. To compare the positions in the source and reloading systems correctly, you have to make sure the viewport settings match the render settings, otherwise the results would be slightly different.
Also NOTE that in order to process the file particles correctly, the File Birth operator HAS TO load 100% of the particles because otherwise the IDs would be off. The Viewport spinner is completely ignored. If your sequence contains millions of particles, your only chance to show less in the viewport is changing the “Visible %” in the Display Operator.
So now we have our saved particles being born and moving like the source, but they never die. To solve this, we have to add the third operator from the set - the Krakatoa File ID Test.
When the File Update operator processes particles, it creates a FileID channel and stores the IDs loaded from the file in it. It also compares the IDs of all particles currently in the system with the IDs in the current PRT or BIN file and finds out which IDs are not in the file but in the system - these particles must have died and are thus marked with an ID of -1 in the FileID channel.
The default setting of the File ID Test operator is to send out any particles with an ID < 0. These are exactly the particles that should have died according to the File Update operator! Simply add the Test to the event, wire to an event with a Delete operator and the particle system will look exactly like the original, with particles being born and dying at the right times.
You do NOT have to kill the particles with negative IDs, for example you can disable the Delete operator and if the Display operator of its event has a different color, you will SEE which particles should have died. You can do whatever you want with these particles, but the typical solution is to just delete them.
The File ID test can also be used to select particles with IDs in a range of values, for example all particles with IDs between 1000 and 2000. While this does not have a suggested practical usage, it gives you more flexibility to split portions of the loaded particles by FileID.
These three Krakatoa PFlow Operators work as a system for dynamically loading particle sequences with changing particle counts.
Another new operator which comes with Krakatoa but is somewhat unrelated to the previous three is the Krakatoa Geometry Test. It implements the Particle Culling feature available in the PRT Loader as a PFlow operator. You can pick one mesh object in the operator (typically a convex, closed volume, a Teapot is a BAD case like with PRT Loader culling) and send out
–all particles that are inside of the volume
–all particles that are outside of the volume
–particles that are EXACTLY on the surface (this usually finds no particles but is useful when used with the Distance Threshold)
–all particles inside/outside/on the surface AND particles that are closer than the threshold to the surface (grows the selection away from the surface)
–all particles inside/outside/on the surface AND particles that are farther than the threshold (this keeps the particles close to the surface and sends out the rest, like in PRT Loader)
You can send the particles to any other event using this test, for example to be deleted, or affected by any other operators. It tends to be faster and more precise than the mesh volume selection methods available in Box #1 so we decided to throw it into Krakatoa as a bonus.
The last Krakatoa Operator is the Options which was available before. The only change is that it has a nicer icon now.
This does not cover all options available in the operators, but should give you an idea how to use the new versions to deal with dynamic sequences.
Since the Krakatoa File Birth is going to override the % and use 100% all the time, what happens if our PRT file has more than 10M points?
- Chad
>Since the Krakatoa File Birth is going to override the % and
>use 100% all the time, what happens if our PRT file has more
>than 10M points?
>
>- Chad
Bad things would happen, I guess...
We did not design PFlow, so it is more a question for Orbaz.
We are looking into adding channel retargeting to the PRT Loader now, so you should not have to use PFlow to do typical Krakatoa-sized processing (10M+ particles).
> (There is a slight difference in the particle positions between source and reloaded system caused by the way integration is performed by PFlow after the operators have been processed which will be addressed in the next build).
Just a note that we decided NOT to attempt to work around this problem.
The problem was this: The operator loads both the FINAL position of the particle for the current frame AND its velocity. After PFlow updates all operators, it integrates with the current time step and velocity and comes up with a NEW position which is offset from what is in the file (and in the original system).
A potential solution would be to load positions from one frame earlier and let PFlow integrate, but when not loading the Velocity channel it would require a different approach, complicating the code and possibly causing more problems.
You must realize that loading the positions in the Krakatoa File Birth just once and then updating ONLY VELOCITIES without reading the Position channel should lead to results IDENTICAL to the original system (assuming you are loading in Blend mode with 100%). This is the desired setup when loading velocities because if you wanted to mix your pre-saved animation 50-50% with, say, another sequence or velocities created by Speed or Force operators in PFlow, loading absolute positions makes absolutely no sense. Thus, if you set up your system to load Velocities, you should always uncheck the Position channel and the above problem would be solved as a side effect...