Our primary idea would be to create a texture like an alpha mask that could be used to extend the camera clipping planes. All the masks / stenciling capabilities we identified so far are working as post processing which is not relevant for the need.
I also saw some mentions for geometry mask while researching forums / documentation but it does not come with any explanations / examples. Also it referred to motion and is possibly not applicable for us.
Please advise.
[Attachment Removed]
Steps to Reproduce
Hi,
We are working on a training system.
On end user target system, there are few / many dead angles in the projection system leading to numerous rendered but unseen pixels. We are looking for a way to prevent these pixels rendering to save performances.
Thanks,
Basile
[Attachment Removed]
Hey there, most modern graphics engines have some kind of built-in depth-testing to avoid pixel shader overdraw in the base pass. Do you have any profiling data like Insights traces or GPU captures that are pointing you in this direction? I’d be happy to take a look at what you’ve got and offer some insights on how to best optimize your project.
[Attachment Removed]
Hi Matt,
We have traces on targeted system that are demonstrating that we are GPU limited on few area of our simulation. While we are working on content structure and optimization, during integration, we saw that the projection system has dead zones with physical masks in front of the projector to avoid lighting areas (like trainee seat for instance). As a consequence, we are willing to apply the same thing to the rendering pipeline as early as possible to save GPU processing.
A good example for the use case would be when simulating binoculars. Image from a quick google search:
[Image Removed]The black areas need not being rendered.
I was hoping to provide a bitmask as a texture to define visual areas…
Early depth writing is a possibility but in that case, we would like to ensure the occluding shape that could be localized in front of the camera actor on clip plane is the first one being rendered.
Thanks,
[Attachment Removed]
Could you share those traces with me? I’d love to take a look at those.
My concern with your proposed approach is that without heavy engine modifications you’ll only end up putting a masked material plane in front of the camera’s near clip plane which will have the same end result as the built-in depth testing.
[Attachment Removed]
Hi Matt,
Some reasonably accurate traces were uploaded in this ticket : [Content removed]
Not sure they are still accessible.
I just created something which is highlighting the expected impact from such a feature. On my laptop, volumetric clouds are just crazy and destroying fps even if no clouds are rendered ! Attaching the trace here.
[Image Removed]The profile is quite explicit on moments with good fps and the ones with bad performances.
What I do is :
To be honest, I am happy to let GPU use built in depth testing to discard fragment and processing. In that case, I need a way to initialize depth buffer with content filled using the mask. Am confident this is something technically simple but I am not able to find an exposed capability for doing this.
Thanks,
[Attachment Removed]
Hi Matt,
First of all, I agree volumetric clouds, which are the main culprit here, should be optimized on their own. We are working on their settings for the platform as a separate task.
The trace I gave was only an highlight of occlusion leverage for performances.
I am attaching 2 traces which are pushing me towards that direction. If occlusion is helping only on the base pass, how do you explain the difference between these traces with/without terrain ? I modified settings so I am starting directly in full screen at a specific location where part of the terrain is occluding the sky. We can see the GPU load is dropping when terrain is here.
Again, I do not mind having black, green (like chroma key) or even random color on the pixels I want to discard as they are not even useful in the final image. I am opened to any technique to allow early discard of arbitrary (ideally bitmask texture) areas on screen.
Thanks,
[Attachment Removed]
My best guess is that the terrain is occluded some of the volumetric cloud pixels. I think TestNoTerrain isn’t going to be very helpful in terms of diagnostics, because I would expect that tracing fewer volumetric cloud pixels would be less expensive. TestTerrain, being more representative of real world performance, is still running about 6-7ms of volumetric clouds, and then because the terrain is present you’re now spending 2-3ms on volumetric cloud shadows.
I still think reducing the overall cost of volumetric clouds is going to be the first place to look for improving performance here. If you really want to, you could mimic the impact of the terrain on reduce the overall number of pixels you’re tracing by just putting a masked or opaque plane in front of the camera. You’d have to do this in the depth pass and not in a postprocess material because volumetric clouds is using the existing scene depth buffer to do its own depth testing.
[Attachment Removed]
Matt,
The only purpose for no terrain was to set a base line.
I also expect occlusion to be the element that is leading to GPU load savings.
Again, the cloud is only an example of demanding GPU features. On the target system and with better configuration, the impact is not that intense.
So… I *really* want to come up with an occlusion capability if there is no builtin feature for discarding screen areas.
Can you point us to the accurate hooks in the engine ? Is there any “prepass” or custom depth definition phase ?
If we must create a fake plane, how can we ensure it is indeed rendered first (sorting criteria ? ), …
Thanks,
Basile
[Attachment Removed]
If the big GPU issue is the Volumetric Clouds, then using a fake opaque plane will suffice. That gets rendered into the depth pass, and volumetric clouds is using scene depth to determine if it should execute the volumetric cloud shader. Shouldn’t require anything else beyond that.
[Attachment Removed]
Hi Matt,
Sorry for the delay.
I implemented a masked effect and it indeed works for the cloud. I had no opportunity to test at the moment but will it also work with foliage / ISM / HISM ?
Thanks,
Basile
[Attachment Removed]
If it’s a masked material close to the camera, I’m not convinced that it’ll fully block scene primitives as you would if there were blocking geometry. If your static meshes are not Nanite, then you can use the freezerendering command to lock occlusion, or use r.visualizeoccludedprimitives 1 to draw the bounding boxes of occluded primitives but only if you’re not using Nanite. That’s on the CPU side, and Nanite does its occlusion on the GPU.
[Attachment Removed]
Thanks for sending this over, very helpful!
The kind of optimization you’re discussing is really only going to impact the base pass, and the maximum duration of the base pass in that entire trace was 1.15ms.
[Image Removed]
By contrast, once you’ve loaded into the application the minimum amount of time you spend on volumetric clouds is about 4ms between VolumetricCloud and VolumetricCloudShadow, likely when you’re looking at the ground. When you’re looking straight up at the sky, you’re seeing potentially up to 28ms.
[Image Removed]
So my first focus for optimization is going to be on the volumetric clouds. You might be able to gain some improvements by skipping those pixels, but even at the lowest value the effect is still a lot higher than I’d budget for in a 60FPS modern video game. Usually I’d say between 1 and 1.5ms for volumetric clouds, and on a 60FPS mode I’ll disable volumetric cloud shadows altogether and use either a light function or nothing at all. What kind of settings do you have on your volumetric cloud actor? Are you using the default material or have you customized it?
[Attachment Removed]