I think it would, since it’s a very dark floor despite its perfect reflectivity.
Incidence of reflections are completely different in those two examples - the lake is at grazing angles so the reflection value is close to 100% whereas the particles on the tiles is getting towards 0 degrees (to the eye ray) and so would be closer to 4% = major difference. Remember a tiled floor is a dielectric and a mirror is backed by a layer of metal which is a conductor and so can reflect at 0 degrees at almost 100%.
Your example looks physically correct to me - but perhaps you just want something stylized which is fine.
I’ve got another thread going on HDR - but this new behaviour is critical to having HDR display correctly and not look bizarre that there’s a ‘bright’ colour causing bloom which in HDR is actually barely bright and then a particle system next to it throwing sparks with correct Black Body levels is scorching hot then the skybox behind everything is flat and dull because it’s a low dynamic range jpeg.
Of course i’m only talking about photo-realistic rendering. Unreal makes some great cartoon/stylized stuff so there needs to be modal behaviour to support every avenue.
|
wouldn’t the U from the unreal logo and all the words not behave the same way then and turn more blue-ish?
additionally
Many of us with untrained eyes are claiming this looks wrong, regardless if it is in fact physically correct.
And if we do, you can bet that any average person who is playing the game/project/showcase, and any client/boss might also claim it looks wrong.
In those cases (especially if a client demands it) we need to be able to change it on the fly.
I think the color values need to be pushed beyond 1
Ultimately there’s no way to keep colors from tending towards white with the tonemapper. That seems to be what it’s for, more than anything else. By which I mean to say that it’s not exclusively for HDR displays, or possibly even essential for them.
What is strange is that green tends towards white as you’d expect, but blue tends too much towards purple, and red tends too much towards orange. You can add a little more green to your blues and a little more blue to your reds and it will look much better. Could be an error with the Linear color>>ACES conversion.
If a colour is causing bloom, it’s already bright. It won’t look flat and dull compared to sparks because they’re relying on the same data for brightness. If anything, SDR is underrepresenting just how bright these things should appear. E.g. That mushroom in the OP would look as bright as the sun in HDR. After ACES, the only change its that it’s now white instead of orange.
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.
Besides the tone mapper, I want my specular color controls back from UDK ! Hope they add something in with the new stuff so that we can control the colors !
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 
It’s easy to look SSR code. It’s just take previous frame linear color(before tonemapping) and use that with proper specular BRDF. In above screenshots you can see clearly how reflection of billboard is looking greenish but the billboard is white. In right picture reflection is hard to even see because street isn’t perfect mirror.
Please forgive a noob his noobification…
Surely, there is a difference between:-
- Materials
- Rendering
- Post-processing
IF, the materials being created are part of a PBR/Linear workflow then (pre-runtime) we are rendering levels/maps to fit into a Post-Production ‘world’, where the environment artist(s) decide what filter to put on the lens the player is looking through?
Simply, this is a run-time issue and not a pre-runtime issue.
UE4 is a PBR system - should we not be focusing on making the initial pre-runtime rendering as awesome as possible, like pushing color values and dynamic ranges are far as the laws of physics allow?
For my purpose console command r.TonemapperFilm 0 helps a lot and emissive materials looks nearly like before. I also pumped up intensity of emissive color.
Yes, it’s already written in the first post. However it does not sound promising if it gets removed in future versions. 
Hi Mitch,
Yes UE4 can be a PBR system but as we’ve seen you can make very unrealistic materials by just using constants and cranking up the values which go into the rendering system and create all sorts of results - some of them are creatively pleasing !
Yes UE4’s SSR should be dealing with the linear colour/pre tonemapping so all mathematics are done in the correct space = the particles are very bright blue and so the dull reflective floor is reflecting something like 4% of that emissive colour = dull blue.
After all these correct lighting/surface mathematics (ideally based on PBR material inputs) the tonemapper will bend all of that into our display space. This is another point where artistry can come in and one can change white balance, gammas, black/white points and parameters to clip/not clip brights etc etc.
Actually as Kalle-H points out the billboard to the left of my example frame is a good case of all of this behaving correctly - the SDR image on the left’s billboard would measure full white (255,255,255) but the dull side walk is reflecting a smaller percentage of that which fits into the dynamic range of the image and shows the true colour (dielectrics won’t tint the reflection) but just to be sure you can see the stopped down image on the right to see the real colour of the billboard which confirms the situation. Again, all of this would look MUCH more correct if we were to look at the frame in HDR on and HDR capable display and the tonemapper wouldn’t be bending things as much.
All I’m getting at is UE4 is making strides to be more and more reliable and work on the scientific basis of light/energy. It’s something I dived into with the Maxwell Renderer 10 years ago and it was very controversial at the time because we were still used to strapping our own shaders/materials together by hand and most of the time not even with any respect for energy conservation (materials could reflect MORE light than they receive!)
Done well this will make realtime experiences more believable as if metals really behaved like metals, not shiny plastics or glass looked like glass and not transparent plastic. You’ll change from indoor to outdoor and you’ll really feel the difference in the amount of light - and not just by hacking at the bloom parameters - but because your new HDR monitor will actually make your eye muscles close your iris down ! Wow !
Still, we need to have complete control over this in the cases where we don’t want photo-realism.
I’ve just comared the element demo 4.11 and 4.15:
4.15:
4.11 :
While I think the lava could be faked to a very bright lava (because even this type of lava exists) I still prefer the “cooler” lava of 4.11. If your goal would be dark orange lava you just failed your job in 4.15. And that said there is not only bright white lava but even deep orange lava like in 4.11 and almost pure red lava as well. While this was possible whit ease < 4.15 it seems you can only get very very hot and bright lava in 4.15 now. And everything that is not lava (neon signs, lasers, magic bolts, …) is doomed. I think this is a step backward and not forwards. It’s not more realistic but forced and limited realistic and less unreal …
While its not too bad a look, it also feels slightly off.
Id settle for an in-between 
You could easy get an in-between (or even more pure red as it really exists in nature) < 4.15 because all those colors belonged to you. In 4.15 all those colors are eaten by evil tonemapper … and just turns white extreme quick.
Hi Neutronux,
Lava is a perfect example for my case actually as Lava fits a scientific phenomena called Black Body Radiation which has an absolute mapping between Temperature in Kelvin to RGB.
I’ve simulated Lava (in VFX) at realistic Kelvin temperatures so the values can be mapped directly through a Black Body node and return a RGB colour that goes into the Tone Mapper.
My guess is the UE4 lava was artistically created to look ‘right’ but isn’t sitting in physically correct units. 4.15 would probably make this easier.
Real units are just a much more reliable platform to work in. Watts, f-stops, IOR, kilogram, gravity and tight PBR materials make life easier as you can pick up scientific journals (even going back decades) which can explain the interaction between them all - regardless of which software one uses.
After this point it’s all about how you creatively ‘expose’ the image i.e Instagram vs RAW
But my material does not have a temperature node. It could glow because it’s a hot black body or it could glow because it’s some cold (temp) red neon light. Or it could glow because it’s my laser beam, wizards spell or whatever where no real physical mapping exists. We have lights so in theory we could just replace all emmisive materials of neon lights and scifi effects with real (expensive) lights. It was cheaper to just fake the illusion of light. Now it seems every emmisive material is doomed to be white-ish. Emmisive colors with bloom are gone. Just the bloom remains in color but the materials itself are whiten out (and way too fast).
Elemental Demo is 5 years old. It’s not really fair to use content that is hand tuned to look good when engine was totally different beast.
Fair? 
- The goal is not a beauty competition in a lava-demo (as this issue happens at many other materials that uses emmisive as well) but finally finding a solution to work with the new tonemapper. This is no PS vs Xbox thread. If somebody could shed some light in how to hand tune the emmisives of the 4.11 screenshot it would ge great. I’ve tried to get the lava in the 4.15 to the 4.11 screenshot. But it’s either complete without any bloom or way too much white. And it seems red or orange is better than other emmisives like green or blue. Multiplying the emmisive input of the lava material * 0.1 in 4.15 brings similar red and yellow spots … but the yellow is still too much and too less saturated the bloom is gone (almost complete) and there are too much dark spots already as well (because it’s getting < 1 values for sure).
4.11 - Would get this:
4.15 - Makes this:
4.15 - tried to make it red again via multiplying the emmsivie 0.1 which made it more red, killed the bloom and still left too much yellow:
