There are many ways to filter in Magma, but one thing that we have in TP that is super useful is something called PSelect. This is a node that allows the user to select particles in the viewport and store their IDs to be used for other things. When clients get specific, this becomes a very useful feature. Currently, our workflow to do this with PRT’s is to load the PRT in PFlow, display the ID’s, and then create a bunch of if ID == # conditions. Not sure how difficult it would be to implement, but wanted to throw it out there.
Logged!
It has been discussed before, I have a few ideas how it would work, but it can be tricky if the user decides to delete 500 million particles out of a billion via this method - if we store the IDs in a modifier or a Magma node, the MAX scene size would increase dramatically. Of course, we could cache the IDs in a PRT file on disk and reference that…
I think it would already help a lot if we were able to display the particle IDs in the viewport directly through the PRT Loader.
And while we’re at it maybe even other channels?
The Particle Data Viewer can help to some extent. It cannot show ALL IDs, but it can show the IDs of selected particles in the Viewer. So if you would select all rows, it would show all IDs:
docs.thinkboxsoftware.com/produ … rt-display
Of course, the Viewer itself only shows a fraction of all particles, but it can give you an idea what is where.
This has been around since about v1.5 (something like 10 years ago?)
Since version 1.6.1, clicking a Particle Data Viewer column while holding SHIFT will toggle its display, too, granting you that second wish 
Damn ha, that’s awesome and very useful! Nobody here at Scanline seemed to know about it haha.
Reading the documentation is not very popular 
Maybe additionally it would be nice to have the same “show info tooltip” button which thinking particles has.
It can display particle data as a tooltip when you hover over a particle.
Would help to find the ID for a specific particle
cebas.com/manual/thinkingPa … ollout.htm
For the pSelect would it make sense for the selection to be stored as data channel on the actual particle (boolean or something)? So we could read that selection through magma and do whatever with it?
I am skeptical that we could get this working with the amount of data we have to handle in typical Krakatoa scenarios, but thanks for the pointer.
Absolutely, we would have to generate a Selection channel on the stack and pass it up, so it would be definitely visible to Magmas and KrakatoaDelete modifiers. That’s the whole point. The tricky part is the storage of data that could be theoretically in the billions within the stack, as it would basically move part of the data into the .MAX file, and we don’t want that.
Okay that makes sense, thanks
Another one of my brain farts:
A button to then actually write/bake the selection (channel) into the PRT files? I would imagine it to not take too long as the main chunk of the data already exists or would that mean a complete re-cache?
PRT files cannot be updated this way in their current implementation.
A PRT file contains a compressed stream of all particles with their data channels in a sequence. That means that in order to update the Selection value of each particle, we would need to resave the whole PRT file, replacing the Selection data value of each particle. So basically we would have to write a whole new PRT file, and delete the old one.
SPRT files can keep the data channels separate, as we discovered that this helps with compression. Having all selection values of all particles in a sequence compresses better than having a sequence of particles with all their channel values side by side. However, while we have discussed the ability to save new information in an existing SPRT file, I don’t think this is currently supported there either.
I was thinking more along the lines of having a modifier on the stack that points at a secondary PRT file sequence which contains nothing but a Selection channel (kinda like the Point Cache which overrides vertex positions). This way, updating data on disk would require resaving just the Selection info into its own sequence, without touching the base PRT sequence that does not have a Selection.