I’d like to hear about your experience using Frost. What do you think is the worst thing about Frost? What’s the most important thing we need to change?
So far for me it’s the management of what particles are used and where the meshing occurs.
Since the viewport and render particle sources are locked, AND the meshing is done to the bounding box of those particles, I can’t do a “ROI” meshing to fine tune a problem area or do a proxy meshing for performance.
- Chad
For working on a ROI, the first thing that comes to mind is a bounding box to cull the particles. Is that reasonable, or is there something you’d prefer?
I’m not sure what would work for a proxy mesh. I guess you’re working with large particle counts, so the viewport meshing res control doesn’t help?
Interesting idea. Of course, we can do the the culling in a KCM, but currently Frost evaluates the render particles only, not the viewport ones, which is what the KCM will return (in the view). So what looks “complete” in the PRT/KCM object is in fact not valid for Frost and you have to re-do it all with the render particle counts from scratch.
I was thinking more along the lines of caching the particles for meshing, and just having a bounding box defined in Frost that only generated the level set / mesh in that box. You could edit the level set and meshing without invalidating the particle data.
But your idea is interesting, I think we have what we need from Krakatoa to do it, we just need to be able to run the viewport particles through Frost.
- Chad
If I understand correctly, you’d like to:
- Access the Krakatoa viewport particles, and
- Specify the meshing bounds?
Yes.
-
If the viewport Krakatoa particles are already processed for the viewport, would that also make for faster access? Meaning you aren’t reading the viewport count from the network and reprocessing the KCMs?
-
If you have collected all the particles (with or without the other idea) moving the bounding box around should not trigger pulling those particles again. In the case of PRT’s, we don’t spatially sort the particles anyway, and they’re compressed, so supplying a bounding box won’t save time on load. But if they are already loaded and Frost caches them, then the level set and meshing can be done from that cached data.
If we are to do 1., it should be an OPTION.
It would be bad if I want to preview the rendering mesh in the viewport but have to draw 10M PRT Loader particles in the viewport to do that.
So the option would be a radio button or drop-down list “Viewport Meshing Source:” “Viewport” “Render”.
Note that Frost currently pulls VIEWPORT particles from PFlow, but Render particles from Krakatoa objects, which is a bit confusing…
But if the PFlow was spitting out one set of particles for the viewport, and another set for Frost, doesn’t that make a lot of extra work for PFlow? It’s the same with Krakatoa PRT Loader/Volume/Source.
But yeah, a pair of radio for source viewport or render set would be great. So you could choose the viewport or render sources for the viewport meshing and you could choose viewport or render sources for the render meshing. Would be especially nice if you set the render meshing to match the viewport meshing and thus not need to recreate the mesh for rendering.
Hmmm… I wonder if there should also be some compensation for other settings. Notably the voxel size and particle radius multiplier. Like you have a spinner for viewport multiplier, so you could set the viewport voxels to be say 2.0x larger and the viewport radius to be 3.0x larger.
- Chad
What I wanted to say was: PFlow+Frost ALREADY mesh the viewport particles for the viewport and the render particles for rendering. When loading a PRT Loader, I would expect the same BY DEFAULT. If the user decides he wants the render mesh in the viewport, both PFlow and PRT Loader (and anything else) should be queried in Render mode (which is currently the default and only mode for PRT Loaders but not even possible for PFlows), at the user’s sole discretion regarding the extra work PFlow has to perform.
In short:
Viewport: Use Viewport Particles - PFlow Viewport Particles (works already), PRT Objects Viewport Particles (currently not supported)
Viewport: Use Render Particles - PFlow Render Particles (currently not supported), PRT Objects Render Particles (works already)
Renderer: Use Render Particles - PFlow Render Particles (works already), PRT Objects Render Particles (works already)
Meshing Krakatoa viewport particles is on our wish list now, but it will require an update for both Frost and Krakatoa.
I think I know what you’re getting at – you’d like a similar surface, despite lowering the particle count? I agree this would be nice, but I’m not sure about a good way to do it. A viewport radius control would let you fill the interior holes, but I imagine it would be misleading about surface details.
A refresher because this thread is rather old: most particle sources produce different particles in the viewport and render. We proposed adding an option (radio button) to use either the viewport particles or the render particles in the Frost viewport mesh.
I would like to add this sooner than later, and I wonder if anyone has feelings on this.
Is a per-Frost option fine, or does it need to be per-particle source?
Should you be able to view the render particles for all sources, or only for Krakatoa sources?
Should we switch only the particle sources to render mode, or the particle sources and everything they reference (more expensive, probably closer to the actual render output)?
Ideally, we’d have a master control on the Frost, and have a preprocessor object to hold the sources and these sorts of per-source controls.
Yes, it’s not so much that we need the output to be “closer”, we need it to be exact, since we might be doing topologically dependent operations further along in the stack.
- Chad
Agreed, this makes the most sense to me too. Tweaking on your viewport and come to find at render time that it looks completely different is difficult if not impossible at best.
“Use Render Particles” should work now for Frost 1.1 + Krakatoa 1.6.1 SP2 Beta. By default Frost will show the Krakatoa viewport particles. Please let me know if you encounter any problems.