I don;t know if it has been brought up yet but will Frost be able to generate a WetMap?
Glu3D has a feature to generate a b/w image sequence where particles made contact with any mesh listed as collison object. Also it has adjustments for “drying time” to fade back to black after X amount of frames. That’s pretty handy at times. I know that is more of a glu3d rather then their pwrapper feature but i’d love to have that where iso surface made contact. 
-Ansi
I second Ansi on this one.
Mapping control/features are a must when dealing with interactions - whether its literally a wetmap or system that allows the proximity of a mesh to influence the texture/shader on another.
Its not a huuuge pain to set it up manually, but its nice to have a built in native frost feature.
I currently setup such an effect using vextexmapping or AO and then rendering the resulting, apparent psuedo interaction out as a rendermap sequence which can be tweaked in post to. then loading this map sequence back into a mask/mix channel.
matt
Yes, this is a good idea. How important is this for you in the first release of Frost?
While I love the idea, I think it would be better solved with a general purpose Modifier that can record mesh interactions / intersections and produce the data that Frost and any other object could then access. This could for example apply to a Teapot intersecting with a Bermuda mesh where the intersecting part gets “wet” and could be used to emit particles based on that map using, say, PFlow, a geometry object covered with Frost particles could get wet where the two intersect and so on. The Modifier could record how long the intersection lasted and apply more or less “wetness”, and remove the data over time according to user settings to “dry out”, possibly even use another mesh as a dryer that removes wet data instead of adding and so on.
In fact, I think an advanced, kd-tree based Volume Select with a History Dependent Wet Map option should be developed to replace the painfully slow and abysmally ugly code-wise (but otherwise awesomely procedural) VolSelect that ships with Max. It could be part of FROST or a separate product (I think part of FROST would be great from customer’s POV). Possibly in v2.0?
We had some code for wet maps from Flood, wonder how much of it could be reused for a more generalized solution…
Sounds interesting. A seperate modifier feature opens up the possibility of using it more generally - not just for wetmap interaction. vertex mapping support aswell as uvw’s would be cool. A proximity detection that paints into the vertex channel would be great. This depends on topology a little of course, but it takes little effort to compensate for this. Vertex colour maps can be a bit slow in max however. Ive often used and built ICE compounds within Softimage such as proximity lookups and mesh weight painting. Actual mesh selection via proximity aswell would of course me useful.
I love the modifier idea as well!
This could solve the “how do I pass particle data from PRT Loader/Source/Volume to Frost to PRT Volume?” problem. Sure you can resample the positions of particles to turn a sparse system into a dense one, but how do we get the rest of the data channels sampled?
Right now we in theory could store various PRT channels in vertex color and mapping slots in the Frost mesh. There would be a memory hit, but it could work on a per-vertex basis.
But a general purpose “Sample points to a voxel array, filter, then apply to mesh vertices or store as a map” modifier might be more flexible.
I this something that could possibly be in a 1.x release already?
This won’t be in the first release, but I’ll make a note that you’re interested in it.
Thanks! Appreciate it 
Ansi
Add another one for interested 