Since I can’t directly grab min/max value I am trying to magmaScript the total particle count from a PRT Volume.
As seen here: thinkboxsoftware.com/krak-pa … xscpt-val/
I use the code:
obj=FranticParticles.GetPRTObjectIStream $PRT_Volume001 false false
obj.getCount()
To try and grab the max particle count from the chosen PRT Volume object (PRT Volume viewport display reports 19012)
Upon running the above snippet it returns:
-1LAny ideas? Did I do something wrong? Bug?
LOL I just tried to plug that into an InputScript and it totally crashed max to desktop! 
Okay little digging
Evaluating the selected PRT object with:
(FranticParticles.GetPRTObjectIStream $ false false).getCount()
PRT Loader --Works
PRT FumeFX --null ? -1L
PRT Volume --null ? -1L
PRT Hair --null ? -1L
PRT Source --Works when sourcing PRT FumeFX, PTR Volume, PRT Hair, actually all of them.
PRT Maker --Works
PRT Surface --Works
Some streams do not know in advance the total number of particles. In that case they return -1 (L means Long Integer).
If you open PDV, you will see it says “Showing 1000 of -1L Total Particles.” for a PRT Volume.
So in that case you have to keep iterating the loop until the particle data returned becomes undefined which shows you have reached the end of the stream…
So not a bug, that is good.
I guess I am still a bit confused, PRT Source knows what the PRT Volumes count is, why doesn’t the function? I call the function from the PRT Source and it returns the PRTV’s current value.
The PRT Volumes viewport count knows what is current count is, how can I get the value? Can this stream value be exposed?
Is there any way I can get that value into a variable I can use in magma?
The PRT Source makes a copy of the stream’s particle data, so it knows exactly how many particles there are. The cost of this is that all those particles are stored in memory at least twice (once by the source, then again by the renderer).
The viewport display shows how many particles it is drawing, but unfortunately this has very little correlation with the number of particles present at render time (the spacing / percentage is definitely different). In the case of the PRT Volume, figuring out how many particles will fit inside your mesh can only be determined by actually creating all the particles (ie. exactly the same work as requesting each particle until it stops generating them like Bobo mentioned).
If you are happy with the memory cost, why not just stick with using the PRT Source approach? Anything I add to deal with this case will be no less expensive.
Thanks Darcy
Sure understand. Was curious.
PRT Source snapshotting is just fine