PCG - achieving parity with landscape grass - keep getting too-many-instaces

[Frenetic]

Starting to work with PCG and I have some questions on trying to achieve the same level of output I am currently getting with Landscape Grass.

Right now, I’ve defined several rings of grass. Higher densities with shorter culling distances to step-down over distance so it appears w/smooth transitions going away from the player. Pretty sure this is what we all do, or close to it. Specifically, I have the following densities:

Landscape grass densities

When I get over to PCG, I’ve struggled with the points/point-density. I keep running into too-many instances being spawned with a note about needing to increase the buffer-size:

LogRenderer: Warning: GPU-Scene Instance data overflow detected, reduce instance count to avoid rendering artifacts.
Max allocated ID 21568349 (20.569M), instance buffer size: 16M

I’ve played around with this enough so far to realize the scaling, density of points, etc is handled somewhat differently (?) vs other grass-deposition techniques. This is fine, but I’d still like to know how I can go about recreating what I get out of Landscape Grass, but in PCG.

This is what I am using to spawn grass, each static-mesh spawner having an increasing cull-distance.

PCG Graph

The density-filters go from 0.75 → 1, 0.5 → 0.75, 0.25 → 0.5, and 0.0 → 0.25 going top to bottom.

Still learning and will plug away but this is obviously-different for me, just-asking for direction / suggestions?

I DO check the docs, youtube, here, but haven’t found a good answer for this vs other kinds of errors.

Side-questions:

• what’s the max-size of a PCG volume. I have a landscape scaled up to 500x500x350, so 10km side. Is there a way to make this ‘unbounded’ like a post-process volume?
• it seems REALLY SLOW to generate things, like tortuously slow . I get this is the new-hotness and does offer a lot of ways to lay stuff out w/runtime-performance benefits. I do like it, but it’s SLOW even just to set up grass. Is this typical of your experiences?
• cannot seem to locate the buffer in question. Anyone know where this lives? 16MB doesn’t seem an awful lot to double-up on…?

[Frenetic]

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:

[Evigmae (Franco Sciaraffia)]

For the time being I don’t recommend trying to achieve parity with the landscape grass system using PCG. Just stick with the landscape grass for the time being if possible.

I think in a few engine versions with pcg runtime and gpu generation you’d be able to make the swap a lot easier than trying to do it now.

Don’t forget PCG is not production ready.

[Frenetic]

FWIW, I did manage to get parity with the grass-density, culling, etc.

However, whilst the data-packer is very handy one is not able to reference height from an RVT to properly place grass on displaced landscape-surfaces; still have to do that in the shader, so no savings there…

Agreed that the experimental tool is experimental, but it IMHO shows good-promise. I tried the options here (Using PCG Generation Modes in Unreal Engine | Unreal Engine 5.4 Documentation | Epic Developer Community), but ended up with 40k pcg-tasks that ended up borking my test-level (was stuck in a crash-loop)…

I can work with the landscape-grass, even though it does incur shader-overhead vs the PCG. It IS handy-enough to use a shader to lay it out though… Otherwise there does seem to be a clear and consistent savings in time-spent on the same stat tasks between the two methods, with PCG coming out ahead.