When sampling a small number of particles in the PD Viewer from a PRT Loader, performance is adversely affected by culling in the base object. Seems like it is culling all the particles, then loading a small sample from that result. This is accurate, but slow. If there was a checkbox to ignore the culling, then the PD Viewer would be faster (though it may include some particles that would otherwise have been culled).
The PD Viewer uses the Particle Stream reading interface we exposed to MAXScript.
That interface gets the particles from the world state of the render stream on top of the stack. This includes everything the PRT Loader does including culling, all KCMs, OSM, Node Transforms and WSMs/Space Warps that might be applied. Thus, I cannot tell the PD Viewer to use something else because that’s all it can get.
If you want to process fewer particles, you have to change the PRT Loader to load less particles, for example by using the Limit option or the Render Percentage.
currently, I can ask for one particle. But if the culling is turned on, it takes 10 seconds instead of .01 seconds.
Ben.
Ah ok. That will make part of my other wish not feasible then. Is it looking at the viewport or render result?
In the case of PRT Loader, it is looking at the Render output.
There is a bug logged against the PRT Volume which is currently using the Viewport output but should not.
I can look into providing ways to copy the stats data into clipboard for pasting into Excel or something like that if you want to compare. Having multiple windows of the same script is quite tricky.
Would it be easier if my wish was to have two PD Viewers in one window? Just have an A side and B side?
I thought about that, not sure if it will be easy to do, let’s see what will happen… 
The alternative would be to “store” the current stat values in an A buffer, select a different object, store in a B buffer and then display the differences (expand the bottom list to show each pair of columns side by side plus a “Diff” column showing what the difference is…
But if you want to list per-particle values side by side, it would need two objects loaded at the same time.
If you capture two buffers, you have to make sure they’re displayed together, and you have to make sure that the buffers can be resynced, especially if you are looking at changes over time. I’ve vote for having a button that makes the window double in size have just have the script run twice when the update button is pressed. Haven’t looked at your script to see how it’s run, maybe I can just take what you have now and end up with my own solution.
My problem is more with design decisions like “Do we use the same controls (frame range, Nth, Selected, Filter etc.) on both or does each one need its own duplicated controls?”. Same applies to pretty much all other controls.
I just felt I was done with this particular tool for the upcoming release and having to break it apart and build it again feels kind of wrong…
Yeah, that’s why I’m thinking maybe I should try breaking it apart. The particular use case I have right now would involve all the settings being exactly the same, save for the object selection. I’ve got 2 PRT Loaders which I want to look the same, but they aren’t, and I was trying to inspect the channels for inconsistencies. And of course you have to look at many particles because any one particle might be an outlier, and some of the values are mapped to crazy ranges, so just using a KCM to convert to color is a pain (and even then, you can only look at 1 channel at a time). If the tool updated as I changed the KCMs on the ugly one, I could see if they were coming into line with the pretty one, and not have to fire off 100 renders.
I’d guess that the performance hit you are seeing is related to rebuilding the volume acceleration structure on every evaluation. I’ll look into fixing that.