I have a PRT Loader where I load particles having color channel.
When I get these particles into PFlow it looks like I am losing color - either on render time or while saving to drive as PFlow assigns them color from the event color picker.
What do I need to preserve color (and possibly other channels) in PRTLoader > PFLow > .PRT Sequence > PRT Loader workflow?
Is the Color channel checked in the Krakatoa PRT Update operator in PFlow?
To bring over PRTs, you need two or three operators:
*Krakatoa PRT Birth only creates particles and sets the Position, Age and ID channels.
*Krakatoa PRT Update can update all other channels that PFlow knows about.
*Krakatoa ID Test can send out particles that have been deleted dynamically and don’t exist in later PRT frames. This is only needed when loading sequences with particles that are being deleted…
You need the first two to bring over ALL data. If you want to update just once, put the Krakatoa PRT Update in Event001, then send out all particles to an Event where there is no PRT Update to control them with other operators…
I don’t have such node.
I have Krakatoa Birth from file only.
See my updated post above!
Thanks.
Now I remember I had issues in the past loading and instantiating particles from PRTloader in Pflow only once on the first frame.
I understand what you suggested above solves the issue?
Ok, Ember Selection works like a charm.
Krakatoa loading and updating too.
Now a million dollar question:
Is there any option of saving custom data from Pflow into Krakatoa .PRTs?
Particularily, I’d like to save information about in which event the saved particle is.
That is actually an easy question.
You can abuse ANY channel to store that info. The way I propose usually is to add a Mapping operator to each Event.
In the Mapping operators, set a Mapping Channel 2 or something like that (unused for texturing).
Enter a U value of 1.0 in the first event, 2.0 in the second, 3.0 in the third and so on. Arbitrary data, really.
Save to PRTs with Mapping2 added to the list of channels to save.
Then in PRT Loader, add a Magma, add an InputChannel:Mapping2 and use a Breakout to split the vector into X, Y and Z.
The X will give you 1.0 if the particle was in the first event, 2.0 if it was in the second etc… You could even convert that value ToInteger and pass it to the control socket of a Mux operator. Set the number of input sockets to about the number of events and you can now pass a different value depending on the particle’s event “ID” coming from the Mapping2 channel… Or you could simply use Switch and Logical operators to compare values, or use the value directly as needed.
You can use the other 2 components of the mapping to store other info about the event if there is any.
Many thanks. Just trying this out now.
I still have issues with getting a single representation of my static particles set from a PRTLoader, updated but not populating each frame.
So I have a PRTLoader and it loads only a single frame.
In my PFlow i have Kraktoa Birth and then Update in one event. Then sending out to another event.
It looks like the system is constatnty producing full dataset in Pflow at the beginning of each of frames. Each new rendered .PRT contains double the amount of previous one.
The condition for these Krakatoa operators to work correctly is to have a valid ID channel. If you don’t have IDs in your PRT files, then it won’t work right because it cannot track which particles were born already and which are new.
If you don’t have a valid ID channel from your original saving, you might have to produce an ID channel using Magma - feed the Index InputChannel into ID Ouput and hopefully the PFlow will start working correctly…
Does not work if Magma is in modifier stack. Looks like either I missed something or need to resave.
Define “does not work”.
PFlow operators should work with as many Magmas on the stack as needed, as long as the Magmas are correct.
Are you getting an error anywhere?
Does it crash?
I have a PRTLoader in the scene and added Magma on top of that.
This PRTLoader is fed into Krakatoa Birth and update in Pflow.
I did not see an option of adding Magma to PFLow - its not visible on the Modifiers list, but anyways I understood I should add it to PRTLoader.
And no, I am not getting any errors.
Also, I have selected ID channel in the Updater.
Is my PFLow OK? Maybe I missed something.
It does work though if ID is written into file.
Yes, the Magma would be on the PRT Loader, and its content would be Index->ID.
I would expect the Krakatoa PRT Update to “see” the new ID channel after that, and only create particles on the first frame.
The alternative is to set the Range in the PRT Loader to 1 to 1 and switch the condition from “Hold Last” to “Blank”.
As result, the PRT Loader will pass the particles to PFlow only on one frame, and then produce 0 particles on all other frames.
This way, no ID channel would be needed.
But I could be wrong, because 0 particles could confuse PFlow about the actual channels content of the loader. I hope it would work.
Unfortunately, I am preparing to travel to LA for Maya Demos, and I will be unable to help you any further this week 
Thanks for everything and good luck.
Looks like I’ll need to find my way.
Finally the only approach that seems to work for single instance of particles from Loader to PFlow is range as you suggested.
However, I think there is some kind of bug which you may want to look into.
Losing color issue
So I am pushing 20MLN particles from a PRTLoader, all containing color and IDs through the following PFlow.
I have Krakatoa Update in the flow as suggested.
I am using an Ember based noise selctor to trigger the event flow in Particle flow.
I got rid of partitioning workaround we discussed in the other topic since mysteriously half of my particles got lost due to it.
So everything seems to look correct workflow-wise.
The issue is that for some reason when I push these particles through the system random particles loose color and I get 0,0,0 in the output file.
It is not related to the event that particles are in at the moment.
ID override
The other question I have is why this workflow does override particle IDs on output?
My input data for the PRT Loader has IDs. ID channel is activated in the Krakatoa Update in PFlow and ID is added to save channel.
However, on output I get a new series of IDs that seem to be incremental starting from 1 and this seems to come either from PFlow or from Krakatoa not getting proper IDs from PFlow.
PFlow to magma
Lastly, I wanted to ask if there is a non-file solution for applying Magma modifier on the PFLow data.
I can’t assign Magma to PFlow in modifier stack as I don’t see it on the list.
I tried using PRT Source and assigning a PFlow as an input and adding Magma to the stack of PRT Source, but for some reason this PFlow does not pass any particles to PRT Source.
So the only option I figured so far was saving from PFlow to PRTs and then applying Magma on the loaded data.
Did I miss something obvious or that’s not possible at the moment?
Looks like I found the problem reason for losing color.
The bad guy is an Ember Follow that is used only for selecting particles.
There is something strange about Ember that is related to Ember’s Initial state vs simulation.
I have the following Ember Magma for selecting particles. It is assigned to simulation slot and while my initial state was empty I was not getting any error and I was able to see the field in frame 0 and all other frames, but the random losing of color in PFlow was happening. When I added a simple assignment of 0 to Ember’s Initial State Magma, the problem disappeared.
FYI - This is one of many situations where I see issues arising from Ember and related to sim vs initial state. I also find it pretty confusing and I think you could consider revising the concept of 2 different slots in Ember or making one of them req’d and the other one optional. I see many situations where you only want to create a static field or your simulation is not dependent on any initial state. Having 2 Ember slots is pretty confusing and causes issues very often. Also, the relation between these 2 slots could be documented a bit better - maybe it’s just me doing something wrong.
The Color problem could be a bug, thanks for reporting it.
The ID channel behavior is unfortunately As Designed.
The IDs coming from the PRT Loader are dumped into a new internal Krakatoa-specific channel. You cannot tell PFlow to override its own IDs, they are generated automatically when a particle is born and there is no way around that. So the Krakatoa PFlow operators use the existing ID channel from the input PRT Loader only to determine when a particle should be born or when it is supposed to die. It works like this:
The Krakatoa PRT Birth reads the stream from the PRT Loader and looks at the ID channel and the special Krakatoa ID channel. If an ID from the PRT Loader is not found in the Krakatoa IDs list, the particle is new and should be born. If the ID is found in both, it is already born and nothing should be done. If an ID is NOT in the PRT Loader but it IS in the Krakatoa ID channel in PFlow, that particle was obviously deleted in the original simulation. At this point, the Krakatoa ID will be set to -1, and a Krakatoa ID Test can check for negative IDs and send it out for deleting…
While all this is happening, each new particle born by Krakatoa PRT Birth will receive its own PFlow-specific ID that does not have to match the incoming ID from the PRT Loader. If you save to new PRTs, the new PFlow ID will be saved, not the incoming ID from the PRT Loader.
We know there are a lot of gotchas in this workflow, but we have the constraints of the PFlow system and have to play by its rules…
