^^ I agree.
the entire thing is confusing and as much as I tried using the (already confusing or contradictory) advice on this thread I ended up having a pitch-black or a completely overblown lit world, or something that was somewhat similar but with something that was always off (ie. direct light ok but completely black skylight)
my biggest issue following this thread was this “EV” value which doesn’t exist anywhere (except the viewport preview setting in the “Lit” dropdown, which is that, just a preview)
Build in lighting rig with few paremeters/presets. Ie, just light intensity (for easier setup if you need something to work out of box).
Why SkyLight does not derive it’s intensity from Directional Light intensity. The two are needed and complimentary. It would be much easier to control both using single slider, than doing guess work.
Why not add reasonable presets for Camera eye adaptation ?
Turning pre-exposure on seems to fix convolution bloom aswell but breaks CircleDOF, creating alot of noise in bright scenes. Also, the console command r.UsePreExposure doesn’t seem to work.
Although careful! The skylight brightness should NOT be related to the directional light at at! The skylight should always sample the skydomes brightness and should not have a brightness itself as thats confusing. For artistic needs there can be a multiplier to make it artificially darker or brighter, but it should not have a brightness slider in lux or whatever. So basically the way it is right now is perfect if people stop using the brightness as brightness. Just leave it at 1 and increase your sky brightness by either multipliying your HDRi up in your material OR by increasing the Directional Light intensity which makes the atmospheric fog brighter (there is your sun sky relationship!)
You dont want to link skylight brightness do directional light brightness as again, the important relationship is how the sun affects the skydome, the skylight just samples whats there. So you want the sunlight to have an effect on the skydome! Of course thats not happening when using HDRs, which is why sunny 16 and measured values become more important and otherwise, when using the physical sky via atmospheric fog, it works exactly like that already…so thats great!
Regarding your last post…sooooo Epic is already secretly rewriting the system? Or do you mean something else by lighting model? Super curious now^^
IDK I haven’t looked at code, but the value you provided in one post (125000 for sun 16/EV) and scene is just white, regardless if there is SkyLight on scene or not. I guess something changed.
Yes, that’s what I meant. That brigthness of sun should controll brightness of sky, which should in the end controll brightness of ambient light over scene. Right now for me it was pure guess work to get something reasonable to work in 4.20. I ended up using Auto Exposure, directional light at 5 and Skylight 0.3-0.4,
What type of sky did you use? default skydome or atmospheric fog? Again…you should never need to touch the skylights intensity as the sky brightness comes from the sky. Nevertheless…these values sound completely random XD
Can you try using an HDRi mapped to the skydome? Then just multiply it up until it becomes visible with EV 16. If you then just put the sun to something around 120k it should look kinda okay-ish. You might need to add an exposure compensation of 1.5 - 2.
Also really make sure you lock everything in manual at 1/125, ISO 100 and EV 16. I am just suggesting things here…if it doesn’t work then it doesn’t I will not try 4.20 until there is a preview build^^
I just tried a view scenes of mine and all i can say so far, it’s a absolut disaster… i really hope this will be fixed/replaced soon or epic will provide us a demo scene where they expalin in detail on how to work with this mess.
If veteran users/developers like Daedalus51 or Maximum-Dev have trouble to setup a “correct” good looking lighting, epic should be really ALARMED, especially when we consider that most of the UE4 users/developers even don’t come close to the knowledeg of a DICE working lighting artist.
Good looking/realisitc lighting setup should become easier to setup not harder… So beginners or not so advanced users, have the chance to setup at least something good looking quick, without beeing a lighting pro.
For me is not even that I want my scene to look good with the new Lightning Units/System anymore. I was in the middle of a project when I realized the lights were way off compared to the previous model and jumped back to 4.18 faster than you can say “Candela”
Now I just want to Understand what’s going on under the hood.
Even if the old system was flawed and not-so-physically-based-as-it-looked, It was well documented and It was relatively easy to jump in.
I have no doubt this new system is better and the changes are for the better in the long run. But it needs to be documented/normalized/standardized sooner than later.
If those Exposure Control numbers everyone is pointing (within a range variations) are the standard photographic numbers for, say, a sunny day outdoor capture with iso 100. Souldn’t those be the standar numbers when we open the Editor?
The problems with the Underexposed Skysphere material that some are pointing at for ej., man, those look a lot like a poor global implementation of the lighting system.
For me the big problem has to do with standards. Epic needs to unify the system. If we have standard autoexposure compensation values and tonemapping when we open a project (hell we even have a “standard” scene with a sky and a directional light already in there!) why we can’t have the same for the camera settings, aperture etc? why can’t the Directional Light and the skylight come straight out of box balanced with point lights in some form or another?
for the sky material aren’t already a couple of standards for sky brightness colors like those CIE pelham and stuff? can we get those? and balance those with wathever the sun should be balanced? or am I talking nonsense? (maybe the brightness difference is too strong and can’t be balanced, I’m not an expert in the field in any way)
But if it can be balanced… THEN let the user, say… double the directional light intensity and put the bulbs in 4000000000 foot candles or wathever the want, But starting from a “correct” camera exposure & light brightness (let’s say… standarize everything with the default level that comes with the sky and the directional light, and let the users start from there)
The goal of this? that the not-so-proficient in lighting physics (like me but I Imagine there’s others) can punch a couple of numbers in the editor and get… I’m not saying an acceptable Image from the get go, but at least a Predictable one like: “I’m halving this light power” “doubling it” “I pasted this lumen values from this vendor and the light values I get are acceptable” or even “I’m now making a point light that shines equal to the Sun/directional ligth” or wathever.
This half and half standarized thing is a mess. Seems like half the engine is trying to look good from the start (with things like bloom, lens flares, vignette enabled by default) and the other half is trying to be physically accurate, go one way or the other Epic.
Also… we are talking LIGHTS here… that’s a central part of the engine in my opinion, unless you’re working on a super stylized project or only programming in blueprints/AI a user gonna have to deal with lights at some point or another, so document everything when you do changes like this, we need reference from the source.
Yeh, I guess there are a few problems that arn’t epics fault though. The exposure system and physical light values were only recently added. Two systems for simple and advanced lighting would cover all use cases but is hard to implement. And a physical based system for lighting in a real time game engine is always going to complicated because there is a limit to how simple a heavily approximated dynamic system can be with so many variables. Maybe vrays solution could work.
You’re going to watch your children grow up and get married while waiting for response here.
But seriously, Epic, wouldn’t you want to try and collect some feedback on new engine features you put out? because at the end of the day if we can’t use them, your work is wasted. ^^
@
The sky light is definitely not using units of Lux, it actually appears to use units of cd/m^2, could you please clarify?
I tested the sky light by capturing a perfectly white sky sphere (measured with the pixel inspector to have a scene color / hdr luminance of 1.0) and using this to light a perfectly diffuse white sphere. Testing the luminance of the sphere with the pixel inspector reports a luminance value that is almost exactly 1.0 cd/m^2. Which suggests that the sky light is, in fact, using units of cd/m^2 and not lux (lm/m^2). A directional light of intensity 3.14 is required to get similar luminance values on the brightest part of the sphere. This makes sense since a purely diffuse BRDF would just multiply the incoming Illuminance (Lux) by 1/pi to convert to outgoing Luminance (cd/m^2). So either the sky light is actually a luminance value (cd/m^2), or someone forgot to multiply by 1/pi somewhere, but I’m guessing it’s the former.
The second issue I have is that the HDR Luminance values I read from the pixel inspector don’t seem to match up to a given EV100 value. For instance, I created a room lit entirely by a single point light of 1400 Lumens with a temperature of 3000K. The room was roughly modeled off the dimensions of my bedroom, the lumens and temperature values of the light bulb were taken from the actual bulb that lights the room. Using my phone camera (it has a manual mode where I can check ISO, shutter speed, and f-stop) I know that I need an EV100 of about 5 for this room to look correct. Using these values the room does actually appear correct, however, when I look at the pixel inspector I see an average HDR Luminance value of around 20. From the Wikipedia page of exposure values (Exposure value - Wikipedia, table 3) I can see that for an EV100 of 5 I would expect an average scene luminance of about 4 cd/m^2 which does not match up at all with the values I am getting.
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?
I think your math might be a bit off here. A 75000 candela spot light with a cone angle of 45 degrees would be equivalent to the same spot light with about 138000 lumens. So your 100000 lumen light actually matches up with the candela value you used.
THANKS for sharing your settings!! Beautiful lighting.
So the sky brightness in this scene is 5000 cd per square meter. What value would this be in lux? Lux is lumen per square meter and the internet seems to suggest that I can simply convert 1:1, therefore 5000 lux? This would be suspiciously simple. So the skylight has 4% the intensity of the sunlight?
Or do you mean something else by lighting model? Super curious now^^
