That’s interesting. Thanks! I’ll try to reproduce it in a new project. Maybe something else together with modulate acts up.
Just for clarity the way I tested was by applying the modulate material to a plane and then positioning the camera in front of it so it was covering the whole screen. It was an empty scene though, but I tried adding some Lit translucency (thin translucent and default lit) to the scene and the reflection cost was still basically flat with/without the modulate material.
Tested with both software and hardware raytracing, couldn’t really think of anything else it might be but if you come up with something else you want me to test I’ll give it a shot.
I’m on an nvidia gpu btw, 4070 super, in case it may be hardware/driver related.
interesting. modulate seems to be broken in my engine setup. the additive mode breaks when rendered with raytraced translucency.
i’d have to check some shaders to find where that composite happens, now.
Encountered this in the Nanite foliage sample, maybe a better view of the issue (or at least less seizure inducing). Definitely looks pretty gross.
yeh. that looks pretty bad. i guess they should preload some sort of data into the color buffer when they hit pixels that have no motion history. iirc there’s a bit for that. what data to throw in there? i dunno. something that has luminance. skylight color match., world grid or screen space neighbors to probe quickly. : )
@Krzysztof.N
BUG: I just tested the ray-traced refractions in Unreal Engine 5.7 preview. And Ray ray-traced refractions are still blocking GI inside glass objects.
well… i shoulda shared this earlier? been doing a bunch of experiments.
it’s not a bug. there is simply no GI data in the raytraced scene. it’s just polygons, light data and materials. if you use the right glass material you can get light into the bottle. left is the singular mesh. right is the split one with pills/cap and glass seperated. the latter, like the shelf i tested, has some issues. both have a double layer of refracton. this is still 5.6, btw. same result in 5.7pre.
and the view outside of the shelf. the glass plane is simple translucent since refraction on that would be wasted. you can see a hint of illumination but still no GI, since the data is not available in the raytraced scene which is inside the bottle. it’s just how raytracing works.
a cheat i would try, is to bake a static GI texture into the bottle. perhaps with a dim switch you can put into the per instance data for authoring the static light level or color.
Unreal Engine Developers might figure out something to overcome this limitation. A few years back, who knew we would have something like Megalights?
For the time being, instead of relying on baked texture, I can keep the refraction disabled.
Your top image also has dark shadows. which looks bad. And after disabling ray-traced refraction, I get better shadows instead of completely dark. So I think it’s better to keep ray-traced refraction disabled until devs figure out something.
you dunno how? okay. i may pick it up again, tomorrow. it’s not rocket science to get a bit of occlusion baked and make the shadows brighter with some shader design.
yes I know how to bake AO. But instead of a workaround, I would love to know the unreal engine’s developer take on this issue. I already sent the test project to developer
okay. you don’t want creative? it could be done a lil cheaper. but you insist on a developer reaction. like TI. the whole stigma. rant platform. i really don’t know why you need this done in reatime, anyway. it’s just some pill bottles in a shelf. will they move at any point in time? no choice to bake some static data?
i’m out of this loop, then, anyway. : )
1 Like
i found this commit from oct 21, so not gonna be in 5.7 but in 5.8.
I wonder what this is?
https://github.com/EpicGames/UnrealEngine/commit/fead0b4f3cfc6262371837867d16e8aea3345481
it uses r.Lumen.IrradianceFieldGather cvars, and Krzysztof.N said some time ago IrradianceFieldGather was an old DDGI style prototype (or i could be wrong), so i guess it will be resurrected in 5.8?
I wonder if it is DDGI style, can epic investigate maybe they could turn it into baked solution as well, overwatch 2 dev recently gave a presentation how they moved from Enlighten middleware to BAKED DDGI “inspired solution”. And it improved baked times significantly for them compare to Enlighten. I don’t know if it’s good enogh quality for a general engine like UE and they said artists need to manualy place volumes (which i think epic wants to avoid), and OW2 maps are pretty small (not open world by any means, more like slightly bigger than counter-strike maps).
I just wish Lumen always worked like this… live-update in editor → then if you need real-time GI in game you are good to go and don’t need to do anything, if not then you need to do some manual work but the idea being Baked and Real-Time GI reusing some data / being closer together and fast bake times. Ideally would be possible to even ship both in 1 game, pretty sure some games do that. Probably not so easy to do for a general engine like UE, but would be a dream…
In any case i’m glad epic is working to make Lumen scale down better than it currently does. 
5 Likes
I’ll take that + the rays for reflections; sounds like a good deal. effective 50% perf increase is no joke.
It took a while to do the heavy-lifting, but for whatever you think of overall performance, they did follow-through with the ‘were going to make it significantly faster’ promise. 56 did a good job for me, 571 a tad better vs that, and then this tidbit. 
If I remember correctly, a prototype of this existed since the UE5 EA days and it just didn’t go anywhere. If this is what it takes to scale lumen down to the mid-range I’m all for it. That said, specular quality worries me a little bit when it comes to keeping light leaking under control.
I just posted this issue ( Lumen surface cache scale woes ) but I wanted to provide some feedback here also regarding how finicky and difficult working with the surface cache is. A casual scan when I was researching this issue turned up problem after problem with people not being able to figure out why objects aren’t in their lumen scene when they ought to be.
The problem with a system that “just works” is when it doesn’t work, now you have two problems. Many projects require finer-grained control over lumen that just isn’t there. The reliance on screen traces obviously invalidates a number of requests to leave things out of lumen (since if they’re getting rendered at all they’d still be visible in screen traces), but the tendency of objects to randomly be excluded for unclear reasons is a real usability issue with projects that aren’t just third person character action titles.
If this thing is going to ship in every game going forward as the gold standard for UE lighting (which certainly seems to be the goal with performance improvements) I just feel like it’s going to need to be more reliable, or give us an actual API to interact with it.