Download

4.19 Physical Lights

that’s exactly what we’re asking for all along whenever we mention localized IBL. we have a hard time accepting that unless you use lightmass you’re stuck with flat ambient lighting and the only solution to mitigate it is DFAO. so localized IBL is exactly what I’m experimenting with by modifying engine source and shaders :slight_smile:
it’s also what I thought DiffuseFromCaptures could be doing, but now that I see how it felt so short at it I’m not surprised it was removed.
as I described before I’ve already managed to inject the reflection captures back as lighting, I’m just not getting the proper local/directionality (since reflections behave different than ambient lighting) and I don’t know if I can get away with using the same reflection for both (if I cant, then my experiment isn’t feasable)

I really don’t see the localized part in the current implementation. DFAO partially shadows it… and that’s it. blocking the light is really far from calling it localized.
DFAO does a nice job as a close-mid range AO but it can only do so much so it can’t be called proper ambient lighting

yeah that was my point earlier. this thread is about Physical Light Units rather than actual Physical Light behavior

I’ll probably make a new thread if/when I get further with my experiments :slight_smile:

I am sorry to bring back this topic, but in documentation I found this.

https://docs.unrealengine.com/en-us/Engine/Rendering/LightingAndShadows/AmbientCubemap

It says Ambient Cubemaps. But I searched the engine and didn’t found the button which it says “Lighting Image Based Lighting”. And documentation doesn’t explain where it is. So as a noob, may be I missunderstood something, but from what I understand, it is same IBL function which you talked about. Or is this the feature, which Epic already removed? Then why is it still in documention page?

It’s in the Post-Process Volume. It’s not deprecated, but it’s pretty much outdated and unsupported, but people can still use it if they want, thus the documentation. Last time I used it, one or two versions ago, it broke the Subsurface Profile shading model and they all turned white, as if it was much stronger on the skin than everything else.

The ambient cubemap is a feature that predates the skylight! Before Unreal had a skylight, the ambient cubemap was the only way to globally applay image based lighting. Its just a post process IBL pass that is fully unshadowed. Thats why it illuminates all surfaces equally and doesnt account for local occlusion.

Basically, thats the old Marmoset for you^^

The movable skylight should look exactly the same if you dont use DFAO and the stationary and static will look different after baking, since they are then fully shadowed.

So basically…this is just a legacy feature from before Unreal had the skylight with cubemap support :slight_smile: Dont use it unless you want to brighten EVERYTHING :smiley:

Cheers!

FUNNY FACT: I actually worked with an Unreal 4 version soooo early back at my old company, it was not yet publicly released and the only way of getting any ambient lighting without using lightmass was the ambient cubemap! God those were horrible times, I dont know why people complain these days :stuck_out_tongue:

that was over 4 years ago, and SVOGI was supposed to be part of it :wink:

nowadays we complain because a non-baked skylight will still affect all areas uniformly (except for whatever shadowing you can get off DFAO), ruling out proper indoor-outdoor transitions

I’ve now made my own thread about my Local-IBL experiment: https://forums.unrealengine.com/development-discussion/rendering/1493669-localized-ibl-proof-of-concept

Hahaha…well it was shortly after SVOGI was removed. I joined the company 1 month too late to still get a shot at Unreal 4 with SVOGI :smiley: They actually did the first visual benchmark for DI2 with SVOGI! That was pretty dope :smiley:

Ah thanks man, gonna follow over there as well^^

Daedalus

Bumping for visibility as physical lighting is still broken.

Bumpity Bumper Bumpity Doo

What is the issue that you guys are still having? There’s a lot of talk here that isn’t directly correlated to “4.19 physical lights” and I don’t want to go through 8 pages again.

I recently did a relighting scene with physical units(cd/m² for emissives/sky and Lumens for lights) and it felt pretty good. Like my first tests with the system, I avoided auto-exposure, so I can’t speak on that. Although, a quick test with the Basic Auto Exposure with the Constant Calibration(amazing feature btw, simplifies exposure tweaking drastically) proved to be just as useful with all physical values than it was without them. I usually have Pre-Exposure enabled as well. Otherwise EV100 has been working pretty well.

