Disable tonemapper/postprocessing specifically on non-metal devices?
Since HDR is not required on non-metal devices, we need to be able to disable the Tonemapper at runtime. Ideally this would just be a CVAR flag we could set per device. From what I've read so far, there is currently no way to do this. Since we can toggle the Tonemapper on and off on device using the console, this seems like something that could be easy to implement potentially.
The comment here that the Tonemapper is "required by the engine" seems odd, since toggling the Tonemapper on device has no ill effects other than disabling the tonemapping colour space conversion.
Additionally, it would be very useful to be able to disable the tonemapper while preserving other post processing effects, such as bloom, for games that don't use realistic shading or lighting.
"The tonemapper curve is softly clamping off the whites and does a slight contrast enhancement." - What we see on iOS devices is not contrast enhancement, but general desaturation and washing out of colours, with decreased contrast overall. Since we're creating a non-photo realistic game, it would be ideal to be able to disable the Tonemapper in this case while preserving effects like Bloom.
In a nutshell though, can you recommend how we can implement HDR effects on metal devices but completely disable them on non-metal devices? Disabling HDR across the board is a bit heavy-handed for our project.
My best response would be to quote our Sr. Graphics Architect on how we handle the Tonemapping in UE4.
"We have a misunderstanding. Tonemapping is HDR->LDR, EyeAdaptation is normalizing the HDR based on content.
I explained how to disable eye adaptation. Tonemapping is still happening. Our tonemapper pass also does add noise to reduce color quantization for 8 bit, apply color grading from LUT texture and other things. All that also works together with otehr features e.g. TemporalAA which assumes a tonemapping step.
If you disable tonemapping (=linear tonemapper) you would get clamped highlights. That looks quite bad.
If you want to export some color like GBuffer properties - you don't need to disabale the tonemapper, you can access the HDR intermediate.
You also can change PostProcessTonemap.usf. We intend to make the postprocessing more programable - then you can do such a change in the material editor."
I also found some more information he provided on a forum post regarding the Tonemapper and how it is calculated.
"The current behavior is intended. The base color is a material attribute that combined with light (and view angle) becomes the HDR color which still needs to be tonemapped to become the LDR color so a monitor can display it. The tone mapping tried to be mostly linear but if the HDR input values get very bright it should softly clamp to white. This is needed as lighting can be brighter than 1 in many areas and we want to avoid clamping artifacts with that.
The pipeline is setup to make it easy to get real (physically based) content. Having a different default (e.g. no tonemapper) would break that goal. We intend to make the tonemapper pass more programmable (You already can override the tonemapper pass creating a Postprocess Material replacing the tonemapper but getting access to the properties is very very limited) so for some applications this default behavior can be altered.
I would love to have a reference shader/material/object type where no color manipulation happened - that would be very useful for reference images. We might do that."
This is all the information I have on this topic, and should provide enough explanation of why the Tonemapper goes hand in hand with HDR, and some suggestions on how to start working around the current limitation.
answered Jan 13 '16 at 06:19 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here