Announcement

Collapse
No announcement yet.

4.19 Physical Lights

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

    Still no answer?
    I agree with Sickmoocow this is super basic stuff.
    Light = what we see inside the engine.
    We ended up doing the last job on unity 2018. We simply can't afford to take the radio silence from epic's side on this topic.

    Kalvothe any news on this?

    Comment


      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
      Last edited by Tim Hobson; 09-17-2018, 11:32 AM.
      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
        I noticed that with Pre-Exposure enabled in the current build, the Pixel Inspector doesn't show the same values as with it disabled. Will this be fixed at the same time? When using physical units, I've had to work with it disabled, get my HDR Luminance values to be around the correct cd/m²/nits, then enable it again afterwards. Not a fun process since it has to keep recompiling shaders each time

        Thanks for the heads up though! Looking forward to what you guys do to make it more intuitive.
        Lighting Artist @ Rockstar Games
        ArtStation
        Twitter

        Comment


          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


                    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).

                    Click image for larger version

Name:	Sieppaa.JPG
Views:	118
Size:	184.1 KB
ID:	1538188
                    Last edited by tmammela; 10-10-2018, 01:15 PM.

                    Comment


                      Originally posted by tmammela View Post
                      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.
                      Artstation
                      Join the support channel
                      Gumroad Store

                      Comment


                        Originally posted by tmammela View Post
                        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

                                Working...
                                X