I have a city in a generic forward renderer with simple lighting: blue-ish ambient, a cubemap for some additional lighting, and a directional light for the sun. The scene looks fantastic.
I have the same scene setup in Unreal Engine. I tried using a solid sky light color and also a cubemap for sky light. I used these with a warm direct light representing the sun. I was highly disappointed with how washed out the color was and after a while I became convinced it has something to do with either the gamma correction in one of the core shaders OR itâs a flaw in how the lighting is blended with the sample diffuse. I donât know exactly which. I tried completely commenting out the gamma correction step in GammaCorrection.usf and reloading the engine. It made no difference in the image. Can someone please tell me whatâs going on thatâs causing Unreal to compress and wash out the colors and how to fix it?
Below are two images. The first more vibrant and richer one is the generic forward renderer. This is the look I want.
The second image is the Unreal render. Note how flat the relative colors are.
ADDITIONAL NOTES: Changing the Exposure does not seem to effect the relative color curve or look other than shifting the total luminance of the image up or down. I played with Exposure and lighting intensities plenty to verify this. The problem has got to be the way the lighting itself is shaded or something to do with low level gamma correction or tone mapping in the core shaders.
We figured out that the FilmPostProcess() function in TonemapCommon.usf only runs if you turn on one of the effects in the Film dropdown of Post Process Volume. But we also discovered that this function definitely shades the entire screen, which means it will only take the existing washed out image and run a color process on it. That means tone mapping is not the problem. The problem is deeper than that. Itâs either some kind of gamma shift that happens before the post process effects are run, or itâs the way the lighting itself shades the geometry to generate the HDR image.
There are some adjustments that can be done to the material that is applied to the mesh which can help bring out the saturation of color that you are looking for, but I want to check a few things as well. The image you are showing in the UE4 example above needs to have lighting built, does it still look as washed out once the lightmaps are built into the level? Also, what does your material look like, is it just the texture inputed into Base color? Also, what is your levels post process settings.
-Let me know
Eric Ketchum
Edited: Also check the textureâs settings in the Texture Editor. Try it without having sRGB checked
Iâd guess the generic forward renderer didnât do lighting properly in linear space, or didnât use a tonemapper at all. The tonemapper causes some loss of contrast because it maps a large HDR range to a small LDR range, thatâs a necessary evil.
You can disable the tonemapper with a show flag, and then it will use the simple gamma correction path.
Can you combat it with the contrast settings in PP, or increase the contrast in your lighting (less ambient so shadows are darker, more directional).
Eric, I unchecked sRGB already. It was one of the first things I tried. It makes no difference.
Also the washout and color range issue shows up both with built and unbuilt lighting.
The material is extremely primitive. 0 (black) in the specular and the texture is wired directly into the Base color.
I will also point out that trying to exaggerate the diffuse texture in the material isnât solving the problem and wonât actually be a proper fix. The problem is that Unreal isnât faithfully reproducing the color range when shown in the viewport. sRGB makes no difference, lighting makes no difference, Film effects donât fix it because they only try to post-fix/hide the real problem. The only thing I havenât figured out yet how to change is the gamma itself or the map from HDR to LDR â they are my last hope.
From the color grading page in the docs: âNote that bright colors become gradually brighter but much less than dark ones. Black remains black and there is a mostly linear part of the curve that is a bit steeper than the non tone-mapped curve would be. That results in some contrast enhancing.â
There is a discrepancy in that the docs are indicating color grading should cause contrast enhancing but youâre saying it can cause contrast lost. Which statement is the true one?
The problem canât be combatted with PP because thatâs simply a hack retro-fix to the poor color rendition on the buffer. Additionally, changing lighting parameters will have no useful effect because the issue is on a flat plane in a heavily varied texture. The problem is relative color metric of the aerial image on a flat surface.
On the editor viewport, Show->PostProcessing->Tonemapper. Itâs useful to see what the affect of the tonemapper is, how much the range compression is affecting your final look.
The photo doesnât have to be evaluated as a photo. You are choosing to think of it that way. In reality, it can be viewed as a simple texture with colors in linear space. And clearly the transformation happening in Unreal is distorting that space. The fact that itâs a photograph is irrelevant.
There is a discrepancy in that the docs are indicating color grading should cause contrast enhancing but youâre saying it can cause contrast lost. Which statement is the true one?
They are both true, in different areas. The doc is talking about the âtoeâ at the dark end of the tonemapper, which increases contrast slightly in the darks. Iâm talking about the generally more noticeable compression of bright colors which reduces contrast. Bright colors also get desaturated as they approach 1.
Additionally, changing lighting parameters will have no useful effect because the issue is on a flat plane in a heavily varied texture. The problem is relative color metric of the aerial image on a flat surface.
I see that now, and that is part of the problem. Material descriptions need to be surface properties, things like diffuse reflectance (this is what you plug into base color). You are plugging a final lit image (photograph) into Base Color, which is effectively tonemapping the image twice, since the camera tonemapped when it captured the photo (conversion from linear HDR lighting to gamma LDR). To reproduce the same result as the image, you would have to know the underlying diffuse colors of the materials captured in the photo.
So thatâs the theory part of it. Obviously you want to make something work and you have an already tonemapped photo, not the raw diffuse colors of the scene that you would want. What you can do is try to undo the cameraâs tonemapping with contrast and brightness operations in the BaseColor of your material.
Jim says: I have verified the culprit is either the tonemapper itself or one of the functions connected to it. Per Martinâs direction, I turned off tonemapping and got hugely improved results even in the default scene. See the following images.
First image is with tonemapping enabled. Second image is tonemapping off.
When turning on tonemapping, the highlight on the table becomes grey instead of white. All the whites in general are lost and become grey. This means not only is their an overall loss of contrast, but the white point is incorrect.
The colors get desaturated reducing vibrance and depth.
This is a fundamental problem that needs to be addressed. Some people could make an argument that it results in a better mapped image â but in reality itâs less physically-accurate AND prevents the artist from getting extremely hot highlights and vibrant saturated colors. It really isnât beneficial in any way. The only seeming positive effect is that shadows get richer, but richer shadows should be setup properly with lighting adjustments, texture changes, or a simple post process color curve that only effects mid and dark tones. The tonemapper should not be responsible for darkening shadows.
I took a look in the PostProcessTonemap.usf file and found the line that calls the tonemapping function as well as the color grading function. I tried bypassing both of them and for some reason the tonemapper still takes effect. Could someone direct me on specifically what to change in the shader file to disable the tonemapper completely? I donât know why my edits arenât taking effect.
Jim says: Ok I guess I was just confused about the edits I was making. Theyâre definitely taking effect. Iâm working on an improved color mapping now that gets a more linear-esque color curve to keep strong contrast but still map everything into LDR properly.
It really does. A tonemapping operation has been applied to the image by the camera which captured it. You canât expect to treat a tonemapped image as diffuse reflectance and then tonemap it again and get the same result as the original tonemapped image.
Figured it out. Disabling the tonemapper is as simple as passing the Linear Color out of the tonemap shader. I did that like this:
OutColor = float4(LinearColor.rgb, LuminanceForPostProcessAA);
in PostProcessTonemap.usf.
But that wasnât the only problem. I also had to uncheck the sRGB checkbox on every single texture in the scene because everything was super dark without the tonemapper until I unchecked that box. Hereâs what the image looks like now. The colors are far closer to the original tonal range in the source texture. Brights blow out nicely and the high tones have their original contrast.
@Hyperloop, no there isnât a solution that doesnât involve code. If you look at my answer down below, thereâs an explanation about a way to do it.
This is a serious issue, In testing it myself I have not found Tonemapper to be the problem, I enabled Tonemapper in editor mode and its enabled by default in game mode. However the moment I press play theirs a darkening that takes place thatâs making me angry. I donât know what this darkening is but you can see it by pressing G and then G again, their is some quick fading transmission that happens often making things darker that is separate from Tonemapper.
This engine started out so well but the more I use it the more I am getting angry with it, I donât want another Unity 3dâŚ
Isnât their a button that makes the Editor View settings the same as the game?
Why does the editor launch with all these preset lighting conditions that are only suitable for certain games?
Alright so after some testing by having all my EDITOR post process effects activated and disabling the post process on my CAMERA and my post process VOLUME in the world outliner, I now have the exact same views in G mode and editor mode.
However I have found that their are hidden post process effects somewhere else, This is evident when I disable the tonemapper, eye adaptation and anotherâŚI am not sure what object is responsible for this yet.
This issue is really screwing me over aswell, Iâm working on a pixel art game where I NEED PURE BRIGHTS.
I have a moon and lightning bolts in the sky and for some reason, they turn out grey instead of pure white, so I started googling around and found this issue, I tried going to show>PP>tonemapping, turned that off and now my picture looks perfect in the editor, but obviously as soon as the game starts running again I get the crappy greyed out colours, and my shadows are also becoming darker, which I simply do not want. I want to be able to 100 % accurately display the colours that I have drawn in my pixel art but aslong as I can not turn off this blasted tonemapping that wonât happen.
I have made a post processing volume and tried turning it off there, none of the options change anything at all, the only way this far has been to turn it off via the viewports show menu as mentioned above, sadly this does not solve anything for in-game use.
What the bloody hell am I supposed to do about this? The tonemapping is messing up my colours making everything look washed out and boring.
See for yourself, you can not honestly tell me that this isnât screwing up my art.
