4.19 Physical Lights

[Juanmilanese]

Any news on this topic?
Is somebody activelly using 4.19 in a scene with both interior and exterior lights?
@Daedalus51 vid on the topic was an eye opener in a lot of senses but even he couldn't get around the interior lights (point and spot lights) problem.

Even then, I had to wrap my head around a lot of very complex topics, and I know I'm a noob on the subject of physical lights, but i'm not the n00best of n00bs, and I found some concepts... complicated to say the very least (like, aproximating the total brightness of the HDRI image based on pixel values that range from dunno, 3k to 20k)

Any word from Epic on some kind of examples, standards, documentation, something?

Maybe with 4.20 blaze it release around the corner we can expect some kind of feedback on this topic?

[rabellogp]

I'm currently working on a interior+exterior archviz project in UE 4.19... I have to eyeball everything and completely ignore the meaning of the values and units that I'm using in my artificial and natural lights.

Light eyeballing has been a huge bottleneck in my archviz workflow. I can't stress enough the importance of proper physical light system in the engine. I would venture to say that this matter is equally (or even more) important for archviz in UE4 than the Unreal Studio stuff.

[Juanmilanese]

I'm currently working on a interior+exterior archviz project in UE 4.19... I have to eyeball everything and completely ignore the meaning of the values and units that I'm using in my artificial and natural lights.

Light eyeballing has been a huge bottleneck in my archviz workflow. I can't stress enough the importance of proper physical light system in the engine. I would venture to say that this matter is equally (or even more) important for archviz in UE4 than the Unreal Studio stuff.

Yeah, I'm also working in Archviz projects but I think this problem not only affects the Archviz community.
Is like Daedalus says in his video, UE4 offers a light system (vital for any visualization purpose, cause... you want to see things in a screen after all, and if you want to see things on a screen you will have to simulate lighting at some point or another) and one part of that system is broken or so badly documented that is unintelligible.
Then, everything falls apart, your super careful crafted and delighted photogrammetry assets, your super complex multilayered materials... what do they represent? what are they reflecting or reacting to?

I'm gonna be a PBR "purist" here, the system needs a previsible camera, a previsible Lightning and a previsible Material simulation to be called, well, a system, at all.
And what bothers me is that Epic was taking the right steps towards that unified simulated system (EVEN if was a simulation at the end of the day, EVEN if wasn't 100% accurate, EVEN if it was an approximation)
But on the verge of settling the issue, they just... gave up? and left us with a (apparently) broken or unfinished one.
And I don't want to get over the Fortnite conspiracy theories wagon but... fortnite doesn't uses realistic lighting and it prints money so maybe is that, they just gave up.

I found very strange that they let pass a whole numbered update without doing any change or documenting this absolutely CORE (for the engine) issue.
Even "obscure" topics like Distance Fields are better documented than this.
Man, I kinda-maybe-almost understood what a Signed Distance Function is by reading unreal's help files and a couple of pages on the topic! And I really really SUCK at math and everything related!

Putting a lamp in your level should be FAR easier and predictable than that. Putting a Sun, a Camera with an aperture that simulates real cameras, an aperture bracket for the auto exposure, a skylight, setting an HDRI should be... working out of the box stuff! at least, "go to the help files, read and learn you n00b" stuff!... not a dig-in-the-forums-and-talk-with-a-guy-who-worked-for-the-star-wars-franchise stuff! that's my point.

Is light man, is like... the base for everything you do inside the engine... is not 100% Physically accurate? no problem, but give us the numbers! I want to know what numbers I'm punching in. A random Multiply between, dunno, 0 and 1000? OK... but then why... call it Candelas and Lumens and Lux stuff??? at least I know that a random 950 is 950 times stronger than 1 in a arbitrary scale.

Anyways... I get a little angry with this issue as you can see... I don't understand the topic so deeply as people who writes here and not knowing where else to look for makes me very upset... I love the engine, and I really wish I could use it, I'm stuck with 4.18. And 4.19-20 look amazing (The GPU acelerated bootleg thing for baking light specially)

gonna try the 4.20 preview today and test some stuff. Maybe they fixed something? Somebody said the exposure thing is even worse now, they removed options or somehting... dang man!

[Daedalus51]

Hey guys,
I have pinged some of our teams on this. We're in the thick of getting stuff ready for 4.20 so give us some time to put together a response. I know you've been waiting patiently and I promise I'll stay on top of it, but I ask for a bit more time.

:-)

Thanks!

Hey man,

any updates on this just yet? And apologies for pushing again....WE care!

Cheers,
Dadedalus

[Maximum-Dev]

