We are using HDR on Metal-level devices and so we need to have HDR enabled in the project
We need to completely disable post-processing on non-metal devices
Using SHOW POSTPROCESSING to disable the Tonemapper on 2/ saves us 12-14FPS / 10-11ms, which obviously is very significant
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.
Some of what you are asking to control, is already handled when you deploy to different devices that cannot support HDR. This will effectively disable any settings or features that are not supported by HDR. Creating device profiles, and understanding which settings within Post Processing that are improving performance when disabled. Honestly, I would take a look at the documentation we have on Post Process Effect on Mobile as well as our Mobile Development information to help you understand why disabling the entire tonemapper is not something that is recommended as Mobile post-processing is handled differently than PC.
Post Process Effect on Mobile
Setting Device Profiles
If you have further questions or need additional assistance, please let me know.
I have extensively read and abide by the mobile recommendations and information on post processing effects as far as the current recommendations suggest, and our device profiles are set up using every optimization we have been able to dig up so far from all sources.
Unfortunately, the current recommendations don’t solve the issue of fully disabling post-processing on non-HDR devices, while simultaneously supporting metal-level devices and HDR effects:
Just to be clear, we only want to be able to fully disable the tonemapper/post-processing on devices that are using no post processing or HDR effects whatsoever.
In effect, the tonemapper is the only postprocessing effect that cannot be easily disabled, even though it eats 10ms completely unnecessarily when running on the (for instance), which uses no HDR post processing effects.
I know we can hack in a method to detect the device and run the SHOW POSTPROCESSING console command, but that’s not the most optimal way to go about things. There seems to be reticence to enable control or disabling of the tonemapper - many of the threads I’ve read have a guarded response about control of the tonemapper, which is either to disable HDR completely, tweak the post processing effects to achieve a non-tonemapped “look” (which doesn’t help performance) or statements along the lines of “the tonemapper is required”, which doesn’t apply to devices that are not using any post processing.
If this is something that won’t be addressed because ES2 devices are not part of UE4’s critical path (which is understandable), then that’s fine, but it would still be helpful to get some pointers on how best to disable the tonemapper at runtime on ES2-level devices, since it is not required, and is non-performant. Either that, or an explanation of why it’s required on ES2 devices that are not using HDR effects.
I may have been too wordy in my follow up, so I didn’t receive a definitive answer on this, so I’ll try to be brief:
Why, when ALL post processing effects have been disabled on a target device, is the tonemapper still required to be run?
“I would take a look at the documentation we have … to help you understand why disabling the entire tonemapper is not something that is recommended…”
As a I mentioned, I had already extensively read through the documentation, but there is actually no information regarding why the tonemapper is required when post processing is disabled. There are however plenty of forums posts asking how to disable the tonemapper, but very few clear answers.
The tonemapper is the only post process effect that cannot be disabled in device profiles, even when no post process effects are being used, or required.
I’m still not clear on why this is the case.
Disabling the tonemapper already disables all post processing effects, so I don’t see a “user error” justification for offering no control there.
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."
AnswerHub Post
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."
Forum Post
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.
For now we have completely disabled HDR in the project (even though it would be great to use post processing effects on Metal-level devices), since there is no straightforward way to enable or disable HDR or the tonemapper per device.
Disabling the tonemapper would have been a nice optimization (as we saw an approximately 10ms saving) for devices not using post processing effects, but running the game in HDR at all is too costly on ES2.0 in the end.
This is probably a diminishing problem for Epic as new ES3.1/Metal devices come on the market, but currently there is no ideal way to target both high end (HDR) devices and low end (LDR) devices with a single binary on mobile. It really is all or nothing, unless your game has extremely low rendering requirements.
Not the end of the world, but it means we can’t really show off the power or beauty of the UE4 on iOS, since Metal devices are required to use LDR if we also want to support low end devices.