4.19 Physical Lights

Development Rendering
1

Hi I have a small question about the new 4.19 physical lights, the new version has changed the intensity to a choice of Candelas, Lumens and Unitless. I understand the difference between Candelas and Lumens, and that Unitless is the old 4.18 and older system, but in 4.18 and older I thought the intensity was a direct value of lumens if inverse square falloff was turned on?
If this is the case then what is the difference between the new Lumens and the old Unitless? I have tested a point light in the exact same scene in 4.17 and 4.19 with point lights with 1700 intensity/lumens, in the 4.19 scene the new Lumens setting is a lot brighter than the 4.17 scene. Of course if I switch the light to Unitless they become the same. What is the difference between the 2 models? If the 4.19 lighting model is the ‘correct’ physical lighting model, does that mean that 4.18 and older were using a wrong model?

Anyone know what the difference is between the new lumens and the old 4.18 lighting system?

2

The documentation for 4.18 and older was wrong. The “unitless” units do not behave like lumens, they behave like candelas. However, they are not candelas. Previously I thought they could be used 1:1 as candelas, however with the 4.19 implementation it appears they are much smaller than candelas. You’ll need about 1 candela for every 625 unitless units.

Directional and skylights are unchanged, but they’ve always been significantly brighter than point and spotlights, so they may compare well with candelas.

All in all, it’s great to see these are getting a proper implementation. Though, there are a few things I’m curious about:
IES profile lights, which really seem like the core reason to have physically correct lumens, but still seem to be standardized around unitless.
Source Radius and Source Length, as these have always been suspect, and are now extra suspect.

3

Versions before 4.19 had an issue with incorrect intensities, about -9 stops off according to Brian Karis.

I’m not sure if the new Lumens intensity is correct though, since the fix for accuracy is through a pre-exposure each frame and I’ve been unable to turn that on without the engine crashing.

4

There seem to be something weird about lumens intensity (or maybe I just don’t understand how lumens work).
I’m trying to light an indoor scene using multiple chandeliers with 10 bulbs each. Each real bulb would emit 300 lumens, so I used a single point light of 3000 lumens to replicate the overall lighting.
The result is way too bright, compared to the luminosity of the standard Sky Sphere, and with auto exposure off I have to use “Exposure Compensation” set to -3 to get something reasonably close to reality. What am I doing wrong?

5

By the way… using manual exposure with 800ISO 1/60 and 4.0 just with the sky sphere produces a complete black (it is necessary a compensation of +10 to achieve something realistic). There seems to be something quite wrong…

6

The standard sky sphere is extremely dark compared to the real daytime sky. Same with directional lights, their default value is a fraction of 1% of the brightness of the sun. It is very disappointing that they have only fixed point lights, while everything else is still unitless. What does it matter that the point lights use the right math if nothing else does?

7

Hey guys,

I was really looking forward to this and today I finally gave it a first shot and man…I have to say its again just half finished and a lot of stuff feels weird IMO.

Regarding the difference between 4.19 and earlier versions in regards to lumens etc…I dunno what the deal is there but it definitely feels weird and off. However, if I tweak the exposure to something that makes sense to me, the new lumen values work perfectly! I don’t know though why you would want candela as default. I never use that and usually, light manufacturers specify their bulbs and spots in lumens …sooo…¯_(ツ)_/¯

The thing that really puts me off though is that a) directional lights still don’t use lux or something that makes sense in regards to measured exposures like FStops and b) the manual camera and autoexposure work completely different still!

autoexposure now has 20 stops of range, which works perfectly with the new lumens. If you lock autoexposure at min/max EV 8 and make a 1000 lumen spot in a dark room, that looks very accurate. Now bump up max EV to 16 and tweak the sun intensity to match…same with sky brightness. Then you have something nice that follows the sunny 16 rule and still makes sense in regards to dynamic range.

Problem though, those settings don’t match at all when using manual exposure which…well…sucks.

Hopefully someone with more knowledge could shed some light on this…preferably from Epic :slight_smile:

