Announcement

Collapse
No announcement yet.

4.19 Physical Lights

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    I made an editor widget that acts as a calculator to convert luminance to a more intuitive unit for lighting, illuminance, while also getting the associated EV and the respective shutter speed/aperture. Here's a Twitter thread to explain the reasoning as well as talk about the updated editor viewmode in 4.24 that measures luminance and illuminance. And here's the Github link to download my updated shader for 4.24 and 4.25 with EV in the viewmode

    Leave a comment:


  • replied
    Originally posted by Rawalanche View Post
    It seems that the physical lighting scale was somehow hacked into the engine, but when I try to actually use it, I encounter quite a few engine areas which just aren't built to handle that...
    What other areas? The only issue I've ran into in recent versions is Convolution Bloom doesn't work as expected at higher luminance ranges used by physical units.


    Originally posted by schauk View Post
    so,i m also encountering many issues regarding emissive / unlit shader und previewing the scene. i get that emissive materials are linked to the exposure of the scene, but "unlit" materials arent "unlit", they are also somehow linkend. to solve that i d get the current ev100 value in the material and multiply by that, but thats not possible right now natively. would be great to get such node. else pbl by now break most of unreal s other features. basically all widgets are unreadable but even countering using arbitrary emissive multiplicators doesnt look right. also previewing is a nightmare. especially before baking the lights, everything is just off.
    It's kind of hard to follow you. Unlit/emissive materials aren't linked to exposure, but your exposure relative to the emissive intensity will determine whether or not it looks correct, or is even visible at all. And to echo what I asked Rawalanche, what are these other broken features, and widgets, you're referring to?

    Leave a comment:


  • replied
    so,i m also encountering many issues regarding emissive / unlit shader und previewing the scene. i get that emissive materials are linked to the exposure of the scene, but "unlit" materials arent "unlit", they are also somehow linkend. to solve that i d get the current ev100 value in the material and multiply by that, but thats not possible right now natively. would be great to get such node. else pbl by now break most of unreal s other features. basically all widgets are unreadable but even countering using arbitrary emissive multiplicators doesnt look right. also previewing is a nightmare. especially before baking the lights, everything is just off.
    Last edited by schauk; 04-09-2020, 05:14 PM.

    Leave a comment:


  • replied
    I had the same concern and experienced the same issue. I had an interior scene that I re-worked with light values and settings based on this thread. All good until I noticed there are fx elements with emissive textures that are not compatible.

    Leave a comment:


  • replied
    Hi,

    sorry for necromancing this thread but I still fail to understand the new physical lighting workflow. Let's say I set up lighting in my scene according to real photometric values, so that during sunny day noon, the sun intensity is around 111 000 lux and indirect sky intensity around 20 000 lux. If I use real world camera settings, such as f/16, ISO 200 and 1/125 shutter, I get more or less what I'd expect.

    BUT!

    look development of emissive materials becomes borderline impossible. Even if I set preview scene settings in the material editor to match the exposure range, thumbnails of the emissive materials with emissive values large enough to be visible under EV100 daylight setup are pitch white in the content browser:
    Click image for larger version

