I am wanting to matte a camera map per pixel Krakatoa particle cache on a plane (before caching, so no particles are generated that are in the alpha).
My setup:
*Particle birth with the position object being a plane
*A material dynamic node with the camera map per pixel png sequence with alpha
I feel like I am missing something simple, so here I am. 
Thanks,
Nick
Can you restate your problem as a series of steps?
I was not able to follow your workflow.
Sure thing.
Create a preset flow
set birth to 3 million
create a plane object
create a position object in the flow, and select the plane object
create a material dynamic node
assign a camera map per pixel map with an RGBA (png with alpha in this case) image sequence to the diffuse slot of a material
set the material to 100% self illuminated
assign the material to the material dynamic node
cache the particles to a prt file, making sure to save position,color, id, and velocity channels
create a new empty flow, and turn off the original flow
add krakatoa prt birth and prt update nodes to the new flow
create a prt loader and point it to the cached prt file
point the prt birth and update to the prt loader
render and see the projected image sequence.
What I want is to have the prt cache to not save particles that are in alpha.
That was a great step-by-step description, thanks!
The main issue with this setup is that the RGB of the map is evaluated as Color, but the Alpha must be evaluated as Density. As long as the same map is in the Diffuse AND the Opacity map channel, this will happen automatically in PFlow when you render directly or save to PRT sequence. So you would see the Alpha being transparent where expected if you render the PFlow, and if you include the Density channel in the PRT files, the particles will have a Density of 0.0 where the Alpha is black when loaded back in the PRT Loader.
The problem comes when you try to bring back that information into PFlow because PFlow has no concept of a Density channel, and Max has no channel to dump that data into. You have two options here:
Delete the particles.
Just drop a Magma modifier on the PRT Loader, set a flow that inputs the Density, compares it to 0.0 using an Equal operator, converts the result to Float and outputs as Selection, and then add a Krakatoa Delete modifier on top. All particles with Density 0 will be gone (which will also speed up rendering!). Then just load the particles into PFlow, add a Material Static with a Standard Material and a Vertex Color Map in the Diffuse slot and the Color channel will appear as RGB. This works best if you have a “binary” alpha - either 0 or 1, no grayscales.
Copy Density to a Mapping Channel.
In this case, the Magma modifier would take the Density, convert it to a Vector and output as Mapping2 or another mapping channel. Then you load that data into PFlow and use a Vertex Color Map set to the same channel in the Opacity map slot, so the values from the Density would propagate to the new PFlow particles via the material’s Alpha. This will work with any Alpha grayscale values, but invisible particles will still be created and processed even if they have a value of 0.
So you could do both approaches, copy the Density to Mapping AND delete any Density == 0 to only deal with the visible particles and still get all the various Alpha values over…
Hope this helps! (I tested it in Krakatoa MX 2 and it worked)
Thanks, Bobo! I’ll give it a try.
On a somewhat separate note, but a bit related:
I am noticing after caching particles to a prt file, and loading them in a new flow and prt loader, they are not copying the timing of the original pflow they were made from. So the movement of the particles in the prt file plays back right, but the timing happens over a much greater number of frames. Is there something I missed? Or a way to correct this easily?
Not sure what you are seeing there, but I would suggest making sure your Viewport and Render Integration Steps match. If you are saving in Render mode with two updates per frame, but the viewport is set to one, what you are loading later will not match the original animation in the viewport. Also the PFlow using a PRT Loader will always be an integration step ahead because PFlow will add the Velocity to the Position after the sequence has been loaded.
Does the animation shown by the PRT Loader itself match the source animation of the original PFlow system?
In general, we don’t recommend loading PRT files into PFlow unless absolutely necessary. Rendering the PRT sequence is what we do 99.9% of the time. Just because we provide these bonus tools to bring back particles from PRT into PFlow does not mean it is without problems 
Hey bobo,
I would you be able to post a sample file for (1.) deleting the particles? I am missing something in my steps I think.
Thanks,
Nick
The animation shown by the PRT Loader itself does seem to match the source animation of the original PFlow system. The integrations steps are both “frame”. I’ll keep poking at this…
If you are running Krakatoa MX 2, you can also copy the following and paste it into an empty Magma modifier:
(--MAGMAFLOW2--
global MagmaFlowEditor_EditBLOPHistory = #()
node0 = magmaNode.createNode "Output"
magmaNode.setNumNodeInputs node0 1
magmaNode.setNumNodeOutputs node0 0
magmaNode.setNodeProperty node0 "channelName" "Selection"
magmaNode.setNodeProperty node0 "channelType" "float32"
magmaNode.DeclareExtensionProperty node0 "Position"
magmaNode.SetNodeProperty node0 "Position" [100,100]
--------------------------------------------
node1 = magmaNode.createNode "InputChannel"
magmaNode.setNumNodeInputs node1 0
magmaNode.setNumNodeOutputs node1 1
magmaNode.setNodeProperty node1 "channelName" "Density"
magmaNode.setNodeProperty node1 "channelType" ""
magmaNode.DeclareExtensionProperty node1 "Position"
magmaNode.SetNodeProperty node1 "Position" [24,30]
--------------------------------------------
node2 = magmaNode.createNode "Equal"
magmaNode.setNumNodeInputs node2 2
magmaNode.setNumNodeOutputs node2 1
magmaNode.setNodeInputDefaultValue node2 2 0.0
magmaNode.DeclareExtensionProperty node2 "Position"
magmaNode.SetNodeProperty node2 "Position" [164,15]
--------------------------------------------
node3 = magmaNode.createNode "ToFloat"
magmaNode.setNumNodeInputs node3 1
magmaNode.setNumNodeOutputs node3 1
magmaNode.DeclareExtensionProperty node3 "Position"
magmaNode.SetNodeProperty node3 "Position" [304,0]
--------------------------------------------
try(magmaNode.setNodeInput node0 1 node3 1)catch()
try(magmaNode.setNodeInput node2 1 node1 1)catch()
magmaNode.setNodeInput node2 2 -1 1
try(magmaNode.setNodeInput node3 1 node2 1)catch()
--------------------------------------------
)
Then drop a Krakatoa Delete on top of the stack.
Thanks, Bobo! Checking this out now.
“As long as the same map is in the Diffuse AND the Opacity map channel, this will happen automatically in PFlow when you render directly or save to PRT sequence.”
What image file format is recommended to have Diffuse and Opacity map channel in one? So far I am not having luck with .EXR or .PNG (both with alpha) in having Opacity (density) be automatically calculated/exported to prt. Maybe this is related to the fact that I am using camera map per pixel projection?
I also tried caching the density channel in the prt to try the magmaflow delete 0 density particles, but when I load the prt, the density channel is not there.
Would you be able to post a single-frame max file with a texture file for me to pick apart?
Thanks,
Nick
I used an image that I had rendered which had an Alpha channel. When you instance a Bitmap texture in Max, the Opacity channel takes the Alpha by default. Anything with Alpha should work - TGA, PNG, EXR, RPF.
Krakatoa ALWAYS multiplies the Density by the Material Opacity, so I got the Density of 0 where the Alpha was 0. I used Per Pixel Camera Projection in my test, too.
The Density channel is set to save by Default when using Krakatoa, unless you removed it explicitly, it should be there. If there was no valid Alpha, it might default to 1.0, but it definitely should be in the PRT file sequence when using the default saving settings (Position, Velocity, Density, Color, Normal, ID). You could remove the Normal for your case.
I don’t have the scene I tested with, and I won’t have the time today to make a new one. You must be missing a very simple step somewhere, because it is really totally straight-forward.
Got it all working now. Thanks, Bobo–you rule! 