If anyone is interested, I am going to work with the new exposure system in the next lighting academy, coming next week. So I am really looking forward to explore this more :slight_smile:

Cheer!
Daedalus

8

Looking forward to hearing (and seeing) your take on this!

9

Apparently the sun does use Lux, it just isn’t reflected in the UI yet. If you use EV+16, or the associated shutter speed and f-stop with an ISO of 100, you should be able to properly visualize the sunlight at ~195,000 intensity. I posted on this UDN post to try and get some more information. It’d be nice if we got a livestream or something to go over these specific changes.

10

(I haven’t used 4.19 yet)

I wish in the case of a game engine, Epic took the approach of “Arnold Renderer” and went with “exposure stops” Setup and a simple color temperature. This in my point of view is a far more streamlined and straight forward approach for digital approximation lighting.

I say Approximation because UE lights are still very very far from being “Physically correct” this is a just a term used for the way lighting feels consistent with materials of a certain package. So I’m not sure what benefits come from such an addition because we can’t expect to match real world lighting to a realtime one by just typing in the same values, I mean we still do tons of tweaks in Vray and Arnold for such cases and their lights are vastly superior to any real time engine. Perhaps it was a demand from Architecture firms working with static lighting? Even that can be questionable because Arch visualization rarely use real world light values of this kind it’s mostly IES stuff which the engine already has support for.

11

Could you post this on answer hub instead? People that dont have a custom license with Epic cant access the UDN :slight_smile:

12

A video on EV and lighting values would be awesome, I can’t figure out how to get something natural at daytime exposure values.

13

I thought I was the only around who didn’t know what’s going on with new exposure settings. I was wrong. :stuck_out_tongue:
@DanielW any chance you can (or maybe ping someone) who can shed some light on the new camera exposure settings in ppv? default settings give pure dark image.

Thanks.

14

Hey guys,

little update from my testings :slight_smile:

First of all, when I start thinking about my lighting, I always use the “sunny 16” rule as a baseline for my work. This has a couple advantages, mostly though, it helps me to set up a rough lighting in seconds and it provides context and relationship for real-world lumen values you get from light manufacturers. Also, since there are measured values like around 125 000 lux for full bright sunlight on a flat surface, if all these values line up nicely, you can work in a very convenient way.

Here is an example of a “sunny 16” chart:
images.jpg

The problem here is, when I use any of these values, I should clearly see a light with 1000 lumens and I don’t if I use manual exposure. So that’s what I am not understanding.

The whole story turns around though if I treat min and max brightness in the exposure section like they are 20 EV stops. It doesn’t feel accurate as well, but it seems to get the job done pretty well until I have a better idea XD

Here are some examples from I quick scene I just threw together. Skylight has intensity 1, Directional has intensity 50 and the spotlight has 800 lumens. The EXR file on the skydome uses a multiplier of 40. Exposure is locked to min 8, for cloudy daylight/interior and max 12 for something that is a bit stronger than soft sun.

This is by no means perfect, but maybe it helps someone to get usable results :wink:

Cheers!

05.PNG

01.jpg
01.jpg1375×845 91.3 KB

02.jpg
02.jpg1374×845 80.3 KB

03.jpg
03.jpg1379×848 93.4 KB

04.jpg
04.jpg1379×847 203 KB

15

Cool, will check out those settings. BTW can you get convolution bloom working? I’m having trouble with that aswell.

16

Hi,

Some more details on the new exposure settings in 4.19 :

  • The exposure value from the viewport EV100 slider is defined as Exposure​ ​=​ ​1​ ​/​ ​(1.2​ ​*​ ​2^EV100)
  • The relationship with the PPV camera setting is EV100​ ​=​ ​log2(​ ​N^2/t​ ​*​ ​100/S​ ​) where N is the aperture, 1/t is the shutter speed and S is the ISO.
  • The scene color is defined in cd/m², before the exposure is applied. It can be inspected by using the PixelInspector tool.
  • To isolate the effect of exposure on the final color, disable the “tonemapper” post process in the show flags.
  • Directional lights are in lux (lm/m²) and sky lights are cd/m² (as emissive materials).
  • When using the “manual” metering mode, the scene can go dark because the default values define an EV100 of 9.91 (where as most scene are made for an EV100 of -1.2).
  • When using auto exposure with realistic lighting values, increase “Max Brightness” to 10K and “Histogram Log Max” to something like 16. Otherwise, it will go white.
  • Prior to 4.19, the point lights units suggested to be in lumens but it was not in practice.
  • IES profiles work in the unit type of the lights.