Name:	emissive.png
Views:	455
Size:	52.6 KB
ID:	1737221

    It seems that the physical lighting scale was somehow hacked into the engine, but when I try to actually use it, I encounter quite a few engine areas which just aren't built to handle that...

    Leave a comment:


  • replied
    Originally posted by Kel Solaar View Post

    For future reference, we spent a few hours digging and found out where the 1.2 value is coming from: It is actually normative as per ISO12232:2006, i.e. an ISO Standard derived value, referenced in Wikipedia, in Moving Frostbite to Physically Based Rendering 3.0 (and confirmed by that bit of maths in Unity code):

    Code:
    1. // Compute the maximum luminance possible with H_sbs sensitivity
    2. // maxLum = 78 / ( S * q ) * N^2 / t
    3. // = 78 / ( S * q ) * 2^ EV_100
    4. // = 78 / (100 * 0.65) * 2^ EV_100
    5. // = 1.2 * 2^ EV
    6. // Reference: http://en.wikipedia.org/wiki/Film_speed

    Cheers,

    Thomas
    So Epic has just documented that whole thing properly which is great: https://www.unrealengine.com/en-US/t...posure-in-4-25

    Thanks!

    Leave a comment:


  • replied
    Sorry to bring back this thread from the dead, although I have to say, it was really interesting from the first page.
    The thing is, I'm finding a large discrepancy between what I get in Unreal and what I'd expect, but I'm not an expert on the field so I want to be sure that I'm not the one doing something wrong.
    I'm working on an archviz scene and I'm testing physical light values, but while I'm getting a good looking result with sun and sky lights, artificial lights seem off.

    I've got a completely dark scene, except for a point light at 800 lm, at 1mt from both walls and 1.80mt from the floor. The camera settings in the PPV are 1/60 for the shutter speed, 100 ISO, 2.0 f-stop, so around EV 8. As you can see by the screenshot the room appears very dark and the light is barely visible. I can't understand if this result is correct or not, but from the tests I made with my phone's camera with exposure settings set to manual, it's very dark compared to real life. The second screen shows the base color, and you can see my textures are not too dark. Can anyone help me understand if there's still something wrong with Unreal, or if this behaviour is expected? To me it looks like the issue that Daedalus51 had with 4.19, when a good eye-balled value was around 10x the expected lumens value.
    Also, I've disabled every PP effect that might add shadows/influence lighting.

    Click image for larger version  Name:	HighresScreenshot00002.jpg Views:	0 Size:	119.4 KB ID:	1721856

    Click image for larger version  Name:	HighresScreenshot00004.jpg Views:	0 Size:	159.9 KB ID:	1721857

    Leave a comment:


  • replied
    Hello everyone. I have been following this thread for a while, and I have been trying to figure out physically based lighting in UE4. I have come up with a tool set and workflow, that so far works for me. Check out this tutorial I made, tools are in the description.

    Leave a comment:


  • replied
    Originally posted by FurryFur View Post
    I'd also like to get some more info about this exposure formula (Exposure = 1 / (1.2 * 2^EV100)).
    Where exactly does this come from? in particle the 1.2 value?
    I assume by exposure here you mean the average scene luminance in cd/m^2 that the game will adjust to?
    For future reference, we spent a few hours digging and found out where the 1.2 value is coming from: It is actually normative as per ISO12232:2006, i.e. an ISO Standard derived value, referenced in Wikipedia, in Moving Frostbite to Physically Based Rendering 3.0 (and confirmed by that bit of maths in Unity code):

    Code:
    1. // Compute the maximum luminance possible with H_sbs sensitivity
    2. // maxLum = 78 / ( S * q ) * N^2 / t
    3. // = 78 / ( S * q ) * 2^ EV_100
    4. // = 78 / (100 * 0.65) * 2^ EV_100
    5. // = 1.2 * 2^ EV
    6. // Reference: http://en.wikipedia.org/wiki/Film_speed

    Cheers,

    Thomas

    Leave a comment:


  • replied
    Thanks a lot for your response!

    Here two screenshots of the test I did on a scene I took from the market place.

    Click image for larger version  Name:	NoPhys01.JPG Views:	0 Size:	118.9 KB ID:	1689097Click image for larger version  Name:	Phys01.JPG Views:	0 Size:	117.4 KB ID:	1689098

    On the left, it is from the non-physical lighting values, and on the right, it is the physical lighting values.

    'non-physical' method settings:
    Dir intensity : 4 lux
    sky light intensity : 1
    HDR texture (captured by the sky light) : brightness of 1

    I set a fixed exposure that looks good to me for the interior of the train.
    Exposure : Set to Auto Exposure Basic
    Min brightness : 0.2
    Max brightness : 0.2


    'physical' method settings:
    Dir intensity : 128 000 lux
    sky light intensity : 1
    HDR texture (captured by the sky light) : texture multiplied by 25000 (to have a luminance around 5000 cd/m2 in the clouds). But other than the brightness, the texture is the same.

    Exposure : Set to manual
    Camera settings :
    Shutter speed : 100
    ISO : 100
    Aperture : 6.8


    Everything else is the same (lightmass settings etc..).

    The exterior lighting looks the same also on the two methods and both contributions of the sky and the sun look the same. Other than the emissive that don't work with the physical values (I guess I have to increase a lot the emissive's values), I see some other differences. In general, physical values give more accuracy and realism I think...

    But I agree that the overall brightness of the character doesn't change drastically... So going with the physical values in my project won't really solve my problem of having dark characters... I will need to cheat on that.
    Last edited by klusky27; 11-20-2019, 09:42 AM.

    Leave a comment:


  • replied
    Physical values shouldn't really change much, you can visually get the same result without physical values - they just make it more consistent/easier. When you set up your arbitrary values, how close did they match your physical setup? Did the sky change other than the intensity? And, how was your exposure? A lot of people skip the exposure step, which has a huge impact on all lighting.

    Regardless of how you do the lighting, there isn't a simple way in stock Unreal to boost characters only other than material tricks or character-only lights with lighting channels.
    Last edited by rosegoldslugs; 11-19-2019, 08:22 PM.

    Leave a comment:


  • replied
    Hello everyone!

    I hope this thread is not dead
    Sorry if you already answered my questions but I really tried to read all the responses!

    So now, are some of you actually working with physical lighting values? Do you still have issues with the exposure and with the material reflections?

    I would like to use this physical 'method' in the project I am working on. I am working on huge environments (big caves with high ceilings) and I tend to find reaalllly difficult to have indirect lighting from my lights on the players. Right now I am using a 3 lux intensity for my directional light and 1 for the skylight (which captures a skybox whose texture brightness is set to 1).
    Even though I can achieve good lighting for my environment (also by adding some fill lights here and there), the volumetric lightmaps are suuuuper dark, so the players are also really dark. They don't fit with the environment at all, and I don't want to add more light since I want to keep a mysterious and dark mood.

    My first thoughts were that I use really low values for my sky and sun and all the other lights, so they don't create so much indirect lighting.
    I tried using physical lighting values on a test scene: I increased the sun to 100 000 lux, increase my skybox texture to 5000 cd/m2, and changed the exposure mode to 'manual' with the proper settings in the camera so that it is not super bright. I baked the light, and looked at my volumetric lightmaps, and theeen it made a lot more sense. They were not black anymore and fitted well in the environment. With the same test scene, I did the lighting using the other method (sun = 3 and sky = 1) and achieved approximatively the same look, but after baking, the volumetric lightmaps were dark.

    So I guess using physical lighting values may help! But I don't wanna f*ck the whole project and the materials and stuff if there are still some issues regarding this way of doing.
    Would you advise me to go with that? If no, how do you do to make your players brighter when you don't wanna make the environment brighter? Maybe I do something wrong in my lighting ...

    Thank you a lot for your response! I am struggling soo muuuuch with that

    Leave a comment:


  • replied
    Originally posted by rosegoldslugs View Post

    I believe you're referring to 2 separate GI methods from NVidia powered by RT cores. It's confusing because NVidia calls everything RTX, when that's the hardware/brand name, and they purposefully change names to resemble RTX(i.e. see the Square Enix path traced demo being referred to ray tracing with RTX... two separate things and fully path traced images are way more impressive, but there's no "PTX" to market right now) Btw did you get to work on that?

    RTXGI is the standard method of sending rays to the scene with x samples per pixel
    DDGI is another method that uses raytracing on top of previous methods of Spherical Harmonics/probes to improve visibility/light leaking, dynamic updates, etc

    I actually double checked on this and NVidia's main page changes Morgan's writeup from DDGI to RTXGI:

    NVidia: https://devblogs.nvidia.com/rtx-glob...nation-part-i/
    Morgan McGuire's site: https://morgan3d.github.io/articles/...dgi/index.html
    Yeah, the RTXGI and DDGI I am referring to is the same thing. They just changed the naming to get "RTX" in there, but I think it just makes it more confusing.

    from your first link:
    "We first presented RTX GI as Dynamic Diffuse Global Illumination (DDGI) at GTC’19 and GDC’19 in the NVIDIA sponsored sessions."

    No, I did not work on the path traced demo. I was on Kingdom Hearts III and FF7R.

    Last edited by 2car; 10-08-2019, 05:21 AM.

    Leave a comment:


  • replied
    As far as I understood from the "Ray traced irradiance fields" (that is the basis of RTXGI) presented at this years GDC, RTX was not a requirement. It would just be able to cast more rays within the allotted ms budget.< yes.

    Leave a comment:


  • replied
    Originally posted by 2car View Post

    As far as I understood from the "Ray traced irradiance fields" (that is the basis of RTXGI) presented at this years GDC, RTX was not a requirement. It would just be able to cast more rays within the allotted ms budget.
    I believe you're referring to 2 separate GI methods from NVidia powered by RT cores. It's confusing because NVidia calls everything RTX, when that's the hardware/brand name, and they purposefully change names to resemble RTX(i.e. see the Square Enix path traced demo being referred to ray tracing with RTX... two separate things and fully path traced images are way more impressive, but there's no "PTX" to market right now) Btw did you get to work on that?

    RTXGI is the standard method of sending rays to the scene with x samples per pixel
    DDGI is another method that uses raytracing on top of previous methods of Spherical Harmonics/probes to improve visibility/light leaking, dynamic updates, etc

    I actually double checked on this and NVidia's main page changes Morgan's writeup from DDGI to RTXGI:

    NVidia: https://devblogs.nvidia.com/rtx-glob...nation-part-i/
    Morgan McGuire's site: https://morgan3d.github.io/articles/...dgi/index.html

    Leave a comment:

Working...
X