Turn on texture compression on your RVT.
Your brush setting are probably fine. You’re gonna get hard edges/transitions with those settings though.
And yeah, your textures are not using much memory at all. So we can rule out texture pools.
The warning is about streaming textures. Those need to be rebuilt every time you change something. I’d turn it off for now. Just remove the texture from the “Streaming Texture” property in your RVT volume. You can re-add it and rebuild it before packaging or once you’re satisfied with your landscape.
Your material should not use alpha blending unless you’re using multiple sculpt layers. You appear to only have one, so your paint layers should be blended together using weight blend.
Maxing out your RVT size should not be necessary. I don’t know how big your landscape is though. But even so, that’s crazy high. 512x512 tiles and 1024x1024 tiles should be enough for most cases. And yes, this will cause the 512 on the debug texture to show up instead of 1024. That’s expected. I have a small landscape and use 256, 256, 4 (8, 2, 2) and it’s WAY more than I need.
In game optimizations… depend on what you’re working on. For meshes, it’s avoiding Nanite. That’s gonna a be huge hit on older cards (and even newer ones). I suppose that is perhaps a controversial opinion considering how much Epic is pushing Nanite. But facts are facts. Nanite is insanely slow. Shadows are a big topic as are distance fields. But more static shadows will reduce processing time. You can also reduce tick events. Clouds casting shadows along with certain fog or volumetric effects can cut your framerate in half or worse. On the flip side, distant fog and volumetric effects can actually help. Depends on how you use them.
There are TONS of buffer views in the viewport to help you see what’s taking time. There’s one for shaders that’s really useful. There’s also a “Trace” button at the bottom right of the editor. You’ll need to watch a tutorial to use it, but it’s very powerful and will let you know exactly where the time is spent in each frame. It’s often difficult to decipher exactly what is causing the bottleneck though. “stat unit” is probably my favorite and simplest performance indicator.
There’s lots of stuff that you can dig into to speed up performance. Lumen and lighting in general is a big one. But once you feel you can’t optimize anymore, there’s a button on the top right of the editor for performance settings. In UE 5.5 and earlier, it was quite hidden. It was in a button in the far right at the top I think. Then it was like two submenus in. On UE 5.6, it’s above the viewport on the right with a speedometer icon. The submenu you want is “Viewport Scalability”. By lowering these one at a time and putting them back and with the FPS being displayed “stat fps”, you can see what affects your performance the most. It could be foliage. It could be drawing too far in the distance. Could be reflections. Could be landscape. They’re all there and it’s a real easy way to see what you should be looking at. And lowering some of those settings for your default game isn’t a bad thing either.
Another thing that affects performance, especially with TAA, is called screen percentage. Most AA solutions are also upscalers. They render at a reduced resolution and scale it up. The screen percentage is how much smaller your render buffer is compared to the final output. So if you have 100% screen percentage, then you’re not doing upscaling at all and your framerate will suffer. The editor tries to use a pre-calculated default. But on ultra widescreen, it’s absolutely terrible at this and is WAY too high. So having an option where the user can lower it is nice to have.
Another thing that can be bad is just bad implementations in your game. I’ve seen people do AIMoveTo every tick. This one is incredibly common. The engine will let you get away with it for a few actors. But if you do this for other things, it can get slow real quick. Updates don’t need to be done every single frame. Timer events are event driven and take almost no processing time.
Then there’s other things like say you tab to another window. Do you know what keeps ticking and what doesn’t? It’s not clear. Certain things will keep ticking in the background. Other things are paused, but the timer keeps going. So when you tab back, the next tick has a HUGE Delay value to catch you back up, but this can break your game easily if you don’t take it into account. Other things do NOT keep the timer going. It is paused and resumes when you tab back. Other things are throttled instead of completely stopping.
Anyways, I’ve rambled long enough. Thought I’d give you some ideas on where to look. Optimizations are what I specialize in outside of games (assembly (SSE, AVX), algorithms, data structures, CUDA, OpenCL, etc.) so I love talking about this stuff. With respect to gaming, the engine isn’t my code, so a bit more difficult to know what’s doing what.
:
