In Thinking Particles, we have a node called PSelect, where we can manually select particles in the viewport and a list of ID’s is created that can be manipulated. Since we often need to clean up PRT caches, it would be very cool to be able to draw a selection in the viewport, especially since currently the only way to see the PID’s is to load the PRT sequence into PFlow and display as ID’s. Even this method is tedious because we need to create a lot of Equal conditions connected to the ID channel to filter in Magma. Just an idea, but since cleanup is often necessary, and specific particles are often pointed out in dailies, this would be a great feature to have.
Krakatoa offers a way to show IDs in the viewport, but it requires a selection in the Particle Data Viewer. So there is no good way to see a particle in the viewport, click it and ask “what ID is this particle over there?”
docs.thinkboxsoftware.com/produ … rt-display
Since Krakatoa PRT Loader was designed to work with literally billions of particles at render time, and the display in the viewport is usually a heavily reduced one, we don’t really have any tools for click-selecting and deleting individual particles. Similarly, the Particle Data Viewer shows only a small sub-set of all particles at any given time.
The SPRT file format we introduced in Sequoia might allow us to do that if we decide to switch Krakatoa to use it. (right now Krakatoa just reads all particles out of an SPRT as if it was a PRT, it does not make any use of the internal octree-based spatial structure).
It would be possible to write a MAXScript that lets you place a scene gizmo (say, a spherical or box gizmo), and display the data of any particles within its volume straight in the viewport. However, it would be rather slow to update if the PRT stream has millions or billions of particles. In fact, I could expand the “Filter…” option of the Particle Data Viewer to use the bounding box of any scene object as the min/max Position values. This way, you could filter the Particle Data Viewer to list only particles within the gizmo, and then you could use the selection capability to display the IDs in the viewport…
The way we do it now is just store the initial position and then filter using geometry and using InVolume or NearestPoint. This just gets very annoying when filtering over a larger scene. I know Krakatoa was built to handle billions of particles, but we use it for lots of things that are no where near that particle count ( skin wrap, secondaries rendered in Frost as geo, etc. ) and it would be nice to at least see the ID’s. Are SPRT’s just an expanded PRT format to allow for more data to be stored?
I was looking here and am curious what the benefits are >>
docs.thinkboxsoftware.com/produ … /prt2.html
Well, PRT2 is the second major revision of the PRT file format, allowing for some features that PRT 1.x did not support, like multiple streams in a single file.
SPRT is an extension of the PRT2 file format which allows us to store spatially organized data including multiple LODs, and access data locally at very high speed (so if you look at some region of space, we can quickly access/load some or all of the particles in that region, and nothing else). We designed it specifically for LiDAR data in Sequoia, but it might be useful in Krakatoa for fast lookups without traversing all billion points to find what is in the vicinity of a certain point or particle…
When we design tools in Krakatoa, we have to consider the worst case scenario - people using billions of particles. We could add tools to select particles manually on the stack and pass them up the stack for a Krakatoa Delete to handle, but if the user decides to select a billion of them, the modifier would have to store their IDs the MAX file instead of externally in the PRT file, and things would become impossible to handle.
The idea of editable PRTs has been floated before. But we want to keep things procedural. If we could build a list of the IDs to delete, we could store that in an additional smaller PRT file that a Magma could query via a second PRT Loader to set the Selection channel of the main PRT stream for deletion. For that approach, a MAXScript selection tool is the only missing component. I will have to think about it and see if I can put something together…