Any direction here? Can I get the benefit of using GPU-accellerated HLSL with landscape physical-materials? I am trying to make a functional landscape-grass replacement (1:1). I can get the landscape maths into an RVT, which drives the physics layer, which can be read in PCG. It works for the surface sampler but pivots on the physical material for the grass-layer.
Help!
EDIT: to be fair to Epic, when using the top-path, not the HLSL, the grass overhead remains pretty-well locked to 0.05ms which is a VAST improvement over the, sometimes, seconds of update-time for large-volumes of grass in large open-world landscapes. So bravo! It just seems this is a bug/oversight/inconsistency that I ran into.. If I could make that 0.05 into 0.01 I would, hence the want for HLSL in this case.
EDIT2: 0.01? I did! But not getting the physical-layer is still and issue in the cases where we still want to use HLSL..
Hey brother it seems like you’re actually deep into the Custom HLSL and I couldn’t help but notice that you are an advanced user. If you wouldn’t mind sharing, I couldn’t get the RVT to get sampled in PCG. The landscape material is writing to an RVT and I have enabled the sample RVT in the get landscape data node, but the HLSL code Epic provided simply won’t sample any data, I am writing my data to BaseColor and would like to write it back out to the color attribute and remap it to density, my plan is to have a unified and visually debuggable texture that is shared across PCG and other assets. Any insight from a technical artist like you would be greatly appreciated.
Hi, so to reply, and at least mark a solution to this one..
The issue with the physics being sampled in the HLSL was tied to my use of RVTs to store what drove the physics-layers. In some cases, sampling the physics-layer would work since it was newly rebuilt and everything was fresh. But once I did something like edit the landscape-material, or something that would touch that RVT-pile, it would desync and stop working properly until the pile was rebuilt.
I believe the issue is due to the nature of feedback to the RVT and how some samples might not trigger the ‘oh I need to actually re-render that tile’ in the engine when sampling the RVT. Post-process suffers from this limitation (as noted in the docs) and whilst I cannot confirm for physics, I feel it’s in the same ballpark.
Regardless…I didn’t ever test without the RVT, don’t plan to here, I’ve since moved onto sampling the RVT directly in HLSL and bypassing everything, including the problem. Better, it’s more-performant. Landscape-grass would be near-instant in game, but come with a heavy-runtime price. Once I chunked up the world via PCG per what I was doing back when I created this thread, it might take a few seconds to lay out 4k by 4k worth of grass, with a better runtime overhead. A vast-improvement. However, with HLSL, it’s literally instant; night/day in terms of performance, so I moved off physics altogether.
I think the solution here is that physics will surely work in HLSL, but RVTs will make the stack unreliable unless you know it’s going to be entirely static. I’ve not tested this statement in a cooked game.
And this just sanity check that the material is actually writing to the RVT, the RVT Volume is set to the bounds of the landscape and writing to the file called. “RVT_PCGLandscape”.
I have used Epics Code, now your code but I couldn’t get this simple noise to be sampled on PCG. The White block to the left of the noise cube are the PCG points, the shaders compiles but its not writing to the Color attribute.
In your case, runtime generation might have been necessary given the way you configured it. It’s not always required; one can generate and serialize data.
Different settings for different use-cases, but glad you were able to get to a solution!
