A surface can only reflect something in a different colour than the source if it’s a conductor (Metallic e.g Gold) That tiled floor is a dielectric which is why the more grazing reflections are 1:1 with their source (the background details) The ‘strangeness’ of the particles is because the source is a fairly bright blue but is being tone-mapped into the colour you see but the lower reflection levels show a darker colour blue which is correct.
I totally get what you’re saying but in the VFX world we’ve only been in this PBR-style land for less than a decade so we’re used to having reliable surface responses to light. Realtime engines are just here now so we’re in a transition zone of confusion and frustration.
Here’s a great example - in standard dynamic range the brightest value can only be WHITE (255,255,255) so to make a bright RED we have to do strange things like enable BLOOM to pretend it’s brighter. With an HDR display you could make that red very bright and the display would show a very bright RED (e.g neon) and you wouldn’t need to use any blooming what so ever.
Attaching a picture I put together - the pixel values of the brights on the left side are all WHITE (there is lighting bleed onto the surrounding surfaces which gives you the idea there is actually colour involved) but the right side is stopped down to see the real colours of the lights. Since 4.15 we’re able to work with these sorts of correct colour intensities and have them mapped back down into our SDR display range. An HDR display would be more capable of showing those colours on the right however and this is what i’m personally working towards so that when desktop and VR displays are HDR capable then all my assets/work is ready for their enhanced abilities.
The Tonemapper should be able to be tweaked for SDR display and not cook so white - I haven’t had a chance to get under the hood - but that picture is from another experiment i’m working on (high dynamic range photogrammetry) so I’ll see what I can find.
Everything you say is true for photography, but a human looking at that sign would see a red sign with no white. Human eyes do not desaturate like cameras do. Compare a photograph of a laser pointer dot to what that dot looks like to your eye, and you’ll see that the dot gets unnaturally desaturated by the photosensors in the camera.
Sorry for the necro bump, but have there been any updates or workarounds on this issue?
A game mechanic I’m working on relies on telling apart differently colored glowing materials and it’s next to unplayable right now due to the current tone mapper sucking all color out of emissive materials. I tried the post process tweaks posted on page 4 of this thread, but it doesn’t even get close to what I need. Any help would be greatly appreciated!
I’m also trying to find an official response to this issue.
I’ve been trying to make an emmisive red light, similar to what you have on cranes and tall buildings to warn planes.
At a distance, with my own eyes and with a camera, these glow a solid red. I’m sure if I was standing right next to it, it would have a white centre, at a distance it is 100% red.
Seems the newer emmisive does not allow for such artisitc discretion.
I stumbled upon this thread for obvious reasons - wanting to retain ‘core’ color of the material. I’m working on recreating real life object, the NBA Basketball shot clock to be precise. Yes, my project is much more on the physically accurate side rather than the artistic side, but ‘artistic’ tweaks are more than welcome.
The solution that works for me so far is going into PPV Details -> Bloom: Intensity between 2 and 3 (currently set to 2.5), **Threshold left at default -1.0 **and then going into Advanced tab and tweaking Size Scale.
In order to have even more realistic result, I would probably have to make LED dots smaller and increase the Bloom Size scale to something like 10. It’s at 4 (default) at the moment.
How are we suppose to display unlit sprites in ue4 exactly as we have authored them now? I created my sprites with the exact color values I want and it’s now impossible to display them in game with those very colors. Everything looks fine in the editor viewport. The colors are being displayed exactly right (I prntscreen and checked them and the hex values are correct). When I press play all of my colors change.
I don’t want to go back to pre 4.15 because I need map and set variables. I don’t know even if I could go back anyway since 4.13 no longer works for me after MS Trojan horsed a new Win10 build on me, hence why I moved to the newer version only to find everything looks like trash now.
as opposed to disabling the tonemapper via the CVar, here everything else that’s tonemapper-dependent (TAA, etc) still works.
the “only” caveat is that the EyeAdaptation node seems useless and my scene becomes fully dark
That’s only for maintaining constant luminance for emissives, useful for gameplay-related things that shouldn’t adjust with exposure.
There is no easy way to replace the tonemapper or achieve similar results with ACES. You could use the Post-Process Material to replace the tonemapper at the cost of no native controls for color grading or exposure. OR, you could replace/comment out a small section of the tonemapping shader and replace it with something else like Reinhard that keeps highlights saturated. The Gran Turismo tonemapper by Uchimura is a good middle ground in that highlights aren’t *as *desaturated and you keep the “filmic” contrast. It’s definitely more complicated than Reinhard, but it’s straightforward to implement. Replacing the code gets more complicated if you’re planning to support anything other than the standard sRGB/Rec709 display.
with 4.24 the EyeAdaptation node now works in postprocess materials, so the above workaround now works respecting all of the exposure settings
however the rest of @rosegoldslugs comment is still true - you lose the rest of controls for color grading
actually nevermind, it doesnt simulate the old effects
any color that isn’t -full- red, green or blue, when multiplied by a high value for emissive, seems to be getting blown out into a whiteish version of that color
on the other hand, unlike the first few replies, as of 4.24 a (50,0,0) pure red does not become orange anymore, and a (0,0,10) pure blue does not become pink anymore
All colors will eventually desaturate, it just depends on the hue. Red and blue are two of the darkest hues, so it makes sense if the same emissive multiplier has a different effect on them. It’s also worth pointing out that the blue to purple issue(an issue directly with ACES which the Academy is aware of) is addressed in post-process with the Color Grading > Misc > Blue Correction slider. It effectively corrects anything similar to blue, so there is a bit of bleeding with green and purple. The Expand Gamut option also improves saturation at high luminances a tiny bit as well, although that’s not the direct intention.
I was wondering why my emissive materials kept getting “washed out” no matter what I did. I guess there’s no way even now with 4.24.3 to have an emissive color retain it’s primary color instead of getting whiter/paler? I mean “r.TonemapperFilm 0” works but it also isn’t exactly what I would want…(not to mention it’ll eventually no longer work).
Just ran into this problem also. The emissive surface turns white when you crank it up. Only the bloom light it emits retains some of the intended color. Not very useful unless all of my emissive is basically white, which they aren’t. I’m using 4.24.3
Tried the r.TonemapperFilm=0 and it fixed nothing. I’m guessing epic made good on their choice to remove the old tone mapper so now I’m screwed? If so that’s awesome.
It sucks that this is still a problem, isn’t Epic supposed to be an “unreal” engine with endless stylistic possibilities? Yet for something as important as emissive materials, we are still stuck with this idiot “realistic” behaviour…
I also was annoyed a long time with the new tonemapper. But just now I discovered one option in the Post Process Volume: Color Grading -> Misc -> Tone Curve Amount. If you reduce the value, the colors in the highlights will come back. Hope this helps someone. (Using UE 4.26)
Tone Curve Amount = 1
Tone Curve Amount = 0.8
If you set “Expand Gamut” (Option Above Tone Curve Amount) to 0 then the tone curve is completely disabled. You can still use the color grading options.
