Fun stuff! You can take Krakatoa PRTs, make a Frost surface, then use that surface in a KCM to sample the (un)signed distance and multiply that by the color channel. Makes handy “depth cue”. It’s a lot of clicks, of course, might have to see about automating it…
Another fun thing I did was use Frost to make a culling object to allow me to “subtract” one PRT from another. Very handy.
Next, I’m going to try baking curvature or lighting or ambient occlusion into the Frost mesh, swizzling it into the UVW1, and sampling it from the SurfDataValue to color.
Frost and Krakatoa, sitting in a tree, K-I-S-S-I-N-G…
Yes, they are a great couple!
What we started using it here for is meshing a fluid sim, then filling the resulting mesh with PRT Volume (next build of Frost has the option to copy the Velocity to an arbitrary UV channel so I can use a KCM to assign velocities to the PRT Volume particles). So a fluid simulation of 600K particles can be upresed to 6 or 60 million without the simulation overhead. Makes for a great foam…
Would the next build of Krakatoa have an interger input for texcoord sampling so we could grab something other than UVW1? Vertex color would be nice too.
Funny, I first tried the Frost/PRT Volume combo to down-sample a particle system… I didn’t have random distribution, so Nth wasn’t working, but I could build a low-density PRT Volume that had even spatial density from a Frost that was sampling a high density PRT that has very uneven spatial distribution.
I wonder if it would be helpful to make some of scripts like Krakatoa has, like “Create Frost object from selected Object(s)” or whatnot. Another thing that might be helpful would be a script to submit a Frost object to mesh on Deadline and output a RF BIN or Boomerlabs SuperMesher cache. I’m getting ahead of myself here.
Yes, Frost will provide additional icons similar to the Krakatoa ones to create objects from selection etc. I haven’t written anything yet, but I always intended to.
RF Mesh BIN doesn’t sound like a good candidate to me (judging by the mess the Particle BIN format is).
We have our own implementation of a SuperMesher-like toolset called XMesh which is production-proven. It stores everything TriMesh can have (vertices, faces, velocities, all 100 UV channels, Material IDs, Smoothing etc.) and has some bells and whistles like the ability to save sub-samples for closer rotation interpolation, the ability to use particle velocities to produce mesh velocities for correct sub-frame interpolation without changing topology and so on (right now these features apply to Thinking Particles, but I think support for PFlow would be something to add, too). There is also an XMesh implementations for Maya and Softimage and it has been used in the Frantic Films / Prime Focus pipeline for years to bake geometry before passing it to LnR. And it supports baking on Deadline, of course
Frost already supported saving to XMesh and to Flood RLS level set files, but these were removed from the Beta. So technically there is a solution for this, but I am not sure if it will be in the shipping v1.0 of Frost.
Now this example has gotten be excited. I even had to tell my girlfriend…who shrugged and called me a nerd.
ah well. Anyway - really interesting concept. I have always loved to use the krakatoa skin wrap with PRT volumes and meshes so the idea of transfering velocity over to volumes has given me alot of ideas
I’m wondering why we need the mesh for PRT Volume though… Seems like you could do the sampling that Frost does, filter it with the available Frost kernels, and then use that voxel / level set data to build new points using the PRT Volume distribution methods.
We don’t, and something similar has been on the Krakatoa ToDo list for a while. Originally, Frost was also on the Krakatoa roadmap as a 2.0 feature (as requested by nearly everyone if you remember ). Now that they are two separate (but loving) products, it means there is an additional developer (Yay Paul!) that could help expand the toolset.
Here a PRT Loader with only Position is used to make a Frost mesh.
The Frost mesh has lighting copied to UVW 1.
Then a PRT Source references the PRT Loader.
A KCM applied to the PRT Source samples the lighting and (un)signed distance from the Frost mesh to make what you see below.
You could also sample face normal if you wanted, to do your lighting/shading in the KCM, but you wouldn’t get global illumination.
Any preference as to how this should work for the user? I’m thinking it would be a special case for the PRT Volume – if you point it at a Frost object with no modifiers, it will use the Frost level set directly. (This will not be in the first release of Frost.)
The main issue with this approach would be the fact that the voxel resolution of the PRT Volume would be overridden by the voxel resolution of the Frost source. So the main factors controlling the particle count of the PRT Volume will suddenly be somewhere else. I suspect that the Spacing spinners of the PRT Volume would have to be grayed out to show the user the resolution is dependent on the Frost source.
In general, I think this should be an OPTION - a checkbox right under the Spacing / Viewp. Spacing spinners of the PRT Volume reading something like “Use Frost Resolution”, enabled when the source is a Frost object. It could be checked by default too.
Do you think there would be a problem if we use the spacing from the PRT volume always? That way the result should be about the same whether you’re getting data from Frost directly or from the Frost mesh.
Wouldn’t there be a technical issue?
Right now, PRT Volume takes the incoming mesh, creates a level set out of it and then creates one or more particles per voxel (called regions in PRT Volume lingo), with the ability to subdivide the voxels into sub-regions and testing each particle against the surface to avoid creating particles outside the volume. (Darcy will correct me if I am wrong).
If the PRT Volume would use the Frost level set directly, I would expect it to create one or more particles per Frost voxel and test against the Frost surface to ensure all points are inside.
How would the PRT Volume resolution apply to a completely different level set internally without any resampling? Am I missing something obvious?
If we used the PRT Volume’s resolution, we would be ignoring the data cached inside of Frost (since it probably has a different sample spacing) and rebuilding the volumetric data with the PRT Volume’s explicit sample spacing.
But we WANT to use the Frost data for performance reasons, that’s the whole point. Right now, it works pretty nicely, but if the Frost mesh is very complex (and it tends to be with all the droplets etc.), the conversion of that mesh to a new level set is the main performance hit. If we could directly populate the voxels of the Frost level set (plus sub-regions and multiple particles per region), we could have a much faster solution. Making it an option would allow the user to decide to go the fast way or use the incoming mesh and resample whenever it makes sense.
What would be the damage of making a new base object? Something that read in points and spit out points? It would be a simpler UI to manage than Frost+PRT Volume, and would have no unused controls.
If you did stick with the existing base objects, what about Frost being able to accept Frost-specific modifiers? So you’d have a modifier that sat on Frost that would output particles with controls similar to what PRT Volume has, minus that voxel size controls. I like this idea because it would let you have a Frost mesh object for the viewport.
Krakatoa Particles are not directly supported on the Max modifier stack. Darcy had done some research, but it was quite tricky to switch the data from Mesh to Particles in the middle of the stack. If you remember, we had to switch PRT Volume from a modifier to a base object for a similar reason - we wanted to be able to see the particles in the viewport, with all deformation and KCM modifiers on top.
I don’t see why we shouldn’t have an option in the PRT Volume which basically says: Use the voxels of the Frost and make your particles. The spacing controls would be grayed out and you would only adjust your Frost controls while seeing the PRT Volume change accordingly.
So I see 2 options then… Correct me if I’m wrong. A = PRT Volume gets a Frost Source and unneeded UI elements from PRT Volume are greyed out. B = New base object, say PRT Frost or whatever, combines the code from Frost and PRT Volume into one object.
The advantage for A is that you can reuse any existing PRT Volume or Frost. Another advantage is that the Frost will be able to make a mesh. Disadvantage is chasing two objects around and having UI clutter.
The advantage for B is that you have a simple, single purpose object with a streamlined UI. Also, more flexible licensing. Downside is no re-use of data for particle and meshing; they become independent.
Something users need to test… Is having the SAME sampling voxel size for Frost and PRT Volume ideal? Or is it better to sample at one resolution, filter it, then resize to another resolution for particle generation? Considering that we can’t “relax” a PRT Volume with a KCM, we might want to double-check that this is ideal. If we did have voxel processing in between the two steps, we would still save the meshing and PRT Volume mesh-to-level-set generation, so it would still be faster/better, but it might not be so simple as a direct re-use.
Also, if the PRT Volume (or the PRT Frost new base object) were to have voxel input, would you want to expose that? Allow map or plugins to process the voxels?
Yes, we’ll need to test this. What would you hope to change with a “relax”? Maybe there’s some other way we can do this.
I think our first iteration may be backwards – Frost will act as a particle source for the PRT Volume, because we have a mature interface for passing particles around, but we don’t have such an interface for level set data. (This backwardness will be invisible to users.) That being said, yes I would like to expose the voxels. This is on our wish list.
). Now that they are two separate (but loving) products, it means there is an additional developer (Yay Paul!) that could help expand the toolset.