The PRT Mesher already propagates all relevant channels from the particles into the mesh including Color (to Vertex Color), Texture Coordinates and Velocities (using two different interpolation methods). I am not sure if I understand correctly what you are proposing, but I think we do most of it. It works very similar to the way PRT Volume propagates mesh data into the particles, just the other way round.
I meant back to the particles. So a particle could be marked with a float16 for distance from surface, or a float16 for spatial density, etc. You could probably get course particle normals too, with little effort.
- Chad
The levelset data could also be used directly, or filtered, as a map for texturing particles.
I think that some dedicated LevelSet Operators inside the KCMs would be a great thing to have in addition to the planned kdtree Operators when it comes to acquiring data from geometry. For the Nanomites in G.I.Joe we used a LevelSet of the cloud to acquire the normals back into the particles for environment reflection purposes, so we sort of have some experience with what you suggested. I would love to at least have a built-in option to create normals for any particle cloud that does not have any, but I think a KCM node would be a lot more flexible since it could return the data where you need it.
But KCM’s don’t sample particles, so you couldn’t generate gradients, density functions, depth functions, etc. You could read levelsets in, yes, but making them is the part we are missing now (whereas we can do these sorts of things with Box#3, just much more slowly with highly dense particle systems because we don’t have the reduction efficiency from the levelset).
- Chad
KCMs don’t sample particles YET.
As time passes, we should get the ability to perform pretty much anything you can do in Box #3.
Things I would like to see in KCM in the future:
*Geometry kd-tree based operations with finding closest point to surface and all its properties
*Finding whether a position is inside or outside a geometry volume (using either the current kd-tree approach of PRT Loaders or the LevelSet approach of PRT Volumes - possibly the latter). This could be implemented even by simply populating the SignedDistance channel where negative values mean inside, positive mean outside and the value represents the closest distance to the surface - a Switch node with SignedDistance < 0 could provide the boolean result for selecting particles inside the volume, then a DeleteParticles modifier could use the selection to cull the particles.
*Acquiring interpolated values from geometry objects using LevelSet the way the PRT Volume samples normals and mapping coordinates.
*Accelerated access to neighbor particles for finding out densities and gradients.
*Loading particle data at alternative times for things like extrapolating missing velocities from two consecutive frames’ positions etc.
At least the first two points are on the plan right now because we want to move the culling to the stack and restore Yost’s Will.
erm…yay…consider me speechless and sitting tight 
Regards,
Thorsten
That would be so nice.
- Chad
Another idea about sampling would be to take a high density PRT, and have the KCM sample a low density PRT that has channels missing from the high density one. Using MSL or RBF methods, or even just doing N-nearest with a weight based on distance… So lets say you sampled something expensive, like global illumination, but wanted to distribute that sampling to a large number of points, some method of sampling between PRT’s in a KCM would be nice.