Have you seen Lumen Performance Guide? There we propose a following scalability scheme:
- Epic GI + Epic Lumen Reflections
- High GI + High Lumen Reflections
- High GI + SSR
- Medium GI (DFAO)
- Low GI (Unshadowed skylight)
“High GI + SSR” is what we usually use on XSS, which should be comparable to lower end PC GPUs. Is this still too expensive? Can you show a ProfileGPU with async disabled (r.RDG.AsyncCompute 0) and explain what performance are you expecting there?
Yes. Lumen caches the most expensive things in screen space, which allows to not be limited by parametrizations like probes or lightmaps, and to automatically adjust quality to what’s visible on screen. The downside is that screen space is a lot of data and there’s always something changing, so you need to recompute a large part of it each frame.
There are also a few other caches like World Space Radiance Cache or Surface Cache, which employ aggressive caching based on this assumption that usually things don’t change in the scene, but they still need to update slowly as tracking scene updates would be even more expensive.
If you want to cache more aggressively then you need to move away from screen space and cache your lighting in e.g. world space probes, like DDGI, but this comes with various downsides. We did experiment with it and there’s a prototype under r.Lumen.IrradianceFieldGather, though it seems to be broken now. But it just not clear whether a grid of probes around camera would be a good tradeoff. There’s lots of leaking and other issues and the only way around them is manual volume placement. Runtime DDGI probe update may be expensive too, as you need to trace a ray and then evaluate material and direct lighting at each hit point.
So basically at that point it feels like this solution would be in this weird spot between Lightmass and Lumen, where it’s neither fast enough to cover all Lightmass plaforms (mobile, Switch, VR), nor good enough for Lumen platforms (consoles, PC). It still may be a good solution for some games, just like LPV was, but it’s unclear whether it would be used by many engine users.
Yes, it’s possible, but it won’t fix all the issues. The general limitation is that probe has limited resolution and can’t represent lighting changes between two probes. DDGI augments that using VSM as a shadowing function, but it’s a very lowres shadow map, which behaves just like you would expect a 32^2 shadow map to behave :). The problem is that those lighting changes aren’t just small scale indirect shadows or similar detail, but it maybe be for example outdoor lighting leaking indoors and breaking the entire scene.
You can’t also increase the amount of probes too much, as their cost grows really quickly due to them being a volumetric representation. Like if you would want to get per pixel quality instead of a single value per pixel you would need to have ~8 probes, where each one has like 64 values for each pixel.
Usually it’s just impractical to track updates. A door opening may influence half pixels/probes in the scene, but to know which ones you would need to trace rays… But if you only trace rays for entire scene if something changes in the scene then you either get hitches on any small movement or some of those movements will result in incorrect lighting.
Yes, but it could move towards a solution like Enlighten, where only form-factors (visibility) is baked, but then you can adjust your lighting in real-time. That feels like a good tradeoff and likely could cover all Lightmass plaforms.
] (you asked what the benefit was) Our workflow entails traditional LOD groups, non nanite DX11 SM5 with lumen SWRT GI and we maintain 90FPS or higher with 4 sessions shared on average on very low spec AWS instances in our fleet. Not needing to worry about nanite software rasterization, WPO limitations, SM6 memory footprint, HWRT GPU instances or due to being a chunk loaded application not needing to worry about nanite mesh sizes made this a win, win, win all the way around.
