Right now the only way to put info onto the map channels is (i think)with a KCM, other than color and velocity.
I have to save particles with krakatoa and then copy my custom channel to some map channel with a kcm… i´d like to do this completely in frost,
telling it to read custom TP/PF channels and assign it to the map channel i want. This way i could see instant results on the mesh
The plans for future Krakatoa versions include PRT objects for each particle source type (right now we have PRT Loader for disk files, PRT Volume for geometry volumes, PRT FumeFX for Fume and PRT Source for 3rd party streams). In the future, we should have PRT PFlow, PRT TP, PRT Geometry (for surface/per vertex/per edge etc. distribution instead of the current “Vertex As Particles” mode), and possibly PRT MaxParticles for the legacy particle systems. (the PFlow, TP and Legacy objects could theoretically be jut one, PRT Particles). So you would create an intermediate object to grab the data from the source system and convert it to a PRT stream (optionally not displaying the data in the viewport). This way, you would be able to add KCMs, deformation, selection and deletion modifiers to ANY particle system’s output without saving intermediate files to disk, and then pick that object as the Frost source.
The reason we want to do this is that the modifier stack above the Frost base object should be used to manipulate the output mesh. We could provide a way to add KCMs to the Frost object that live in some sort of sub-object holder and affect the incoming particle data, but that wouldn’t allow you to easily distinguish between the dozens or so possible sources, and would go against the basic concepts of Max. Also, you wouldn’t be able to apply deformations, selections or Krakatoa Delete modifiers to such a sub-object holder, so our idea sounds more flexible.
For example, you could create a PFlow, a PRT PFlow object, add a Bend 180 degrees or Path Deform to it, then feed back the result into a second PFlow via Krakatoa PRT Birth and Update and you have an instant modifier stack for PFlow systems. Or you could create a TP, get its particles to a PRT TP, apply whatever data and deformation operations you want and feed into a PFlow. (I have a prototype TP Birth operator similar to the PFlow Krakatoa PRT Birth/Update ops, so the opposite direction could also work - create in PFlow, convert to PRT stream and feed into TP without saving to disk).
Since all this would work with the Evaluation version of Krakatoa, it would benefit all Frost users that want to do advanced particle work.
That sounds great for advanced effects, but for simple channel assignment, it sounds pretty convoluted. Like all we might be doing is copying from vsel to radius or whatever, but we’d have to create a new object just to hold that KCM?
If this is the real plan, support for non-Krakatoa sources should be dropped from Frost. So you can only use PRT Loader, PRT Source, PRT Volume, PRT Particle, PRT Geometry, etc. Otherwise we’ll end up directly adding an input source, then making the “KCM holder” object and having to swap them out.
I don’t mind doing a few more clicks to do this, and i could make a KCM preset anyways.
hope those PRT loaders comes soon 
I like how krakatoa is always growing and offers more ways to edit particles… maybe some day Pflow/TP won’t be needed anymore… 
A possible approach would be to provide “dummy” modifiers that can be added to the sources in question and modify their Frost characteristics (I had proposed something like that for Splines for example since they don’t define any radii and it would be great if we could do gradients along the spline to vary the radius and make things like tentacles etc.).
So you would drop a light-weight Frost Source Properties modifier on top of a Geometry object for example, and in the modifier you would check options like “Copy Soft Selection to Radius”, “Multiply Radius by X”, etc. and Frost will use these to modify the incoming stream.
I would rather keep these operations outside of the Frost UI, because it would allow you to modify each scene object independently and merge them all into the same Frost after that.
But then this would mean duplicating the functionality that could be done with a KCM. I would rather allow KCMs (or FCMs ?) to be placed on the stack of Frost sources and modify the point data before it reaches Frost.
Note that FumeFX requires a helper for each source object participating in the sim and nobody has complained yet. So having a dedicated conversion node for each particle source that goes into Krakatoa or Frost wouldn’t be the end of the world. But we don’t have these objects yet and Frost is releasing in a week or two, thus the whole discussion is forward-looking and completely open 
Yeah, it’s tricky. The Frost installer should include Krakatoa, that’s for sure. What you describe as a workflow makes perfect sense, but it means that a HUGE portion of the Frost UI is wasted/redundant when those workflows start working. Which in the beta is fine, but after release you’ll have people complaining about how Frost 1.1 won’t let them directly load PRT’s or splines or whatever anymore.
I agree this is a good idea. I don’t really like that Velocity is a special case – I think you should be able to map any channel in the same way. I’ll add this to our wish list, but this will depend on how the Krakatoa/Frost particle interface develops.
Even without a Krakatoa interface, you could have a “Frost Preprocessor” helper object which does the data swizzling and anything else you need done on the input pointset. Then you would just have Frost support loading of the Preprocessor objects. This would simplify the Frost UI a lot, and allow you to handle multiple sources, each with their own mapping needs. Like MysterySource01 could have it’s vsel converted to radius, while MysterySource02 could have it’s age converted to radius. Or MysterySource01’s Mapping1 could be output to Mapping1, while MysterySource02’s Mapping1 could be output to Mapping2.
This approach would simplify the Frost UI and would allow for much more general data mapping and functions.
But where do you draw the line between simple channel copying and channel manipulation? Would the preprocessor object just have checkboxes to “Copy this to that”, or MagmaFlows to be able to copy, multiply, blend, curve-control and massage the data in all possible ways? The objection to the latter is “it makes things complicated”. My objection to this is “I would rather have flexibility than ease of use, but if possible, both”.
As it is now, any geometry object can accept a KCM on its stack, it just does nothing. If Frost would look for these and evaluate them on the incoming point data stream, we would have the most flexible system with almost no development effort because both the UI and the compiler already exist. Would you be ok with MagmaFlows or do you want it simplified (at this point, ignore what the masses might want and tell us what YOU want).
It’s the “both” that I was envisioning.
The “Frost Preprocessor” would be simple swizzling and maybe some of the basic options like Scale Radius by Age or whatever. The most general stuff. It would not require Krakatoa at all, and could be implemented soon.
In Frost 1.1 and Krakatoa 2.0, you could improve the Frost Preprocessor objects to support KCM’s in it’s stack. So the flexibility would eventually come for people willing to wait and willing to install Krakatoa.
EDIT: Just read the second paragraph you wrote again, but this time understanding what you were saying. If the KCM “support” was there, and the licensing was ok with it (which I think it is, just need to include Krakatoa in the installer) then it would be a good solution. It’s not THAT complicated to use, and for most of us, it would be EASIER since it is an interface we already understand.
In my immediate use case, megadalton molecular simulation meshing , I want to have a means of doing:
Both can be done from a KCM easily. Neither can be done currently any other way. And supporting both in the Frost UI would be overkill.