I’ve mostly been playing with numbers on the assumption that the brightness of a point light is supposed to be its actual lumen amount (which is what the tooltip claims). In that case, the default value for auto exposure ’ brightness’ is much too low at 2, and there seems to be little harm in turning it as high as it can go, at least until you decide what you want your brightness to be.
Until we find another way to get a pre 4.15 look through the new post 4.15 tonemapper. Please dont remove the old tonemapper.
So Epic did a stream on the Tonemapper,
The default tonemapper should be as physically accurate as possible as to provide a neutral starting point. The problem is that the bloom generated by the old tonemapper resulted in a visual effect that, in real life, would be the result of a combination of different phenomena, not only camera lens light bleeding (which bloom is). Specifically, exaggerated bloom gives the impression of atmospheric light scattering (the “hazy” look) and the reflection of diffuse emissive lighting on nearby surfaces. When the tonemapper is made physically correct, those side effects disappear and you only get actual bloom.
Now, UE4 always supported overriding the tonemapper with a custom one in the post processing settings, so even if Epic removes the old tonemapper, you can continue to use it. I think this is a better solution than having everyone design assets around a non-standard tonemapper that doesn’t match industry standards and bias games toward a proprietary look by default.
Just wanted to chime in a bit since i worked on film compositing for a lot of time.
The new tonemap function is indeed physically correct.
Values outside the 0-1 range desaturate and turn to white when pushed.
The lava displayed in 4.15 is correct, the problem lies in authoring. Real lava never emit as much light as a lamp, and usually doesn’t bloom. If you see pictures with blooming lava it means that the photo was overexposed, not that lava emits light.
Anyways, If you want to have a very saturated and emissive material you need it to be in 0-1 range, or at least have a value of 0 in any of the channels.
Problem is that materials authored like that don’t pick up bloom so easily, so you should work on bloom lowering the detection threshold. It’s a balancing act on every part of the scene.
Also, the ssr reflected particles in a previous post seems right to me.
I don’t have the scene so i can’t see the values, but the emissive values probably go over 1, so they desaturate. Then the reflection is calculated using absorption in the material (since it’s not a perfect mirror) and values get dampened, giving off more of the original hue since the range of the reflection is compressed compared to the particles.
I sincerely prefer the new way, as it’s very consistent with film offline imaging. Problem lies in authoring the scene. It’s not a bug or an unintended behaviour.
just my 2 cents
But a lamp emits as much light as a lamp and does this even in other colors than white. And a physical correct fantasy-mushroom is saturated orange as everybody knows and not yellow or white.
Yes, but it seems even in that case you have to work against the tonemapper instead with it. I’ve an idea how it should look like in my world and the tonemapper says: white, white, white, white now. I still have no clue how to create some saturated neon-sign material in another color than “white” (with some tiny but saturated bloom).
Most photos of a neon signs are white in the middle, like a light saber. The only ones that aren’t white are exposed so everything but the sign is black, and still start to desaturate as they get brighter.
This is not really helpful. I search a way how_to make them saturated with bloom (and it’s no neon sign anyway) not getting told that I should leave them just white. If you search for neon sign images on the net you find various that are saturated and not pure black in the background. I’m pretty sure you know that you could find various lights (led, neon, …) in reality that your eye does not white out but shows in its pure deep color. Even if a photo might capture it this or that we even create fantasy and sci-fy worlds for a good reason.
If you want it saturated object that looks like it’s glowing, just make a custom material.
I made a material in seconds that looks good.
Take a 3 constant of .8, .1, 0 to get orange, plugged that into a multiply.
Took a fesnel node, put .5 into exponent in, plugged the output into OneMinus, plugged that into the other multiply spot.
Plugged the multiply into BaseColor and EmissiveColor.
Done.
We here at Snaketakes Studios Inc. www.snaketakes.com & www.eotbgame.com are experiencing all of the above mentioned issues with our game title as we use alot of visual effects, now not only are all of our Environments much darker than they should be, the colors are way off, SILVER = PINKish PURPLE? In what world i’m not sure… Our Emissive is a total mess as illistrated above a few times now, and just generally setting things back to a good look if we were in the year 2000… We’re in the middle of migrating back to 4.14.3 as that was the last build we upgraded from and everything was nearly completed and ready for polishing phase and now, not even sure what to call it, our game was a dark sci-fi effects driven game and now its just blackness with aweful effects and colors that look laughable compared to just one build previous… #NotImpressedAtAll
Any news on this? Will we get to keep the old tonemapper as a setting?
I understand the need for more proper tonemapping, but as a noob in lighting and post process, I’ve painstakingly built after the old settings, and am happy with the way things look. Proper or not, I really want to keep it.
the new tonemapper is mixed. there is one thing however that i do like, i do like the fact that epic took notice of UE4’s lighting. UE4 should have expanded gamma, brightness and contrast levels. I don’t like high contrasting, crushed dark levels, and bleeding colors in my project. Epic Should focus on delivering “pure” colors, not this whole “Camera based” colors and tint. the effects of a camera can be emulated well through post processing; once you have good gamma, contrast and brightness levels.
This won’t work on flat materials, such as particle sprites. Fresnel requires normals. Sure - You can plug your own procedural normals in, but why should you pay for that computational cost?
The bottom line is this: Restoring the old tonemapper does NOT return the old Bloom or Glow. Everybody arguing that the new Tonemapper is physically correct - we’re not disagreeing with you, what we’re saying is you completely lose artistic control and that is bad.
I’ve compiled some of these posts into a feedback thread here.
New Tonemapper completely destroys the look of my game. I’m not remotely interested in a physically based Tonemapper as my game isn’t even set in a physically based world. I just want to be able to upgrade the engine to get the new code fixes without having the appearance of my game forcefully changed.
It’s half a year now and Epic still didn’t respond. It’s horrible. We’ve been working with unreal for exactly half a year on 4.13 then 4.14.
We need Switch support and overall other changes, so ofc we tried migrating and now the game looks like ****. Everything is white, the bloom is almost nonexistant, and there is no way of bringing the old look back. WTF Epic? Seriously?
Can you post this in the feedback thread here? I’m trying to get some official response.
so sad:(:(:(
No matter how powerful it is, if the artist is not used to it, it makes no sense.
I am a solo dev with MachRace on steam greenlight.
I was wondering why the colors were so botched after recent upgrade 4.13 to 4.16
It sucked all the life out of the visuals. And after tweaking it for hours, I still cannot get it back.
Is there really no way to go back?
Going to bump this considering it is still costing me hundreds of dollars to fix from the old tonemapper and it still doesn’t look near as good.