In case this is helpful to anyone else…
I figured out a solution, but it opened up more questions.
Use a sample-once, transform/jitter-many. Specifically, for each cascade, ring of grass I had in my landscape grasstype, I made a node-series off a singular/shared point-sampler:
So this begets another question: is it better to have multiple, smaller-cells tiled across a large world, or a single giant volume? With smaller-cells, one might jitter less-times off the same sample-density as the same density with a larger volume tends towards the too-many-instances. With a large volume, one would have to likely lower the density to avoid that, hence jitter many-many times.
This leads to another question, what DOES this thing spit out? Is it a dynamic-script it generates/runs some kind of network at runtime or some type of hard-output/reference-able file it can load from (pre-calc’d)? It would seem to inform how complex a script one might want to make? If I have to keep jittering many-many times per the above, that might be poorly-performing if it’s some kind of runtime-network?
FYI, PCG does seem cheaper, netted a few FPS for the same grass-densities as landscape-grass. From what I can see only the landscape-grass has any kind of (async) dynamic-build overhead. For my test-case it seemed to be consistently cheaper for the PCG on the same Foliage stats shared across the two paths:
Landscape-grass:
vs PCG:
