I think that column would be perfectly visible from that mirror angle. But the reflected space between columns is the one outside the camera, at left. That’s all and that was the @Arkiras ‘mistake’.
Anyway, he was not pointing a geometry reflection issue, but a lightmass one. And if geo was wrongly reflected, that would worth the report too. So why not to use any conflictive scene, even if it can show even more buggy sides?
Try set “Specular Scale” to 0 in light parameters.
So, it’s leaking from the sky above the ceiling into the room itself due to low probe density? Do you have a lightmass importance volume in place, or is that stock behavior? This is just pure curiosity.
There’s a lightmass importance volume yes, and yes this is just how it behaves. Probes are linearly interpolated and don’t store any sort of occlusion information, so they will interpolate lighting outside of the wall if the wall is between probes.
Unreal’s default probe spacing is 2 meters, so you can imagine… walls are pretty much always going to be between probes.
Dealing with this is normally the biggest headache of using baked lighting, but in very close second to that is managing reflection captures which is why it would be so cool if lumen reflections + baked lighting worked with software raytracing 
Or just bring back ray tracing.
@Arkiras Or just bring back ray tracing.
Or just go back to an earlier engine version which has it. You’re welcome.
I was just reading a SIGGRAPH talk on hemispherical lighting from Activision, and that convinced me more that Epic should invest in a better baked lighting solution. We’re still struggling to hit those performance numbers with lumen, especially in indoor scenes, and a more robust probe-based system would be very useful. As for software lumen, I’d be curious to know how that would work, what would you sample for hit lighting if you don’t have lightmaps or the surface cache for material information?
I really wish they would 
I was originally optimistic when GPU lightmass was announced and Epic had said Lumen reflections would support lightmapped GI. But I didn’t realize lightmapped GI support for Lumen reflections would just be a hardware raytracing option, and GPU lightmass has really languished since the release of UE5.
Just to clarify I don’t think that Lumen + Lightmapped GI only sampling the VLM is intended. I’m certain that at one point, it DID sample surface lightmaps correctly, but I guess at some point it broke.
As for how it would work with software raytracing my thought was that it would use distance fields and surface cache, the same way Lumen reflections currently work with Lumen GI. Except the surface cache could be pre-computed for the static lighting. I don’t know how performant this would be in practice, it might not be worth it.
At the risk of getting too off topic there might be better options. For example Mafia 3 stored depth in their reflection captures and traced multiple sets of them to get the hit result. It covered the entire roughness range and ran on a PS4 at 1080p in 3ms. The results were remarkably good quality imo, even if it did have some… weirdness on mirror surfaces.
Frostbite also somehow implemented approximate specular from their lightmaps without the need for any reflection captures which has some downsides (that he explains) but still looks really good.
Unreal’s static lighting was built for UE4 and iirc it was intended for the xbox 360… On modern hardware I’m sure if it were a priority the team at Epic would come up with something great. But since Fortnite doesn’t need it… well… I suspect it won’t be a priority.
I agree with you, although I can understand why from a dev resources perspective they have been focusing on lumen more. Performance is massively better compared to where it started at, but image stability is still enough of an issue to warrant better baking.
It’s a good question, although I will say that combining baked lighting with DF lighting has been a very successful in the past (Stray made great use of it). I wonder if you could have the SDF look up radiance from a volumetric lightmap, which would give low-res but still color-accurate GI. Expense is a great question though.
Slightly off topic too:
All that said, if you want a really good implementation of RT reflections and baked lighting, look at the Callisto Protocol. Their SIGGRAPH 2023 talk (SIGGRAPH 2023 Advances in Real-Time Rendering in Games course). Since most games are going dynamic it makes sense that it’s not a priority for Epic, but there are still situations where dynamic GI isn’t performant.
That reflections solution in Mafia 3 is really interesting as well. I think I saw God of War use something like that too (they called it Ray-traced cubemaps or something else), which overall gave really high-quality especially for non-mirror surfaces. It’s a brilliant idea and one that’s perfect for pretty high-quality dynamic reflections, but I think with how quickly RT performance is improving given new innovations, it probably won’t be implemented going forward. Also, the mirror issue is really fascinating. The temporal accumulation for the SSR broke somehow, and samples got reprojcted into the cubemap? It was an interesting bug. Mafia 3 still had some of the best mirrors I saw outside of an RT game.
i’ve been rehashing tlou part 2 today. i know they used baked directional lightmaps for the world shading and a hack ■■■■ of irradiance volume data for character model gi. it looks good. yo
reflections are whole different beast tho. at low roughness one could use the irradiance probes, higher up use roughness mipped parallax correct captures or go full on raytraced for flat out mirrors. it’s a load of shader math either way. and a bit of data to support all of the tech blend. hmmhmm
I was actually working on a type of ray parallax corrected cubemapping system as an experiment recently, although still too early to show anything, and not sure if it’ll ever get finished. But the ideas were to either use a depth map technique like POM or SDFs to trace the cubemap against.
Not really intended for fully dynamic real time reflections, but to allow for higher quality parallax correct captured reflections for edge cases that lumen struggles with, such as perfect mirrors in indirect lighting environments.
Also have some ideas about using screen space lighting and shadow techniques on unlit cubemaps to allow for seemingly dynamic re-lighting on a static cubemap.
Although most of the time I suspect it’ll be better to just have multiple cube maps for different lighting.
But not sure how much effort to put into it if it’ll be obsolete before long.
Any idea why my lumen scene looks like this?
Same scene with thin geometry for walls looks better but has some corner leaking, so i made the room from individual thick parts that should do better and lumen now does worse job somehow.
This is on a macbook(m3pro) 5.4.3
Normals are correctly oriented, no weird scaling or transforms, no holes…
you’re obviously missing surface cache data. it’s all pink. and you got no normals aka it’s a hollow distance field. what did you use as the base mesh to build it? does this mesh have a proper distance field? there are console commands and viewport options to display that data.
the artefacting is temporal and probe occlusion cause the cache data does not exist. it’s juggling the light computation with probe data only.
Yeah, but it did compute properly when the meshes were just planes. Right now its just basic “blocks” boxy meshes to make it as simple as possible. I kinda have a suspicion this is mac only problem. Will try to get the meshes to PC tomorrow and check it out there cause I don’t remember ever having this issue on pc
There’s something really weird with geometry - notice in the first view how normals are broken and some meshes are missing. Like if all your SDFs were generated as two sided (depends on the default material and two sided setting in the static mesh editor), which we treat as semitransparent foliage. Try changing them to one-sided.
Also if this is like archvis or something, you likely should use hardware ray tracing.
Got it
That was the issue, however it couldn’t be fixed while in editor. Not even at reimport would it recompute sdfs after i made sure the material is one sided.
Since I had simple planes as walls before I did setup the default material as twosided, but that material would also be applied by default on reimport of meshes which were now thick walls. I switched twosided option on material off but it didn’t do anything until I restarted.
I hope I will be able to in 5.5 finally. As of now not even though m3pro supports hwrt, I cannot use it in unreal.
Anyways, it does look like importing mesh while having twosided enabled by default on the material was indeed causing the issue!
EDIT: I can see now that enabling and disabling the two sided sdf generation in static mesh editor can easily make those meshes hollow and fix them too by disabling it while in editor.
So I assume that option was simply enabled by default on import cause the material had two sided option enabled? Or what esle could cause this to be enabled on import?
@Krzysztof.N Just out of curiosity, is MegaLights expected to go into Beta for 5.5, or is it still a ways off from a servicable implementation? I know you talked about potentially creating a MegaLights feedback thread when the time was right, and there were some possible bugs I wanted to share if there was a good place to do so.
you mean manylights? that is already in “beta” or rather alpha stage via cc. might aswell throw the feedback in here for now. i did too. rather a couple of us did. feedback is always good. get it better for beta stage. you know?!?
I’ll make a dedicated thread when it will be officially announced as at least experimental. For now officially this feature doesn’t exist even though quite a few people already use it and are happy with the results :).
As for the bugs and feedback please write them here, this way we can look into it and maybe improve something for 5.5.
