4.19 Physical Lights

Wow, i will check out this

From the HDR visualization chart, it can be seen that the pixel brightness at a distance of 1 meter form a point light source of about 50 lumens , similar to the directional light with an intensity of 3.141593.
So if the illuminance of the sunlight is 125 000 lux, then the lumen of the point light source is 125,000/50 = 2500 times smaller than it actually is?Or does the HDR visualization now not work at all?

Hey @

Does that mean that if I have ISO 100 and 1/125s as well as EV 16, I need to set exposure compensation to 11,11 to get the result I expect?

Why not build the system in a way that the values above WITHOUT exposure compensation put out what everyone expects?
What do you mean most scenes are made for an EV100 of -1.2? Do you mean other tools work that way? Because no one has been building stuff for Unreals new exposure so far…at least to my awareness. Also, if all other people assume -1.2 is the default and everyone is used to these values, why then change it and confuse everyone?

And last but not least…why do auto exposure and manual mode work differently, to begin with? That’s just basically asking for beef between level lighters and cutscene lighters cause their values don’t work together.

I am not trying to be bitchy here and I really am sorry if it comes across that way. But I just can’t make any sense out of this. I have worked with almost all available engines and some in-house tech as well and I have worked with Unreal 4 since 2011 and I have NEVER come across a system as cumbersome as this cause nothing really relates to each other or to some known good values. Everything is just random eyeballing etc T_T

And in regards to physical values in general…here is another example:

When I lit the Deathstar for Battlefront 2, a lot of the lighting magic comes from the emissive shapes on the walls. These emissive shapes have a visual emissive value and also actually contribute to the lighting…like lightmass emissive.

At first, the level looked super flat and there was not a lot of material interaction with nice roughness and spec on surfaces and characters looked dull as well. The level lighting itself looked kick *** though! So I was like: what the hell is wrong here?!?!?

In the end, it turned out to be the emissive values. The thing is, depending on your bloom and exposure settings, emissive value of 5 and 500 can look the same visually…but since we render in HDR, the values are still there even though they might not be visible per so.

So what happened was that the emissive visually kinda looked correct, but in relation to physical exposure, it was too weak and this didn’t render as strong enough value into the reflection capture. Once I increased the emissive values to be in line with local light lumen values in the level, it visually looked the same, but the HDR values that got captured for the reflection were way higher, thus really pushing the look and making everything come together nicely. Suddenly, I had sexy materials and a lot of interaction :slight_smile:

That’s why I personally believe, physical values “can” be VERY important :slight_smile:

Another small update :smiley:

I just made a new scene, added a directional light with the intensity of 125 000 (thats more or less what I used on Naboo so I know how things have to look)

I use manual exposure with these settings:

Sooo…if we look at this, can anyone explain how this makes any sense in relation to what @ has written? :slight_smile:

Also, the skylight has a brightness of 5 in this shot. How does this make sense if the sun is 125000 lux and the sky 5? Should the skylight not sample the lighting intensity from the skydome and brightness should just be a multiplier of that sampled value?

Ouestions over questions here :smiley:

Another thought I am having, cause this smells a lot like the issues the community had when the tonemapper changed…would it not make sense to maybe get feedback from certain experts from the community on some of these topics before implementing them and then everyone is unhappy with the way its done?

We have so many professionals in this community that have real world experience with these things and their feedback could prove invaluable before releasing a big change like that.
Just some food for thought, cause I for myself would be more than willing to participate in testing things like this before they get an official release :slight_smile:

Cheers!

Alright… the last one for today, I promise :smiley:

So I used my little test scene that I showed earlier and reset everything. Then I set my exposure to manual and used the values you see in the image above, but with EV 12 instead, cause the sky is rather cloudy. Then, I set my directional light to be 65 000 lux, cause I know that the sun usually is between 35 000 and 125 000 lux.

So far, so good, I can see direct lighting, but the sky is still black. Now it gets interesting! I have an HDRi image as EXR mapped to a skysphere that I capture with the skylight. I bumped up the multiplier in the material until the sky became visible, but how would I know what brightness is correct?

So from our measurements, I know that a cloudy sky like this has an average brightness in normal areas (like not where the sun is) of around 2000 candela per square meter. I used the pixel inspector and bumped up the multiplier until I had a lot of spots on the sky that made sense to have this value and it also instantly looked correct. I ended up using 6500 as a multiplier for the EXR which actually does sound quite familiar to me…depending on how the image was exposed :wink:

Now I recaptured the skylight and did a bake. Everything turned out exactly as expected and that’s ****ing great! :smiley: I am actually really happy that it kinda worked out like that!

However, and now we come to the issues I have experienced :smiley: I had to use an exposure compensation of 2 to get it to look like what feels right to me with those values. So I basically would expect it to kinda look like this but without exposure compensation.

