Sorry I just went to it.
Interesting stuff and that is an impressive video. I have no idea how to tinker and update engine code so I may have to acquire a person who can bring over the IBL capture in UE5. Thanks for sharing that. Bounce lighting really brings the project to another level. And we need something more performant.
I felt like it could work well.
honestly I think this looks amazing. I would love an in depth look at how this was achieved.
If you mean for exterior ambient lighting… Unreal already has that. It’s the skylight with realtime capture enabled.
Interpolating 24-48 cubemaps for interior GI would be wildly impractical, you’re better off just tinting them or just fading between a night/day cubemap. Though… neither of these is possible with the engine in its current state, you’d need to modify it.
Interpolating 24-48 cubemaps for interior GI would be wildly impractical, you’re better off just tinting them or just fading between a night/day cubemap.
I don’t know? I mean every 30 mins we have maximum of two data layers holding their hourly captures, baking each capture separately using the data layers system. Every 30 mins a layer is destroyed(unloaded) for the next layer. That’s that fading part.
EDIT
Though… neither of these is possible with the engine in its current state, you’d need to modify it.
Yeah, I’ve already accepted we’ll need a custom version of the engine but I wont be able to pay someone to do that for a while.
I’m not a rendering engineer but the thought of storing 24-48 cubemaps for every GI probe just sounds like an obscene amount of data, even at extremely low resolutions
Anyway, this is way off topic for the Lumen thread so I’m gonna stop here
Would you be able to get an image of that scene in the surface cache visualization?
Your issue does look partly like SSR disocclusion. You could disable screen traces for reflections and see if that makes a difference, as sometimes the difference in the SSR/lumen scene matchup is quite visually obtrusive.
It also doesn’t look like hardware RT is actually enabled? That blobbiness looks quite a lot like the SDF scene, in which case hit lighting wouldn’t even work alas.
You need an RTX GPU
Also you’re lucky reflection captures are ignored with Lumen, setting it to 2048 is a risky move.
Depends on what you’re doing I guess but for gamedev I would go with a 3060 or better. You may want to buy a 3060 12gb or a higher end 12gb+ card, if you plan on doing super high quality renders.
If you continue using Lumen it really doesn’t matter, as reflection captures are disabled when Lumen reflections are active. But I wouldn’t recommend setting it higher than 512.
On an 8gb GPU you can only place a handful of 2048 reflection captures before you run out of memory and your GPU driver crashes. A large scene is likely to require upwards of a hundred reflection captures… and I don’t know if they stream.
Of course. I’m curious what the aliasing on your surface cache geometry in the background is, that’s rather curious. I’ve never seen errors like that before.
What I would first do is compare lumen’s behavior against the path-tracer. If the path-tracer returns faulty results similar to lumen, then you know that some combination of your materials and scene lights are the issue. If it works, then you know that lumen is the problem.
I would priorize amount of Vram over GPU power, at least 12gb, at Akiras pointed.
After that, there are some GPU models, with a number. That number is related to the power of the cards. For example: 50 series, 60, 70, 80, 90 (with the vitaminized variations with a ‘Ti’ at the end of the name). And series 4000 are more powerful than 3000. In summary: the more expensive card you can buy, the better. But, obviously, don’t buy a 4070 model which is more expensive than the cheapest 4080, for example; the cheapest model of each series is usually good enough.
All are (almost) the same; they are just vendors with custom designs. I would buy the cheapest one of the serie I’m interested in (unless if I’m an enthusiast overclocking user, where I could choose a ‘premium’ vendor). Just look at the series number: 4060, 4070, 4070 ti, 4080, etc.
As a matter of fact, you actually have the two confused, but that’s of no fault to you. The left side of the reflection is drawing from screen-space, and since it has the gbuffer to pull lighting and accurate geometry from, it looks very high-quality. The right side is the simplified lumen scene that offscreen rays are traced against, and it’s simplifed for performance reasons. Screen-space is giving better results than the lumen scene in this case.
Looking back on your previous photo, I believe I understand what your problem with the scene is. If you don’t have an RTX card or similar AMD offering, you cannot use hardware ray-tracing, and without it your scene representation is quite worse. SDFs do not hold up in reflections very well, with blobby artifacting.
Essentially, you cannot get good reflections without hardware ray-tracing. It more or less isn’t possible. The lower in roughness your reflecting surface is, the worse lumen will appear.
You could maybe share that simplified but conflictive scene (and project, with Config folder), so the community can test it and give you more accurate replies.
You are welcome @OurManinAUS, it’s quite a complex system and the behavior certainly isn’t intuitive.
To speak a bit on SSR, when people say ‘screen-space reflections’, all they’re referring to are reflections that were calculated via use of the depth buffer. There are so many different techniques to compute reflections (or any lighting information) from that system, so the quality levels vary immensely. UE4’s SSR implementation was, by default, rather poor. But they offer a much, much better technique in UE5 for lumen, so the quality is now quite good actually. Lumen is architected in terms of fallbacks, where certain techniques flow into others when data isn’t available. When information is off screen for example, lumen pulls data from signed distance fields in the surface cache. As it is, that representation is poor, but at least is guarantees something is there.
Thank you very much also for that information on SSR, it’s quite helpful to have an insight into how these systems in UE5 work.
In the simplified test scene which I’ve now uploaded I think there should be enough light from the sky shining through all the windows to sufficiently light all corners of the interior. My impression is that there should be enough light data available, there might be a field setting value that needs to be changed. Hopefully someone is able to determine which one it is, if that is the case.
The first main headache I had with the interior was a large amount of light leaks. Ultimately I managed to resolve that by adding some light blocking geometry, but one thing I discovered in the process of testing was that the amount of the Dynamic Shadow Distance MovableLight in the Cascaded Shadow Maps section of the Sun Directional Light had an affect on the amount of light leaks and their size. In general reducing that value made an improvement.
Hi @OurManinAUS ,
I have opened the file but I see it as expected (even if as expected means a litte weirdly). To compare, I (we) should need to see screenshots of your problems in this same scenario. About the rest, sure other much more expert and engligh speaking (it’s not my mother tongue) users will give you some great advices.
I believe there is a solution in Epic’s new local exposure system, I’d look at the documentation. They talk about problems with exactly the phenomenon you’ve described, and while I’m no color grader, it may be a very good thing to look at.
Traditional shadow maps may not play nicely with lumen and nanite. I would switch to virtual shadow maps if you can, and when you have the supporting card, RT shadows.
Ok! I have been noticing now that the white material was something like translucent, emisive, unlit, or something like that… you had it as translucent! Obviously, this won’t behave well as a wall opaque material. Assigning a common white material was working quite decent.
But I’m not speaking about reflections. They are just that weird… no solution at the moment.
That is how Lumen reflections work and behave right now. Even if you had HWRT enabled and everything on ultra settings in terms of visuals not the best solution, relies on what your surface cache represents, combined and limited screenspace with weird striped artifacts when camera moving in certain angles. I don’t want to hurt any devs feelings nor any users that are trying to defend and tell you under every post how well and good visuals Lumen reflections work.