4.15 tonemapper - is it possible to simulate old effects?

[Daedalus51]

@Renbry;669011

Hi Luos -

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.

Hey Matt,

thanks a lot for further explaining the tonemappers behavior! Great to see some better visualizations!

I have to say though that the reflections still look wrong from SSR as I have some kind of “proof” since we are also rendering for HDR and our SSR reflect exactly what you see on screen. So I am really confused.
Also, in your image, you can see how the properly exposed reflections of the cars headlights look. They look strong and match the exposure of the image.

The example with the blue effect from unreal looks like if we would take the reflections from you right image and put them into the left one. And that just feels wrong.
I think it would be really awesome if someone from Epic would comment on this so we can get an understanding of whats going on under the hood

Thanks again and cheers!

EDIT: I actually remember now that we had a similar problem with emissive surfaces and reflections but it wasnt on the SSR where values were wrong, it was in the reflection volumes. It had something to do with the buffers where emissive information was stored and the reflection captures didnt have proper access to that information. So maybe something similar is wrong here? But yeah…different engines=different problems