17

@, Thanks for the explanation.

If I’m correct, with 100,000 as directional light value and these camera settings the scene should look as bright as a bright sunny day without having to touch compensate exposure. But it looks a lot darker than expected? Having to touch Exposure Compensation means having to eyeball scene/lighting again which defeats the point of having Lux or any other physical values. I’m probably missing something here.

https://i.imgur.com/XF2vVEb.jpg

18

I have yet to understand the decision of having a needlessly over complicated real world lighting measuring methods in a realtime game engine where the notion of anything related to how real light works in the world is absent in the first place, from true reflections to realtime or even accurate baked GI to bounce lights to true area lights, to shadows and self shadows you name it.

Even in offline renderers these methods of measurement are rarely used and most of it is eyeballing with approximate exposure values.

Why take this route? Just keep it simple exposure stops and temperature values (similar to Arnold) only a handful of occasions in the CG world will someone resort to measurements in Candelas and lumens Not even majority of VFX in Hollywood movies or animated films at Pixar use this!

Everyone is trying now to match realworld settings in a game engine and expecting super accurate results like a camera, well good luck.

From time and time again as much as i like this engine I am constantly disappointed at the priorities and some of the decisions taken when there are so many basic things that require immediate attention that would actually make a difference.

19

I like the direction with the physical units, but like maximum-dev I seem to be be getting unpredictable results even with a simple camera and directional light setup.

20

Hey ,

thank you so much for elaborating on those implementation details! I have one big chunk of feedback in regards to this :smiley:

First of all, clarifying the implementation approach for this clearly helps to understand it, but it doesnt make the whole system more approachable or usable at all!
Also, I dont really care if this is super accurate math wise or if this is the scientifically correct way of doing it (something you can hear quite often from Epic) because in the end, it all matters NOTHING if the usability is bad and the system makes no sense in comparison to similar and proven systems.

PLS just make the whole system EV based, for manual camera AND auto exposure! Just give us EV1 - 22 with ISO 100 and 1/125s on the manual camera and make min and max brightness respond EXACTLY the same way for auto exposure. You can set min EV. to lets say 8 and max EV to 12. That should get the job done!

Also, in relation to why realworld values are great…let me give you the following example:

I did some lighting on Theed City, Naboo for Battlefront 2. So lets look at a shot here

BF2_1.jpg
BF2_1.jpg1920×640 480 KB

So…this is a sunny setting with pretty strong lighting and a bright sky…so what do I know?

I know that I need a sunlight intensity of around 125 000 lux
I need a MAX EV value of around 16 based on the sunny 16 rule
We also measured sky luminance for different settings so I know that the sky like I want it should be around 5000 cd/m[SUP]2[/SUP]

With all this data, setting up the lighting for Naboo becomes a **** cakewalk!

First, I tweak exposure to be EV 16 and I crank up the sunlight to 125 000 lux. Then, I add an HDRI skydome and turn on the exposure viewmode that has a square in the center of the screen…inside that square, it measures luminance and shows me the value. I look at an average spot on the sky with the square and bump up the sky brightness until the number in the square reads 5000 cd per square meter.

DONE!

Now my local lights will AUTOMATICALLY ALWAYS be correct since they use lumens and all these values work in relationship. Now I can focus and the actual ART of lighting instead of getting the **** basics done. This whole thing took me less than 10mins to setup and it looks almost perfect right out of the box!

So why exactly can’t we have something like this? Can anyone give me a really good reason to NOT do this? :smiley:

Cheers! :slight_smile: