Download

4.19 Physical Lights

Development Discussion Rendering
#89

sure, anything for the cause! :smiley:

I don’t know what version ARK is using. the further away they are from where DiffuseFromCaptures was removed, the more work they would’ve needed to put in to maintain/adapt it. I suspect it’s also somewhat easier to maintain the feature If you go version after version than trying to re-implement it 10 major engine versions later.

I also don’t know how CryEngine does it as I haven’t even used it (I want to learn a bit of it eventually) so I can only speculate. however I’d suspect they’d also need to turn off IBL itself during the capturing of IBL otherwise I believe it would stack up as well.
in terms of UE4 it wouldn’t really be much of an issue. just add some code that before the capture happens, iterates through all capture actors and turn them off, then turn them back on after the capture is done. or maybe with a shader define that’s aware if the rendering is happening from a reflection capture source to it simply skip it there.
I’m actually curious how this used to behave in UE4 when the DiffuseFromCaptures feature was functional

at this point I’m still busy with other stuff though so I won’t get back to this research/prototype for some weeks still

#90

I’m going to assume the person who removed it did it by mistake. :rolleyes:

#91

I actually remember them saying each probe has to capture the environment twice by the artists. First time the environment is captured (diffuse only since at this point ambient is black there is no specular/reflections seen from shadow covered assets) and second time it captures it takes specular highlights and reflections into account as well and reproject a more accurate image to the environment.

#92

Reflection captures are part of the static lighting pipeline. Using them for “ambient” lighting makes no sense when the volumetric lightmap exists (which stores static “ambient” lighting).

#93

you’re missing the context of a scenario where baked static lighting isn’t used

for big levels the long iteration times and the huge memory footprint of lightmaps makes static lighting hardly an option. falling back to stationary or dynamic lighting then means relying on a skylight that will affect all areas the same, resulting in an unwanted homogenous lighting everywhere. this is especially problematic in games with indoor-outdoor transitions where going inside a house or a cave and having the outdoors skylight really doesn’t cut it. R[COLOR=#252C2F][SIZE=13px]eflection captures share the same principle: they are used because using the Skylight cubemap as a homogenous reflection really wouldn’t cut it.

the engine’s solution to avoid homogenous lighting is DFAO but it’s not really effective. it essentially means blocking the skylight so it’s not a replacement for ambient lighting. DFAO will still let come skylight through, and even if you manage to make it block all the skylight, then you’re rid of any sort of ambient lighting. also DFAO has a maximum effective range, and any game probably would need to have it toggleable if you want it to run on low-end hardware.

btw local IBL is a tried and tested technique (read up about it here). just because UE4 does things one way it doesn’t mean it’s the only way. specially when you really can’t use UE4’s way.

I don’t mean to derail the thread into a full IBL discussion though :)[/SIZE][/COLOR]

#94

It’s completely valid though. Epic said “Physically Based Lighting”, which makes it apply to ambient lighting as well. Despite IBL not being quite physically based, Epic’s current ambient lighting solution breaks the “Physically Based Lighting” term into pieces as a whole.

#95

honestly I don’t think they mean “physically based lighting” in terms of “fully realistic and physically accurate lighting”, but rather as “lighting that looks better than the good old phong”. after all the world of real time rendering is all about approximation

same way as they can’t possibly mean it when their Features page lists “Photoreal rendering in real time”. it’s just buzzwords to say “our graphics are better than Unity” (for now) :stuck_out_tongue:

#96

Of course. But that’s also what IBL is. Giving an approximately correct ambient light for each different environment. With skylight being the only ambient lighting solution Epic can’t claim their lighting looks better than it did in other 10 years old games.

Hmmm…
Im my own personal brain (the chuck where still belongs to myself) I know this as a fact that between UE4’s SSAO, DFAO, Skylight, broken physical lights, and Unity’s recent advances in real time rendering (if you have seen their presentations and Book of the Dead), I think the “Photoreal rendering in real time” arrow clearly spins towards Unity atm.

#97

That’s the Remember Me technique, which is the basis for the UE4 reflection captures. It’s only useful for lighting objects inside somewhat rectangular shaped areas. I fail to see how it would be of any use in levels that are truly large and open, specially when it was introduced in a game that is basically a string of static lit small corridors.

#98

For outdoors you have one probe that covers the entire world and then you place local probes within the global probe. i.e this part of the forest is very dense, you put a probe here so ambient becomes darker. Other part of the forest is more sparse, you want lighter ambient light. Cave over there, you want much darker ambient light.

Crysis 2
Crysis 3
Ryse
Homefront: Revolution
Kingdom Come: Deliverance
Warface
Star Citizen
Sniper: Ghost Warrior 2
Sniper: Ghost Warrior 3

Are some examples of outdoor games in one engine only that use IBL probes for handling both exterior and interior ambient lighting.

#99

please try to look at the big picture, I only posted the link to the technique for explanation and not as the target use case. try to think of the use cases we’re mentioning - the idea of “localized ambient lighting” and “we can’t use baked lightmaps” should really give you enough to understand :wink:

in some cases even, the ultimate goal would be to be able to update the reflection captures at runtime (in a deferred process aka. just one at a time, updating those around the camera more frequently than the rest, etc) and be able to have dynamic IBL in scenarios where lighting changes only ever slowly (games with time of day). however reflection captures are 100% static in cooked, so that’s really more of a very long shot wish

btw I gave UE4 4.11 a roll (last UE4 version with r.DiffuseFromCaptures) and I found out that DiffuseFromCaptures never really worked as a diffuse lighting term
here’s some shots: Imgur: The magic of the Internet
all it did was add some extra color information into the reflection, but for a completely matte object it was doing absolutely nothing.
of course without applying the reflection capture as actual diffuse lighting, they never even had to deal with the issue of IBL stacking over itself when re-capturing the reflections :smiley:

#100

Just to be clear here…

There are 2 different things you can do with capture probes. You can capture indirect specular, or you can capture indirect diffuse (and some approaches combine the two)

When you use Lightmass…like Remember Me did, you want to use the captures for specular only as you have all indirect lighting baked. That’s what Remember Me did and since UE3 didn’t have reflection captures, they “invented” them for UE3 and the render guy from Dontnod helped Epic with their own PBR system for UE4 later on if I am not mistaken (Seb Lagarde).

When you use dynamic lighting only, you want to use the captures for both, indirect specular and indirect diffuse via IBL.

That function is absolutely not supported in Unreal, hence you can NEVER get any localized information with dynamic lighting (if you don’t use LPV). The only thing you can get is a localized, partly shadowed skylight via DFAO. Which is one of the reasons I think DFAO is a super specific and limited feature.

All in all though, let’s stop discussing this here please, as we don’t want to clutter the thread with nonrelevant information. Its already hard for Epic to reply here, so let’s not make it any more difficult for them :slight_smile:

I do appreciate all the good insights here though!

Cheers!

#101

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:

#102

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?

#103

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.

#104

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:

#105

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

#106

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

#107

Bumping for visibility as physical lighting is still broken.

#108

Bumpity Bumper Bumpity Doo