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.
3 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 causing 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…
This is confusing.
It is said - you should always use hardware raytracing if you want increased quality - and yet it looks worse or broken in some examples above.
Also many say for increased realism you should use real life values, even someone from Epic is saying real values are good now, and yet - in the examples above we can see issues.
I mean you could just use the skyatmosphere system since it sets the skylight intensity automatically. I have not touched the skylight intensity since SkyAtmosphere was added to the engine, don’t even need to use physically based directional light intensity, works just as well at 10 lux.
well… there are some apparent issues with all of this. unless i’m doing something wrong…
athmosphere doesn’t reflect in water nor metals nor glass. you need a skylight to get that and match some form of color…
and… even on realtime capture you get no sun reflection. and it’s not color accurate. it’s a plain white mirror. fog is not captured, which is hard ofc.
same for the skysphere.
this is with static capture (or rather random test cubemap i lined up by hand), cause it cannot capture realtime without athmosphere. it does the “is sky” material tho.
so… yeh… i’ve been thorough and tested this months ago. still no change. hmm.
epic also corrected some occlusion errors on the way. iirc the building on the left did not occlude the directional light in the water reflection at some point/version in the past. that’s a nice improvement tho.
still… even under “perfect” conditions without fog or anything, i need off nominal values to get it to line up colors in mirrors and it produces a fresnel kinda thing, that is not in my material.
Works perfectly for me, always has for the nearly 7 or w/e years I’ve been using it. It’s also the basis for UDS so I figure someone would have noticed it by now if there were problems. Honestly one of Unreals best features.
1 Like
yeh. i’ve been using it ever since aswell. it is a kinda ambient light term even in mobile or forward rendering. or the hdri to use. hence why it’s in the usd spec. or nvm… uds? ultra dynamic sky?
in ue5’s raytracing pipeline it has multiple functions now, tho. it’s used as a light source, but also a requirement for sky sphere reflections to work, now. iirc it used to do those reflections without one before. allowed a semi stylized lighting path with different ambience than the sky. don’t quote me on that. it’s been a while i built my test maps. and they progressed.
so… just going thru my test levels, it is now all synced light.
still has this fresnel and value issue i added in the edit. that should be fixed at some point. i can make the mirror blend into the background at 2.0cd/m² (non-default), but the fresnel on shallow angles remains.
fog approximation in reflections would be nice at some point aswell. that’s for the grand scheme of exterior rendering.
There are two different things here: absolute values and ratios.
Artists like to light their levels using realistic PBR values - e.g. your sun intensity is 16EV and exposure is set to 16EV. This should work exactly the same as setting sun to 1EV and exposure to 1EV, as at the end of the frame you divide your lighting by exposure.
The issue here is that some lighting values can’t be exposure-relative, as they are cached (surface cache or world space radiance cache) and exposure changes each frame. In that case if you just store those values without exposure then they may get clamped, as float16 range covers only [-16EV;16EV]. We use mentioned offset to prevent those values from clamping by shifting usable range from [-16EV;16EV] to [-8EV;24EV], which should cover realistic lighting value range.
Now what makes visual difference are ratios between lighting. If your indoor lights are 1EV and you expose for 1EV and then ramp up invisible outdoor sun from 1 EV to 16 EV that will cause sun leaking to be more visible. This is indeed an issue. Some of this can be fixed by scene geometry adjustments or by various workarounds like: making sun dimmer when you’re indoors, disabling affect indirect lighting on sun when you’re indoors (screen traces won’t ever leak through walls), faking sun / sky using analytical lights etc.
5 Likes