{Constructive feedback

I'm not sure if rendering engineers will happen to read this thread sometime in the future but in case they do, as you might be aware of, physially based lighting isn't about Sun only, but it's also about ambient light. With directional light being physically based, best we can do is to make surfaces that are under direct light look more close to reality. But there are parts of the game world where environments are covered in shadows. You can't make skylight physically based because all it does is capturing the sky and projecting it everywhere, that includes anywhere it shouldn't be projecting the sky light as well. i.e interiors, forest grounds, caves etc. which makes it impossible to achieve true physically based lighting, as you're aware. You don't want to work on a dynamic G.I solution and we've accepted that as an unchangeable fact. But Image Based Lighting is the perfect solution between flat skylight and dynamic G.I. It allows every different environment and even every interior to have their own unique ambient lighting. The type of ambient lighting that actually corresponds to the environment around it. Please consider letting the artists make better looking environments in UE4 by bringing IBL to the table. It's a rather small feature compared to majority of features you're releasing with every engine update.

End constructive feedback}

[Daedalus51]

{Constructive feedback

I'm not sure if rendering engineers will happen to read this thread sometime in the future but in case they do, as you might be aware of, physially based lighting isn't about Sun only, but it's also about ambient light. With directional light being physically based, best we can do is to make surfaces that are under direct light look more close to reality. But there are parts of the game world where environments are covered in shadows. You can't make skylight physically based because all it does is capturing the sky and projecting it everywhere, that includes anywhere it shouldn't be projecting the sky light as well. i.e interiors, forest grounds, caves etc. which makes it impossible to achieve true physically based lighting, as you're aware. You don't want to work on a dynamic G.I solution and we've accepted that as an unchangeable fact. But Image Based Lighting is the perfect solution between flat skylight and dynamic G.I. It allows every different environment and even every interior to have their own unique ambient lighting. The type of ambient lighting that actually corresponds to the environment around it. Please consider letting the artists make better looking environments in UE4 by bringing IBL to the table. It's a rather small feature compared to majority of features you're releasing with every engine update.

End constructive feedback}

Man, I dont want to drag you down, but IBL support for local captures has been explicitly removed from the engine. It was there before and it was called "DiffuseFromCapture".

It is fairly easy to hack it back in though if you know a tiny little bit about coding and copy pasting

Sorry buddy!

[Chosker]

Man, I dont want to drag you down, but IBL support for local captures has been explicitly removed from the engine. It was there before and it was called "DiffuseFromCapture".

It is fairly easy to hack it back in though if you know a tiny little bit about coding and copy pasting

Sorry buddy!

gonna quote myself from the Svogi thread. I posted this but it quickly got lost in the discussion

btw I had a shot at the IBL thing I mentioned with reflection captures.
I was able to make reflection captures show up as lighting but the results are worse than I expected. captures can "see" to infinity which means any bright spots will leak inside windows/doors/etc indefinitely, no matter how far they are (I'd probably need a 'maximum render view distance' for captures, but then it wouldn't work for reflections anymore. alternatively if captures had depth I'd be able to filter out far objects by distance, but I doubt probes have depth information).
aside from that there's a big issue that capturing probes will accumulate over themselves each time you capture them, since they are already affecting the scene as lighting. as such, I have to turn them off every time I want to recapture and then turn them on again.

these issues severely affect its feasability, and the more engine changes I have to make, the less chance that it would ever get accepted as a pull request (chances are already slim, since they removed the DiffuseFromCaptures feature in the first place)
in any case I'm focused on other things at the moment so I can't work on this currently. but if there's interest I can at least post some screenshots of my progress

talking from experience, it's possible but it's far from being "fairly easy to hack it back in". at this point it really means redoing the feature because the rendering and shaders changed so much since the feature was removed.

[Daedalus51]

gonna quote myself from the Svogi thread. I posted this but it quickly got lost in the discussion





talking from experience, it's possible but it's far from being "fairly easy to hack it back in". at this point it really means redoing the feature because the rendering and shaders changed so much since the feature was removed.

Thanks for following up on this man! I wasn't aware of such drastic changes so I assumed it was more straightforward...so thanks for clearing that up. I know that the ARK guys are still using this technique, but I am not sure if they are running on the latest engine version and how exactly they implemented it.

Out of curiosity, since this is Cryengines main GI workflow, how do they make sure they dont capture lighting in an additive way all the time and filter out too bright spots in the distance?

Cheers!
Daedalus

[Chosker]

sure, anything for the cause!

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

[Maximum-Dev]

Man, I dont want to drag you down, but IBL support for local captures has been explicitly removed from the engine. It was there before and it was called "DiffuseFromCapture".

It is fairly easy to hack it back in though if you know a tiny little bit about coding and copy pasting

Sorry buddy!

I'm going to assume the person who removed it did it by mistake.

[Maximum-Dev]

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.

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.

[Manoel.Neto]

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

[Chosker]

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.

Reflection 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

[Maximum-Dev]

I don't mean to derail the thread into a full IBL discussion though [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/LEFT]

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.

[Chosker]

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) :P