I agree. In some situations, some intersecting objects in some situations look like “flying” over the other, due to lack of ambient occlusion details.
Ah, I see. This is, incidentally, another thing lumen improves on in the current update path. They’ve improved and rolled a few disparate lighting methods into something they call ‘short-range AO’, and upped the resolution of screen traces to resolve lighting quality issues. It may help.
2 Likes
Oh, it sounds very good. Love the way you keep updating yourself and informing us! Thank you Blackwell 
1 Like
Thank you! I’m happy to do so, and I like providing a bit of a window into the tech as it’s being developed. The entire lumen team has done absolutely spectacular work, and it’s come such a far way since Land of Nanite.
And speaking of updates, I noticed this:
There was a sort of ‘leaking’ I noticed if you had anything too reflective in a heavily-fogged area. I don’t know whether or not this is simple distance-based attenuation (relatively straightforward) or some sort of volumetric simulation (wizardry imho), but I’m excited nonetheless.
Update: I looked in the .usf, it looks like a distance fog-based implementation, but that’s probably more than sufficient for indirect lighting.
2 Likes
The lumen team has been very prolific with new features lately; what I often see is refactorings or integrations into other systems, but we’ve gotten a lot of rendering features lately. Speaking of:
This will probably make it easier to integrate lumen into stylized games; lesser specular reflection intensity will also look better considering lumen’s (currently) unreliable specular denoising.
So… I’m not sure if you guys are open to feature requests but a while back I had an idea for a fake window light in order to address the issue of small windows causing noisy/splotchy lighting in interiors. Basically it’s just a rect or spot light whose color is set by sampling the skylight texture in the general direction the window is facing. Since it samples the skylight texture, the lighting color is dynamic. Lights Intensity is scaled by an artist control.
Anyway here’s a sample of the results:
Video of it adjusting in realtime (after I press simulate it begins to use the fake window light):
Another example in a real scene:
As you can see there are some noticeable benefits to this:
- Significantly improved soft shadow detail provided by VSM/MDF shadowing
- Improved hit lighting reflections by providing more hit lighting
- Reduced splotchiness and noise, especially on high scalability.
- Dynamically updates, provides plausible lighting even in sunset conditions
A spotlight could be chosen instead of a rect light depending on the desired performance characteristics, and it otherwise has access to all the same controls as a regular light.
As noted I am using the skylight texture, I wonder if this could be improved by getting the color from Lumens translucent lighting volume from a point a bit behind the light? This would allow the light to take into account things like skylight shadowing and exterior bounce light which my implementation doesn’t do. Might even be useful for stationary lightmaps as an alternative to lightmass portals (which incur huge build time costs).
I think this would provide a higher cost, but higher quality alternative to skylight leaking or albedo boosting, since both of those create a mismatch between the screen and the surface cache which is an issue this method doesn’t suffer from.
Anyway… I’m not a tech artist, the way I had to implement this is awful (I can elaborate on it if needed) so I think people who knew what the hell they’re actually doing could be much better. I don’t know how feasible (or desirable) any of this really is to implement but I think it could be useful and I hope you’ll consider adding it
Huge thanks to whoever was responsible for exposing the SkyLight texture to the material editor… honestly something I’ve wanted for a long time.
2 Likes
I absolutely love this! Skylight noise resolution has been an issue, as well as shadowed skylighting being one of the slowest parts of the pipeline to updaet.
1 Like
Just something like Sky Portals!
Buy about your research, it may be less noisy just because it’s quite brighter, right?
Basically yes. It’s not physically correct (but neither is skylight leaking or albedo boosting)
As far as I know the noise stems from not enough rays actually hitting the window, resulting in interiors with unstable lighting that are often darker than they should be so I wouldn’t say Lumens output is necessarily correct in these cases either. Adding direct lighting resolves the issue, but as you say it is adding additional light to the scene.
1 Like
You mean something like the Lightmass Portals ? Lightmass Portals | Unreal Engine 4.27 Documentation
Hi Max,
No. I was talking about ‘something like’. Lightmass portals are for static lighting, if I’m not wrong. Other softwares use Sky portals to potentiate the entering skylight.
Anyway, something like lightmass/sky portals, but for realtime Lumen.
Hi @jblackwell !
Maybe they are preparing the GDC 2023 to show the new Unreal features.
BUT, @jsfilmz has pointed in his videos that some of those lovely features are being added to the v5.3 branch. What do you think about this, as an experienced ‘github watcher’? Does it have any sense, skipping 5.2 even before being released?
Well… quite dissapointed with 5.2-5.3 “improvements”, for the moment:
“Same” quality, less performant, and more noisy.
Slider comparison: Lumen 5.1.1 VS 5.3.0 Beta - Imgsli
“Worse” (?) quality, less performant, much more noisy, and what about those white halos around objects?!
Slider comparison: Lumen 5.1.1 VS 5.3.0 Beta - Imgsli
And still… those quite limited reflections:
I’m starting to think that reflections and translucency will remain grotesque looking until pathtracing becomes standard realtime rendering.
1 Like
Not even 5.2 is stable, let alone 5.3. It’s WIP, so it’s obvious things are often broken. 5.3 is going to release in half a year at soonest.
I remember what a dumpster fire nanite foliage was when I built 5.1 from source before it was released. Not only that, it was actually quite close to final release. Yet, when the final 5.1 came, the nanite foliage worked pretty d.a.m.n well all things considered.
I mean just half a year prior to that, most of us thought nanite with non-opaque meshes was a problem that will take years to figure out, yet it took Epic just a single release.
There can be so many things at play. The developer working on lumen can have some default variables changed to debug, so for example lumen may not be doing any ray intensity clamping in that build because the developer was in the middle of making some comparisons to the path tracer and wanted to remove the bias.
Building the latest engine from source from time to time is fine, to see what’s being cooked. But drawing any conclusions about how the features are going to work and perform in the final release based on build that is a month away from release, let alone half a year from release, is just crazy and pointless.
Hi @Rawalanche !
Of course, you are right and I’m concious of it, but even being under development, it’s supposed to include lastests changes and improvements. Of course it can break some things, no doubt.
Anyway, I could be quite sure that some of the pointed problems would be still there in the final release. I was just looking if things are getting better in future versions (as it’s quite buggy right now), and trying to give it more visibility. Maybe the Lumen team could be interested in getting feedback.
For example, I already warned about some of those weird things, like that white halo arround objects, already present in 5.1. And now it’s even worse! And I bet you that they didn’t realised. I just want to contribute with my grain of salt.
I wouldn’t worry about it honestly. Epic doesn’t guarantee ue5-main will even compile, much less that any of the features will work as desired if at all. This is the note on the branch on the github page:
I built ue5-main a week ago and Nanite landscapes with PDO were completely broken.
vid
Pretty sure it’s not going to actually ship in this state so again… I really wouldn’t worry about it. ue5-main will have regressions, it will have broken stuff, and new features will be unfinished. It’s just a given.
Edit: Not trying to stop you from giving feedback, just maybe don’t panic.
Thank you Arkiras for sharing your opinion
Don’t worry. I know you are not trying to stop me.
Anyway, I’m quite sure that’s the current ‘releasable’ state of Lumen right now. Not a known problem or a regression. Tested in 5.2 and it’s the same too. (I’m specially talking about those white halos around objects, which I think it’s the most missunderstanable ‘novelty’)
Hi Arkiras, that is a great idea, I tried to figure out how to expose that skylight sampling to rect or spotlight, as I am still beginner in UE my first thought was to find a way how to connect sky light env map sample with the lights source texture. Still cannot find the way on my own - could you help - how was your example setup in detail please?
emissive meshes/materials have a rather short path length (roughly 16 meters?). how would i get more out of it? without going overboard overall. i see the emission ray hits getting rather random at a distance. also… i would like to bake those sorta static light emissions in a controlled manner, but it’s not allowed. i tried all settings. lightmass is enforced “off” in the world settings.
