4.19 Physical Lights

[Daedalus51]

@coach

Hi my 3rd “vate” Tilmann
(in time order koola 1st and Rabello 2nd :D)

is like a week i’m tring to focus on your posts and youtube channel (btw amazing class i just give to you a little contribute

i have a question about lighting and building:
i alsways used **skylights **specific cubemap and ( mostly with the multibounces) i get many colours from HDRI (for exemple in the interiors i have colours from the windows came from hdri) now with the **captured **scene i have no this colour shades

is it normal?

Good question but a different topic!

Would need to investigate. Theoretically, there should not be any difference between the two when using exactly the same levels of brightness.

Cheers!

[Tjames44]

Hi **Daedalus51****, are you planning to release any new tutorial on how to use the new system to achieve such exceptional results as the one above?
**I´ve been following your tutorial series and I really like it a lot and looking at the images above I think it will be great if you could share some of your tips to get this quality of lighting.

thanks.

[Daedalus51]

@TJAMES44

Hi **Daedalus51****, are you planning to release any new tutorial on how to use the new system to achieve such exceptional results as the one above?
**I´ve been following your tutorial series and I really like it a lot and looking at the images above I think it will be great if you could share some of your tips to get this quality of lighting.

thanks.

I might actually do that during the holidays!

[Kafumanto]

Hi Epic! I saw there is now a documentation page about “Physical Lighting Units” (Physical Lighting Units | Unreal Engine Documentation). It would be great to have also some official guidance on how to make a realistic outdoor lighting setup, as the default values (for lights and in the templates) don’t seem correct (or I’m wrong?). Thanks!

[rosegoldslugs]

@Kafumanto

Hi Epic! I saw there is now a documentation page about “Physical Lighting Units” (https://docs.unrealengine.com/en-us/…icalLightUnits). It would be great to have also some official guidance on how to make a realistic outdoor lighting setup, as the default values (for lights and in the templates) don’t seem correct (or I’m wrong?). Thanks!

Documentation is updated to explain some of the workflow/changes, but as far as reference values go, there aren’t any on the documentation page. But there’s a ton of information out there that you can start with. Go back through the last ~5 or so pages to find some other examples of real-world values being used in the engine. wants to add reference values though, so perhaps early next year:​​​​​ as seen from his post a few weeks ago:

@Tim_Hobson

One thing that did not make the documentation with this most recent update for 4.21 is a section detailing the workflow for using the PLUs and Auto-Exposure. It’s something that I want to add along with some reference values to use for different lighting situations (ie, sunny day, overcast, night, etc) that are in line with what you can find on other sites with tables of exposure values (for example, Wikipedia).

Just know that it’s still on our minds to add these things and reduce the confusion (as much as possible). Unfortunately, I don’t have an ETA, but I’ll push to get something added before the end of the year (which isn’t really that far off!).

Tilmann - Nice tests. Good to see things are working for you! I’m always a fan of that “blue hour” type of lighting like in the second shot. The lights/light sources are reading well too.

You should try measuring some light values next time to go along with your camera settings. I’ve had pretty good luck with some smartphone apps that use the ambient sensor. Might not be the most accurate, and they’re usually full of ads, but the values I’ve gotten with my Pixel 1 have been in the ballpark range no different than what we get with online resources. Just hold it horizontally, facing up and you can get the measurement like you would with a flat white plane horizontally in the scene, after conversion. To be even more accurate, you could shoot in sLog and send it through the ACES ODT to sRGB

[Kafumanto]

@rosegoldslugs

Documentation is updated to explain some of the workflow/changes, but as far as reference values go, there aren’t any on the documentation page. But there’s a ton of information out there that you can start with. Go back through the last ~5 or so pages to find some other examples of real-world values being used in the engine. wants to add reference values though, so perhaps early next year:​​​​​ as seen from his post a few weeks ago:
…

Thanks @rosegoldslugs !

[Xiaowantou]

@Daedalus51

Good question but a different topic!

Would need to investigate. Theoretically, there should not be any difference between the two when using exactly the same levels of brightness.

Cheers!

Hey Shifu, I use the same workflow as Coach mentioned, especially for the interior scene, I like using specific HDR on skylight to get more color on the secondary bounce.
However, I’ve also switched in between the captured skylight and the specific HDR skylight, the brightness in Skylight [Stationary] seems similar, but if I choose static skylight, the HDR specified skylight went way darken after the baking process.

Probably I did something incorrectly on my bake setting 0_O, would be nice if we have more follow up on this topic XD!

[Daedalus51]

@Xiaowantou

Hey Shifu, I use the same workflow as Coach mentioned, especially for the interior scene, I like using specific HDR on skylight to get more color on the secondary bounce.
However, I’ve also switched in between the captured skylight and the specific HDR skylight, the brightness in Skylight [Stationary] seems similar, but if I choose static skylight, the HDR specified skylight went way darken after the baking process.

Probably I did something incorrectly on my bake setting 0_O, would be nice if we have more follow up on this topic XD!

Hey!

Could you guys open a new Thread for this topic and ping me in there so I know where to look?^^

I might have time to look into this soon and I can also give Daniel Wright a shout after I dug a bit into it and see if there is anything unexpected from an engine point of view

Cheers!

[Nepfish]

@Daedalus51

PS: I totally forgot to mention the bugs I encountered!

1. eye shader seems to be broken as eyes render black when using physical values (I have pre-exposure turned on)
2. skin doesnt show spec anymore
3. the hair of her is set to black, for some reason it renders light brown when using physical values
4. black dots on water reflection on the daylight shot

The eye shader is broken due to it looking at the scene color (which gives incorrect results when pre-exposure is turned on). So unchecking pre-exposure will fix that or an even better solution is to simply divide your result in the shader with a EyeAdaptation material node. This takes the correct exposure in mind and adjusts it accordingly.

An annoyance of this new physcial based lighting workflow are 3D widgets and other unlit UI shaders (VR comes to mind), because they are affected by exposure values. They will look vastly different in every scene because of the huge varying EV values. They will be either too bright or too dark depending on whether you have a night or day scene. Sure it can be easily fixed by adding the EyeAdaption node I mentioned above but it’s something people will have to know it exists ^.^

[MysteryBlues]

Thank you all for the good amount of info on using exposure with extended range, physical light units etc.

Here’s a very very simple blueprint that you can drop in your scene to convert the Luminance values the Pixel Inspector gives when you sample a surface from cd/m2 to Lux (lumens/m2) and displays it as text in the viewport.
I don’t know how useful it is (as to convert from cd/m2 to lux is almost multiply by 3 in your mind - well, actually Pi: 3,14149) but I was here resorting to the calculator again and again to get exact values.
You have to input the luminance value in the Details Panel to see the result in lux.

https://www.dropbox.com/s/9busn0vkbx…or_BP.rar?dl=0

(made using 4.21 - there’s an exported blueprint and unlit material using emissive for the text - to make it bright only put big values for emissive multiplier in a material instance, or leave with the default text material - I exported them as unreal text objects .copy)

Maybe someone can extend the blueprint by adding a reference to the skydome’s material/material instance to pick its multiplier parameter, use some math nodes etc, so that the converted value updates automatically. Anyway, a very simple blueprint, but as it was done, why not share?

Thanks to the info on this thread I was able to get a properly lit scene using the extended range + exposure in 2 days of experimenting.

One question: is there a way to make the Unlit view mode work well with sunlight values like 120,000 lux without blowing up in white? Also the Scene Color buffer visualizer…

[Daedalus51]

@Nepfish

The eye shader is broken due to it looking at the scene color (which gives incorrect results when pre-exposure is turned on). So unchecking pre-exposure will fix that or an even better solution is to simply divide your result in the shader with a EyeAdaptation material node. This takes the correct exposure in mind and adjusts it accordingly.

An annoyance of this new physcial based lighting workflow are 3D widgets and other unlit UI shaders (VR comes to mind), because they are affected by exposure values. They will look vastly different in every scene because of the huge varying EV values. They will be either too bright or too dark depending on whether you have a night or day scene. Sure it can be easily fixed by adding the EyeAdaption node I mentioned above but it’s something people will have to know it exists ^.^

Well…it was also said that pre exposure needs to be turned on to fix the other issues or am I actually mixing this up now?

Regarding unlit materials, thats exactly how it should be!

We had the same issues on Star Wars as the lightsabres use a unlit material with emissive! In reality, if they would have a static value, like our unlit shader, you wouldnt see the lightsabres during day but they would glow strong during night! In movies, they fake it per shot…so using the exposure node in the shader is exactly the correct option for gameplay purposes

So I am quite happy for all these things falling into place like this

[MysteryBlues]

Regarding this I said above

One question: is there a way to make the Unlit view mode work well with sunlight values like 120,000 lux without blowing up in white? Also the Scene Color buffer visualizer…

Actually the (sun) directional light is not blowing the buffer visualizers as I said. It’s the skylight. Turning off “Affect world” temporarily for the skylight brings back the values for the visualizers. The directional does not affect/blow them. Weird.

[MysteryBlues]

Another very simple blueprint to temporarily fix (the lighting for) UnlitMode etc - for when you are checking your Base Color values etc.
While we wait for Epic to fix the Unlit mode preview while using the extended luminance range + physical real-world values for lights.

UnlitCheck_BP.rar

As you can see in the screenshot, you just have to assign the sun directional and skylight actors, and mark “Check Unlit mode”. It will turn both actors to invisible, and the “UnlitCheck” directional light component in the blueprint to visible - this light has the default 3.14159 intensity. Unchecking will revert these lights to their previous visibilities.

Again, very simple, but as I made it here, why not share?

[rosegoldslugs]

If you’re checking your Base Color values, you should do it in the Base Color viewmode. Unlit includes other things, altering what the actual Base Color is.

[MysteryBlues]

@rosegoldslugs

If you’re checking your Base Color values, you should do it in the Base Color viewmode. Unlit includes other things, altering what the actual Base Color is.

Ah, thanks for pointing out. I actually meant Unlit, not BaseColor. The BaseColor viewmode works normally. The ones that seem to be blown out in white or black are Unlit, Final Image and SceneColor. Is this correct, or am I doing something wrong, missing a checkbox somewhere…?

rosegoldslugs, thanks for all the info on Exposure Values in the thread here. And that tutorial where you re-lighted the sci-fi room in the space station is awesome. One of my saved references here for lighting in Unreal.

[anonymous_user_cb9ec8a0]

hi all.

i get an error using Luoshuang’s GPU:

there are my Lightmass settings with traditional method (intensity 1, auto expurse)

https://forums.unrealengine.com/filedata/fetch?filedataid=155278&type=thumb

if i use Deadalus51’s settings (intensity 70.000 manual expurse, camera 100/125/14) i get all meshes black

if i use Deadalus51’s settings with auto expurse (intensity 70.000 auto expurse but compensation using) i get correct interiors burning exteriros

https://forums.unrealengine.com/filedata/fetch?filedataid=155279&type=thumb

it means Luoshuang’s GPU have a bug with strong dome intensity?

[rosegoldslugs]

@coach

hi all.

i get an error using Luoshuang’s GPU:

there are my Lightmass settings with traditional method (intensity 1, auto expurse)

https://forums.unrealengine.com/filedata/fetch?filedataid=155278&type=thumb

if i use Deadalus51’s settings (intensity 70.000 manual expurse, camera 100/125/14) i get all meshes black

if i use Deadalus51’s settings with auto expurse (intensity 70.000 auto expurse but compensation using) i get correct interiors burning exteriros

https://forums.unrealengine.com/filedata/fetch?filedataid=155279&type=thumb

it means Luoshuang’s GPU have a bug with strong dome intensity?

This would belong in Luoshuang’s thread, but you’re not the only one with this issue. I posted about it on this page and it seems like there are some other people having the same issue.

[anonymous_user_cb9ec8a0]

ok thanks. i will try to understand more about it.

(i also would like to know if someone alse with 4.21 working fine)

[pf_breton (Pierre-Felix Breton)]

@MysteryBlues

Another very simple blueprint to temporarily fix (the lighting for) UnlitMode etc - for when you are checking your Base Color values etc.
While we wait for Epic to fix the Unlit mode preview while using the extended luminance range + physical real-world values for lights.

Dropbox - UnlitCheck_BP.rar - Simplify your life

As you can see in the screenshot, you just have to assign the sun directional and skylight actors, and mark “Check Unlit mode”. It will turn both actors to invisible, and the “UnlitCheck” directional light component in the blueprint to visible - this light has the default 3.14159 intensity. Unchecking will revert these lights to their previous visibilities.

Again, very simple, but as I made it here, why not share?

@MysteryBlues how do you load those .copy files in unreal? Do you have my any chances the uassets to share instead? (I am interested by your light meter BP ) We tried to load them in 4.21 in a couple ways and we don’t get the expected results.

[MysteryBlues]

MysteryBlues how do you load those .copy files in unreal? Do you have my any chances the uassets to share instead? (I am interested by your light meter BP ) We tried to load them in 4.21 in a couple ways and we don’t get the expected results.

@pf_breton, sorry, I just right-clicked and chose “Export” without even checking how .copy files were used etc. I searched here and someone mentioned this .copy is deprecated, or not used at all.

Here is the .rar file with the the blueprints Unlit_Check_BP, LuminanceLuxCalc_BP and its material and mat. instance:
https://www.dropbox.com/s/xkiu13r2w8…Utils.rar?dl=0

(I just copied the uassets and zipped them together. I guess they’ll work, as the only reference is to the material and mat. instance in the file)

The calculator is very very simple. Ideally it should have something in the blueprint graph like PixelInspector.GetLuminance connected to the text component. I’ve tried typing “Pixel” in the blueprint event graph to see if the Pixel Inspector window had been exposed to blueprints, but found nothing. And I’m busy now to dig more into that.
Hope it helps you.

Edit: typos

Edit: Regarding the .copy format, I tried here changing the extension to .txt and it seems like they’re like what you get when you select nodes in the material editor (or blueprint editor etc) and ctrl+C.