Announcement

Collapse
No announcement yet.

4.19 Physical Lights

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

    rosegoldslugs

    It's not a process I'm fully aware of at the moment, which is why I had mentioned this not being an "official" statement from our engineers.

    The shader recompile was something that was mentioned by one of the engineers, but workflows and processes are something that Sam and I are planning to look at how best to document them along with some of the best practices to make things easier. We understand there is a lot of confusion (even on my part since I've not really used the new settings as extensively as you all have!), so we need to take the time and do the docs right on this part.

    WRT Pre-Exposure values, I'll bring that up to the engineers.

    Thanks!
    Tim Hobson | Learning Resources | Epic Games
    UE4 Documentation

    Comment


      Originally posted by Tim Hobson View Post
      Hey everyone,

      Apologies for the delay. I don't have an "official" response yet to all the concerns in this thread but know that we're carrying on some active conversations right now with some of the engineers and are looking at how we can address this in our Documentation.

      We're evaluating how we can best approach this to make the most of the new physical lighting units. Whether that is through examples in the doc, an example map, or something else is still to be determined, but we're actively looking at improving this. Also, in 4.21 we'll enable pre-exposure by default, which should help lessen confusion. There is also some setup between the physical lighting units and post process that we want to address to better tie these together and provide detailed example setups as a starting point.

      We'll be evaluating notes from our engineers along with reviewing concerns in this (lengthy) thread. I don't currently have an ETA for the changes to be implemented in the documentation but hopefully around the 4.21 release timeframe or shortly thereafter.

      If anyone has any thoughts or suggestions (that haven't already been mentioned), please feel free to post them here as we start to look at this over the next week or so.

      -Tim
      Nice to see you here Tim Hobson! Finally!

      About suggestions, I think that "draw a square and get the median HDR values from a selection of the sky" that Daedalus proposed in his video could be a useful addition to the pixel inspector, to get values from a surface area, not a specific pixel.

      Comment


        Hey Tim Hobson ,

        thank you so much for the response!

        I think the most important thing for us users is consistency...and thats why its sometimes tricky with the engineer way as you can see with, for example, the auto exposure feature (which is quite unintuitive to use for now).

        Personally, I think the two most important steps for now are:
        • Make auto exposure use fstops and iso etc. like the camera does so they are in sync and make sense
        • Enable a measuring viewmode that allows measuring the values across a certain screen area and not just pixels (whatever implementation would do)
        This way 2 big problems would already be solved as you a) have consistency between the modes and b) you can measure and verify values on screen and make sure everything works nicely together

        Those are...of course just my 2 cents!

        Cheers,

        Daedalus
        Check out UNREAL 4 Lighting Academy
        https://forums.unrealengine.com/show...ng-like-that-)

        Comment


          Just wanted to give an update here that 4.21 is going to include some improvements requested here to hopefully reduce confusion and make things that much easier to use. You should be able to check them out in the 4.21 previews when they start soon!

          Hopefully, I'll be able to provide updates to the documentation before 4.21 release, if not, it'll be shortly after! The release notes for 4.21 will have a lot of this information as well (in more detail)!

          To give you an idea here is a short list of what's been improved or added:
          • Improvements for how we display Light Units and Light Intensities for Point, Spot, and Rect lights.
          • Directional Lights now have Lux units
          • Sky Lights now have cd/m2.
          • Added Pre-Exposure support for the Pixel Inspector
          • Added new Project Settings to increase auto-exposure luminance range.
          • Updates for HDR visualization tools
          Note that this is just a highlighted list and there are more details and context to a lot of these than provided here. The engineers have reviewed this thread and added these based on a lot of the detailed feedback here! There are still some areas that still require work to be done in terms of units (such as Lightmass Environment Intensity and Exponential Fog Scatter Color) that we'll address in a future release.

          Once previews and the final release are out, please let us know what you think!
          Tim Hobson | Learning Resources | Epic Games
          UE4 Documentation

          Comment


            Originally posted by Tim Hobson View Post
            Just wanted to give an update here that 4.21 is going to include some improvements requested here to hopefully reduce confusion and make things that much easier to use. You should be able to check them out in the 4.21 previews when they start soon!

            Hopefully, I'll be able to provide updates to the documentation before 4.21 release, if not, it'll be shortly after! The release notes for 4.21 will have a lot of this information as well (in more detail)!

            To give you an idea here is a short list of what's been improved or added:
            • Improvements for how we display Light Units and Light Intensities for Point, Spot, and Rect lights.
            • Directional Lights now have Lux units
            • Sky Lights now have cd/m2.
            • Added Pre-Exposure support for the Pixel Inspector
            • Added new Project Settings to increase auto-exposure luminance range.
            • Updates for HDR visualization tools
            Note that this is just a highlighted list and there are more details and context to a lot of these than provided here. The engineers have reviewed this thread and added these based on a lot of the detailed feedback here! There are still some areas that still require work to be done in terms of units (such as Lightmass Environment Intensity and Exponential Fog Scatter Color) that we'll address in a future release.

            Once previews and the final release are out, please let us know what you think!
            This is great news! Thanks Tim Hobson

            Could you please give any update on aligning auto exposure to the camera values? This should be a simple fix as the values and settings already exist. I would argue that this is way more important than physicalizing the units of fog inscattering

            Thanks and cheers!
            Check out UNREAL 4 Lighting Academy
            https://forums.unrealengine.com/show...ng-like-that-)

            Comment


              Originally posted by tmammela
              Skylight at 1 cd/m2 (this unit doesn't make sense to me here, how can skylight have unit when it is derived from the skybox HDRI).
              Wondering the same thing for a while.
              Skylight intensity is tied to sky texture brightness/color, regardless of whether the sky is solid color, 8bit texture or 32bit HDRI. What would a physical unit on skylight mean in that case?

              Also exposure looks way off in the picture.

              Comment


                Originally posted by tmammela
                Heads up! Preview 1 is out. Going to test it when I get home from work. I really hope lighting system makes sense now...

                EDIT:

                This is what I get with manual exposure 125-100-16. Sun at 75 000 lux. Pixel inspector indicates a range of 1000 to 10 000 cd/m2 for the sky sphere. Skylight at 1 cd/m2 (this unit doesn't make sense to me here, how can skylight have unit when it is derived from the skybox HDRI).

                Emissive surfaces are expressed as cd m2 (nits). A sky box in hdr is using the pixel intensity multiplied by the light intensity, resulting in a total luminance, expressed in cd m2.

                Think of the hdr pixels as a filter . If your hdr image ranged from 0 to 1.0, and the sky set to 1000 cdm2, the resulting luminance would be 1.0 x 1000 cdm2.
                Pierre-Felix Breton

                Sr Technical Product Designer AEC, Unreal Engine
                Epic Games - LinkedIn

                Comment


                  The only proper way to use this is to set the skylight to 1....always! Then use a multiply on your skytexture and adjust the value until the pixel inspector shows the correct luminance value for the setting you want to achieve. For example, bright daylight with white clouds (not cloudy but fully lit clouds) the clouds should read around 10k candela/m2

                  At least thats the only consistent way I have found. Increasing the skylight beyond 1 gives you more light while the sky still reads the lower candela value and that again breaks the correlation of the values. You will get brighter indirect lighting and shadows while the sky itself looks way too dark and that will mess with autoexposure as well. So I would recommend to never touch it (read: only for artistic tweaks)

                  Cheers!
                  Check out UNREAL 4 Lighting Academy
                  https://forums.unrealengine.com/show...ng-like-that-)

                  Comment


                    Originally posted by Daedalus51 View Post
                    The only proper way to use this is to set the skylight to 1....always! So I would recommend to never touch it (read: only for artistic tweaks)
                    Cheers!
                    Correct. I'm glad you're pointing these things out instead of silently shaking your head like the rest of us .

                    In this case though I tried reporting the new cd/m2 skylight labeling as a bug on issues.unrealengine.com but was directed to this thread. Thankfully I have a UDN account and was told to try there also, where I did receive a developer response.

                    Here's a link, but you'll need to log in to UDN https://udn.unrealengine.com/questions/462412/view.html
                    Essentially, Brian Karis at Epic responded in detail and concluded with "I'll see what I can do."

                    I'll update everyone here if there's more news than that.

                    Comment


                      One approach that I implemented in a different life to solve this is as follow:

                      problem: unpredictable luminance of the sky due to unknown / unstandardized hdr values in hdr images, sometimes ranging from 0 to 1.0, 0 to 1000 or 0 to X.

                      solution: internally normalize the input image to force a range from 0 to 1.0, evaluate the Illuminance at an imaginary horizontal plane and scale by a user defined factor, resulting in lux .

                      benefit: no matter what image is loaded, hdr or not, the amount of light emitted by the sky box would always be the same. Then you get a true “horizontal lux” control and removed the unknowns.

                      The Sun and the Sky would the be controlled with lux values and be totally consistent.

                      Would that solution improve things for you?
                      Pierre-Felix Breton

                      Sr Technical Product Designer AEC, Unreal Engine
                      Epic Games - LinkedIn

                      Comment


                        Originally posted by pf_breton View Post
                        problem: unpredictable luminance of the sky due to unknown / unstandardized hdr values in hdr images, sometimes ranging from 0 to 1.0, 0 to 1000 or 0 to X.

                        solution: internally normalize the input image to force a range from 0 to 1.0, evaluate the Illuminance at an imaginary horizontal plane and scale by a user defined factor, resulting in lux .
                        TLDR; This creates a bigger problem and over-complicates things. The problem is simply that the UI shouldn't label skylights as cd/m2.

                        If sky textures/materials/captures are normalized then sky luminance would be unpredictable. Please don't normalize skylight input textures.
                        • If I knew the HDR sky texture was captured at EV100 10 before, I certainly wouldn't know what it would be after normalization
                        • If I have two version of the same sky: one with sun sun painted out and one with the sun visible: normalizing them both would look very different.
                        • Again, using skylight intensity other than 1.0 breaks the physically correct link between the visible sky and the light it emits.
                        • Would this also normalize the captured scene? This opens a can of worms: then you'd also want to normalize all reflection capture actors presumably? Let's not

                        Comment


                          [*]If I knew the HDR sky texture was captured at EV100 10 before, I certainly wouldn't know what it would be after normalization
                          ]
                          It would be a a luminance matching the defined horizontal illuminance, so direct correlation with physical units is actually brought to the surface.

                          Besides, I don’t understand what a HDR image captured at EV10 means for you. Can you describe what this means in terms of hdr pixel intensity? What luminance a pixel set to 21.56,21.56,21.56 means in this case?

                          AFAIK the whole point of HDR imagery is to capture the full range of luminance, thus eliminating the notion of exposure entirely ( a pixel value becomes fully linear making abstraction of non linear aspects introduced by cameras). then what is left is a notion of scale, like zdepth or height maps.
                          Pierre-Felix Breton

                          Sr Technical Product Designer AEC, Unreal Engine
                          Epic Games - LinkedIn

                          Comment


                            Originally posted by pf_breton View Post
                            solution: internally normalize the input image to force a range from 0 to 1.0, evaluate the Illuminance at an imaginary horizontal plane and scale by a user defined factor, resulting in lux .
                            I didn't fully catch that earlier, sorry.

                            Originally posted by pf_breton View Post
                            It would be a a luminance matching the defined horizontal illuminance, so direct correlation with physical units is actually brought to the surface.
                            I think I see what you're saying. I could go outside on a cloudy day with an incident light meter and measure maybe 1,000 lux facing straight up, then capture an HDR panorama of the sky. Back in Unreal the HDR panorama will be normalized and I could plug in my measured 1,000 lux. Right? It's not a bad idea as long as there's still a way to get a sunny and non-sunny texture to use the same scale if I wanted (they would output/measure different results in lux obviously).


                            Originally posted by pf_breton View Post
                            AFAIK the whole point of HDR imagery is to capture the full range of luminance, thus eliminating the notion of exposure entirely ( a pixel value becomes fully linear making abstraction of non linear aspects introduced by cameras). then what is left is a notion of scale, like zdepth or height maps.
                            Correct, any HDR texture used as a light source should have the full range (unclipped, linear), but we still need to know how those pixels relate to real world cd/m2. Most stitching/processing software (such as PTGUI) don't output in absolute luminance as cd/m2, but scale output based on the middle EV or some other scale, so the HDR is already "semi-normalized".

                            Originally posted by pf_breton View Post
                            Besides, I don’t understand what a HDR image captured at EV10 means for you. Can you describe what this means in terms of hdr pixel intensity? What luminance a pixel set to 21.56,21.56,21.56 means in this case?
                            If I shoot an exposure bracket and merge to an HDR, and the middle exposure was at EV100 13 (let's say ISO 100, f/8, 1/160s), I know that there is some relationship between those EV100 13 pixels and luminance. PTGUI says that 1.0 in the middle EV should correspond to white in the output HDR. So presumably I could take 21.56,21.56,21.56 measured in my HDR and scale by 13 EV (*8192, or some number/formula) and get 176,619 cd/m2 for that pixel. (looks like a pixel near the sun)! Another pixel from that HDR might be from the blue sunset sky and measure 0.04 (0.0301,0.0503,0.0860), but when we scale that knowing it was captured at EV 13 we get 327.68 in luminance (246.57,412.05,704.51).

                            I'm sure I could be making some wrong assumptions about the math, but when I go through the process on HDRs I've captured with corresponding incident light readings I'm within a stop or two of where I should be. I can also compare to Unreal's procedural atmosphere and check luminance with the pixel inspector, it's close. I'll leave the exact math to the researchers . What I do know is that labeling sky intensity as cd/m2 as it currently is will confuse people. I am glad you folks at Epic are at least trying to figure out ways to make physical lighting units less confusing
                            Last edited by william.sch; 10-25-2018, 02:16 AM. Reason: Additional quote added for clarity

                            Comment


                              I also think we're still talking about two problems. One is to remove the cd/m2 label from the UI (easy). The other is how to make photometric units more artist friendly and scaling these semi-normalized HDRs back to meaningful real world units (difficult).

                              Using either method could work:
                              • Evaluate the Illuminance at an imaginary horizontal plane and scale by a user defined factor, resulting in lux.
                              • Scale the HDR intensity using the photographic settings from when it was captured (only works if you know exactly how it was authored)
                              Either way, that scale would need to happen on the texture/skybox material side of things instead of the skylight (as @Daedalus51 mentioned). The best way to make that more intuitive would be if the skylight was visible as a light source instead of requiring a separate Static Mesh skybox.

                              Comment



                                I think I see what you're saying. I could go outside on a cloudy day with an incident light meter and measure maybe 1,000 lux facing straight up, then capture an HDR panorama of the sky. Back in Unreal the HDR panorama will be normalized and I could plug in my measured 1,000 lux. Right? It's not a bad idea as long as there's still a way to get a sunny and non-sunny texture to use the same scale if I wanted (they would output/measure different results in lux obviously).

                                This exactly the way this solution could work.
                                Pierre-Felix Breton

                                Sr Technical Product Designer AEC, Unreal Engine
                                Epic Games - LinkedIn

                                Comment

                                Working...
                                X