The last couple of pages are kinda off-topic, but the issues presented in the first two pages of this topic (well exposed on Daedalus52 posts) still persist.

Bumping this for visibility as the issues are still not resolved.

Bump. We need Documentation on the new Physical lighting system on 4.20, if its even working as intended.

Meant to ask, are you going to do a breakdown of that scene or kinda show some insight to how your handling it? I been wondering about the constant calibration and Ev100.

Found This in 80lv today

maybe offers some insight on the topic, haven’t read it myself, gonna look at it tomorrow, but seems to be on the topic.

Looks similar to Daedalus methos tho.

Agreed. Very similar to what he would do.

Constant Calibration just forces the auto-exposure to always adjust for a particular gray, like most auto-exposure in cameras do for 12%, 16% or 18% gray. It’ll work for physical values as well, you just need to increase the Max value(~10,000) to allow for the high dynamic range physical values will require. EV is just a simplified way of measuring exposure that is always the same regardless of camera settings because it includes the necessary ISO, shutter speed, and f-stop settings. EV 10 would be identical at any ISO provided you also used the appropriate shutter speed and f-stop on the chart. The best part about it for our lighting is that just like physical units of measurements, EV is a known “measurement” and there are numerous charts out there to explain what value works best in any given lighting condition. Therefore making it a consistent way of getting close to perfect exposure for a given view. The 100 in the name is just part of the common convention of 100 ISO.

Similar because that’s what physical units brings to the workflow: consistency.

That’s my write-up btw. :slight_smile:

I consider the new lighting management very interesting. Of course the use of the new features is not so immediate and probably the choice was determined by the new road taken.

Epic Games is an American software house and perhaps did not take into consideration the conversion of the international system of measurement units using, instead, the American one.

In the United States, an old lighting unit that is not part of the SI system (= International System of Units: https://en.wikipedia.org/wiki/Intern…ystem_of_Units) is still used: the footcandle (literally “foot-candle”). It has:

1 footcandle = 10.764 lux,
1 lux = 0.0929 footcandle.

Now I share two links to the two units of measurement:
Candle= Candela - Wikipedia
Lumen= Lumen (unit) - Wikipedia

I also found some difficulties with the new system, and to better understand the new features I read this information about the unit system and it was at least very useful for me.

I hope my post can be useful.
Thank you

Update

Luminous intensity :candela:[cd=lm/sr]
Luminous power :lumen: [lm=cd*sr]
Illuminance: [lux=lm/m²]
Luminance: [L=cd/m²]

the light of the Sun on average varies between 32 000 lx (32 klx) and 100 000 lx (100 klx);
in the spotlight of the television studios there are about 1 000 lx (1 klx);
in a luminous office there are about 400 lx;
in an illuminated office according to the current European Uni En 12464 there are 500 lx
the reflected light of the full moon is about 1 lx;
the light of a bright star is only 0.00005 lx (50 μlx).

A very good information of Exposure Triangle: Aperture, ISO and Shutter Speed on this article: https://www.cambridgeincolour.com/tu…a-exposure.htm
More information on Exposure Value: Exposure value - Wikipedia

Hello,

Now that 4.20 is out can we expect a reply on this thread?

This video sums up the issues detailing why and how the physical lighting is broken: https://forums.unrealengine.com/community/community-content-tools-and-tutorials/106867-unreal-4-lighting-academy-or-something-like-that?p=1475346#post1475346

Just got 4.20 and gave it a spin.

Going with sunny 16, you’ll want something like 900,000 Lumens for simple room point light.
There are two new options added to PPV, “Maximum Aperture” and “Number of Diaphram Blades” which you can’t use because they’re both grayed out.

It’s very strange I have to say, that Epic adds two new options to physical lighting system as if the system is usable and they’re upgrading it.