Next issue is that a spotlight with 1000 lumens is basically invisible that way! I used 100 000 and it looked correct ¯_(ツ)_/¯

Also, I started experiencing render glitches like extremely noisy and broken looking SSR even on max quality settings, also convolution bloom seems to be badly affected and that’s just what I found for now.

Additionally, I tried matching auto exposure settings visually to the manual exposure and it turned out to be super weird and unintuitive values like 5200 and stuff like that. The autoexposure also had troubles adjusting to some of the brightness levels on screen.

All in all, I am really excited that the exterior stuff seems to “kinda” work with manual exposure, but I am also quite frustrated on how everything else is implemented and how this seems to work :frowning:
It all just seems so weird, unintuitive and overly complicated.

Well, lets see if someone will be able to shed some more light on this! :slight_smile:

Cheers!

EDIT: okay, interesting find! The 1000 lumens light was suuuuper dark, so I had to use 100 000 lumens instead. I thought, what happens if I use candela instead? So with a converter, I found out that my 1000 lumens light would translate to 75 000 candela. After I put 75 000 candela into the lights value in Unreal, it actually looked correct! Like what the heck is happening here? XD

Still toying around with this as well.

Using the default atmospheric fog with a directional light at 125,000 and a Skylight capture at 1 gives me something reasonable with 1/125s and f/16 although it’s fairly muted and those settings still don’t really line up with what has been said already. Measuring the Scene Color(or is it HDR Luminance?) of a pure white plane without the tonemapper doesn’t give me the cd/m² results I’d expect. I’m looking at 1.1 with the above settings. I’m guessing that’s 1.1 cd/m², or is there is a multiplier and it’s really 1,100 or 11,000 cd/m² - the latter seems to be closer to some averages I’ve found. That’s for the Scene Color though, I have a bug now where the Luminance isn’t updating at all. Adjusting the skylight anywhere above 1 with these settings results in a poor image, eventually turning pure white with artifacts everywhere. And pre-exposure is enabled.

Trying the same thing with a noon HDRI only and the intensity needs to be cranked up to 100,000+ to feel natural, but that blows out the material viewport. Switching the values around and using a default intensity of 1 in the HDRI and cranking up the Skylight works, but then you don’t see the sky with the exposure settings.

Also with these settings, bloom doesn’t work until you crank up the intensity into the thousands or remove the -1 threshold. Planar reflections are pure white planes. And switching between Game Settings and EV16 gives me a white screen until I move in the viewport, despite my sunny 16 settings visually being similar to the EV16 defaults.

Thanks for those details. Can you tell me the dynamic range that the camera and viewport are using, I know the post processing and tonemapping are done in ACEScg space but what is the bit depth?

I know this is not accurate, but try adding an exposure compensation of around 1.75 to 2 to your setup! At least thats puts it visually where it needs to be^^ Local lights are still off though if you DONT use my lumens to candela hack I mentioned in the edit of my post above :wink:

I just finished recording a new Lighting Academy session where I work with my testscene and explain my thoughts and what I like or dislike about how it seems to be implemented right now :slight_smile: Its gonna be available tomorrow I guess.

Cheers! :slight_smile:

@Daedalus51

Was trying to find out why scenes look so dark in UE4 with 125,000 Lux, far from looking like a bright sunny day.

I wanted to check out how 125,000 Lux would look like in Cryengine (since everything always look fine in cryengine) and find out how much I’d need to touch Exposure Compensation in UE4 for my cube to look like the one in Cryengine, to have correct results.
So I setup a 50% Grey (186,186,186) cube in both Cryengine and UE4, with sun intensity of 125,000 and lighting directly from above. Surprisingly both cubes are around 225,225,225 when sampled.

So I was wondering why scenes look a lot darker in UE4 while sun has same value in both engines.

I bring in a rite color chart in both engines and it turns out to be UE4’s tonemapper making values below 50% a lot darker. That’s making everything below 50% Grey look extremely dark and making you think there’s something wrong with camera/exposure settings and thus, making us think we should use exposure compensation slider but doing that is extremely wrong since that affects values above 50% Grey as well @.

Here’s the color checker in both engines with no bloom and UE4 vignette turned off and both engine tonemappers at default settings.

UE4 (you can see the frame around colors already looks like black but it’s actual value is 52,52,52)

https://i.imgur.com/0J7Z8E0.jpg

Cryengine

https://i.imgur.com/v8aoySI.jpg

Square 19 actual value is 245, in cryengine it’s 243 in UE4 it’s 219.
Square 24 actual value is 48, in cryengine it’s 67, in UE4 it’s 27.

Now I know how it should look like based on how it looks like in cryengine, if I use PPV and try to compensate for it manually without using that Exposure Compensation slider I end up with way more accurate results.

https://i.imgur.com/bO3yZHH.jpg

This time:

Square 19 actual value is 245, in cryengine it’s 243 in UE4 it’s 232.
Square 24 actual value is 48, in cryengine it’s 67, in UE4 it’s 70.

It was some quick and crazy changes to highlights, midtones and shadows in PPV and didn’t touch tonemapper settings. Now it does look like a nice sunny day but still far from how it should’ve been. You can see text on square 16 is hard to read.
ACES is a “Film” tonemapper and I never understood why Epic put it in a game engine instead of something like Hable tonemapper.

Tried to use your values on sample scne (new map with single floor). disabled all static lighting. As long there was nothing particularly reflective on scene it looked acceptable, the moment I placed an mesh with wood material (from StarterContent), it broke. I guess after setting 125000 on directional light, renderer run out of numbers and flipped into negative values, since where there were supposed to be reflection it was black blob.

So it either cannot be intended setup (by Epic), or the material is broken… I would guess the first.
But what are correct values in this supposedly physically correct lighting model ? (when providing physically correct values break it).

It’s a “filmic” tonemapper, meaning it’s based on the response curve of various film stocks, which is based on the response curve of our eyes(excluding dynamic range, local chromaticity correction, etc). I believe CryEngine supports/will support ACES based on one of their blog posts last year, but I don’t know which flavor/curve. Have you tried adjusting the Tonemapper settings in Unreal to reduce the blacks and match your CryEngine result? Reducing the ‘toe’ value will quickly give you more milky blacks.

Did you have pre-exposure enabled in the project settings? I’ve had black specular artifacts too, but it was fixed once pre-exposure is applied to the scene color. It doesn’t fix some of the other asset issues(planar reflections), but the actual specular from the light source gets fixed.

I just set Toe to 0 and tried to bring it all back using a LUT, again based on how it looks like in cryengine.
Here are the results of how the rite looks in cryengine and in UE4+LUT (both without bloom)

I’m actually not sure which was which after uploaded. I think first image is cryengine.
Both engines with 125,000 Lux, no ambient light, no bloom. UE4 camera settings is sunny 16.

Enabling bloom with default value makes it look quite like a nice sunny day now.
Here’s the LUT if anyone wants to try it out.

https://drive.google.com/open?id=1TI…fJ0ffYBskr4nOs

Edit: Set Toe to 0 if you use the LUT.

Thanks I will try it out. Though it shouldn’t be nessesary to workound it in frist place.

Man, I used to follow rather blindly the 3.1416 SUN Sky 1 and 1750 lm for 100 watt bulbs guidelines from the guy who worked in robo recall.
Now 1750 lumens looks completely blown away, relations look off etc.
What has changed and what new guidelines should I follow for creating a basic illuminated scene now?

Not having resources for this new changes makes it really hard to work in 4.19 for me. I think I’m going back to 4.18. Which is a pity cause 4.19 looks nice.

I think that’s kind of what we’re all trying to figure out here :slight_smile: There are values documented for just about every time of day that the engine now uses, but those values don’t give the results we’d expect.

The reason your old light value does not look the same now is that exposure was off by -9 stops previously, according to one of the programmers. With the proper EV and material calibration, the new values should look correct compared to a photo of the same EV and materials(excluding tonemapping)

Messing around with it i’m finding the tonemapper pretty limiting. And the problem with the tonemapper and real world values is that everyone is going to have a different idea of what it should look like based on whatever source material they are use to. Personally I would like to have an option where you could disable the tonemapper and have a log encoding with a slider to control the amount of encoded dynamic range, then use the color grading tools for tonemapping. And to make it simple for everyone, have a preset menu with some typical tonemapping/grading settings.

At the bare minimum pick an EV or aperature value relative to the environment you are trying to emulate then bring in a color chart and change the light values till it looks uniformly lit.

Ok it’s somewhat fixed. But now I had to bring my SkyLight value into 0.001 range. Otherwise everything is just white ;o.

So are the folks at Epic aware of this? Is a fix being worked on?

Honestly…my main concern is that it will go down exactly how it happened with the Tonemapper :frowning:

Basically EVERYONE complains about it because there are no alternatives and Epics only reply is a) our tonemapper is great but you just dont understand it (they never said that, but you get that feeling by how they treat this topic) or b) they just tell you: well then turn our tonemapper off and do your own. Like I have a graphics programmer in my closet that is just waiting to do that for me :stuck_out_tongue:

This really makes me sad the more I think about it so all we can really do for now is for some folks from Epic to talk to us.

Please Epic…this is an open invitation to, at least have a dialog with us about this! Lets just sit together like grown-ups (and not internet trolls^^) and discuss how this was implemented and how we can improve it. No bad feelings, no blaming or hating…just a normal discussion and exchange of ideas. Wouldnt that be great? :slight_smile:

Cheers!