Is this possible or could it be possible? Did I miss something?
I have a few events yet I would like to cache out the first event and the second event separately. The second event particles are obviously dependent upon the first event but require a completely different look than the first event particles. Any ideas?
It is already possible, and is even outlined in the FAQ.
It is not supported automatically though (we have a Wishlist item logged about automatically saving each Event to a separate PRT sequence).
You put a Render operator in the events you want to save (or the ones you don’t want to, depending on which ones are fewer).
You set the GLOBAL Render operator to one mode (say, Phantom), and the local Render operators to another mode (say, BBox or Geometry, just not None).
Then you enable the type of the local operators in the Krakatoa Main Controls rollout and disable the type of the Global Render operator.
As result, the whole PFlow will be updated, but only the particles of the events specified for saving will be saved.
Note that Render operators are ALWAYS evaluated as Global First regardless of the UI settings, so a local Render Operator will ALWAYS override the global mode.
The None mode is not shown in the Main Controls rollout so you cannot filter by it, but if you have two PFlow systems dependent on each other (for example a Proxy system and another one with Box #3 using that data), you can set the Proxy system to type None which will cause Krakatoa to send an update request to it, but not save any particles from it, allowing only the second system to save to disk.
Excellent! Thank you 
Man the docs are getting huge, any chance of a search function? 
You can also just save some unique identifier channel for each system. Makes huge PRT’s that you can then sort with KCM’s into smaller PRT’s by testing against them.
Well it is all one system but now you have sparked my curiosity, How? Something like assigning a unique integer payload to all particles per system them dump them into a ‘output new’ data channel in box#3? IE system one integer payload would be 1, system 2 would be 2, ect. If so, this may seem naive, how do I tell the channel to write to PRT and how do I read them in a KCM? (the latter I imagine I could figure out if I knew I was writing a channel correctly) I know I’ve got those 90+extra mapping channels and alas I hate to admit never used them 
LOL, seem it would be nice to have a box#3 Krakatoa Output sub-operator
We don’t support custom channels from Box #3 yet.
But you can write to any other channel that is supported, like the MXSInteger or even any Mapping Channel.
So have a Box #3 DataOp in each event that sets all particles’ MXSInteger channel to a value of 1, in the next event the same operator with a value of 2 and so on.
Then in a KCM, you can affect your particles based on that value, as long as you saved the MXSInteger channel from PFlow. Or you could set the selection channel in order to Delete or Deform just those particles that came from Event X.
I am halfheartedly glad you said that, if it was in the docs, I would have had to take myself out to pasture. I did see the “Passing Data Between KCM and DataOp” but that was it, wrong direction. Does the Box#3 SDK allow you to build sub-operators?
Ah good idea, I will definitely give the Integer channel a shot, I was using it for something else but that can be easily changed, I think.
Yes, we “just” have to find time to implement something.
We consider it lower priority because there is a huge amount of channels we do support already and you can use any of them to transfer the data.
It doesn’t HAVE to be integer, even if you will essentially use it as such. It could be something like Mass or something else you aren’t using.
I looked up the channels page, needs a little update, it hasn’t seen some love since you guys added all the Fume + channels.
So were is the Mass Channel coming from? Box#2?
Got integer working just fine with a kcm switch, so particles with integer payload of 1 retain original color and particles with a payload of 2 are modified (of course after subtracting 1 since the switch uses 0 and greater than 0), forgot to add the age channel going to have to resave PRT, and tweak again.
We have never listed all channels that could appear on the Channels To Save list since there are so many.
Some of them are typical for RealFlow, some are from Fume, I think “Mass” came from RealFlow (in a KCM, it actually tells you where the channels are typically used when you select them).
The list of channels we can acquire from PFlow is currently hard-coded. I am pretty sure “Mass” was added by Box #3 even before Box #2 came out (possibly to allow for Box #2 tweaking), but I have not tested whether it gets populated by that channel’s value when saving. If Chad says so, it probably does…
I just meant that Mass wasn’t a “Custom” channel. Seems it is a box#3 thing, though. Guess you’d be stuck using the int/float/vector (whichever is free).
Gotcha, there was some confusion on my part because you can populate a Mass Channel in box#3 with a Output PhysX sub-operator. Though the Mass channel is indeed labeled as Realfow. So in all reality I doubt it is accessible.
I am trying with some success to just be able to identify particles in certain events with box#3 so I can color them via a KCM, instead of saving out a slew of different PRT’s and adding a bunch of individual KCMs, which would certainly work too but because of the dependencies it seems just as easy to save them out to a single PRT, control them with a couple of switches to route them down different color paths.