hardware raytracing uses geometry to trace the surface hit and lighting. software lumen uses distance fields which “naturally”/programmatically have a volumetric thickness. hence why there less potential for leaks thru the geometry. not sure how that influences the radiance cache sampling. i’ll have to do some testing of that aswell. : )
I would stress that, again, this is ONLY an issue when using physically based intensity for the directional light. At 10 lux, there’s virtually no light leak with hardware raytracing.
(The light on the right side is bounce lighting coming from upstairs, only the portion around the bend is leaked lighting)
So I still want to know how Epic is dealing with this…
okay. that’s a you problem then.
i don’t use physical values for lights, and this, i would call this, extreme auto exposure dependency. it’s bad. don’t like it. i eyeball lighting at 0 or 1 exposure level. more stable and predictable results around the small 8-bit range. old shool. you should maybe consider that. : )
No.
then fiddle around with random exposure and maybe never get it done. shruge…
You’ve continuously misunderstood my intentions. I do not need help lighting my scenes, I can already get great results with Lumen working the way that I do.
What I am asking is why Epic is changing the defaults to suit physically based sunlight intensity, when all of my own tests working this way are abysmal. I can only assume that Epic does not encounter these issues, which is why I asked. My screenshots are only intended to provide context for that purpose, so that it is understood the types of issues I encounter when attempting to work this way.
Being told that the solution is to just not do that, is an answer to a question I never asked and have no interest in. I specifically want to know how the artists at Epic deals with working with high intensity lights. That is all.
Every sample scene I have from Epic is an open environment without man-made interior structures where light leaking could be an issue, and they are all filled with high frequency detail that obscures any patchiness in the indirect lighting.
If my experience is normal and those are the keys to getting good results when working with such high intensity directional lights then that’s fine. I just want to know so that I can properly evaluate its costs/benefits on my own.
2 Likes
who said they support physical sun light values? they kinda obviously don’t. you fail to eyeball that. if you use physical values you have overexposed exteriors and rely on the auto exposure to get it to a normal viewable level. this method is unpredictable lighting trash. i’d call this exposure ping pong. it is kinda slow and the results are usually whacky. get my intention?
I certainly also think they switched to physical light values and EV100 by default, so this situation should be more “normalized” and tested.
@Arkiras I never saw this before. Maybe you could share you very basic scene to replicate the issue? (I just like to do it, as is always good to know the workflow to prevent future surprises).
PS: I think it just might be an exposure and/or exterior-interior lighting balance.
For archviz, physical light values are a big plus. That way you can just use the scientific values and data from light fixture manufacturers.
2 Likes
Go back to the original post I quoted that started this entire conversation
I understand what you’re describing but it is not relevant to me, I have no difficulty working with auto-exposure while also avoiding jarring pingponging. This was a much more difficult issue to solve in UE4 where we only had global exposure to work with, but UE5 has local exposure and more recent versions allow it to be set dynamically via curves which solves the overwhelming majority of issues.
I will try to put something together
i don’t think it works or is accurate like that with Arkiras’ setup. in my test map i leveled a static EV13 value to get a nice looking 120.000 lux sun light. at this EV i need 5.000.000 lumen to produce an approximately 60 watt incandescent looking shine, which it should do at 800 lumen, if it were accurate. i get that value at EV1. which does a 10 lux sun.
anyway… enough of that exposure talk. : )
I must be missing something but why not use a post process volume and set the exposure values like min 5 (interior) and max 14 (exterior)?
Hi, I wonder why this code line is commented out? It causes some light leaking because a neighbor probe can come from another mesh card. Is this code line causes performance issue or visual artifacts?
interesting. it makes a lil difference. looks like less leaking on angled surfaces. i dunno what is leaks and sky gi in this scene, rn. not sure if it could fix @Arkiras’ setup. they should check that out. hmm.
120k sun still kinda looks disgusting, btw. skylight is breaking. the sky is breaking. the shadows are pitch black unless you tweak all the other light values. and mess with contrast or post processing. i got some lumen traces 300 meters away that are throwing dots on the walls. fiddle bits rendering. not my style. why would anybody do that?!?
anyway…