you fanboying the dude? why you tryna smooth talk this technique to me? i’m not convinced it’s of use for lots of quality 3d scenarios. i watched this video that explained what the data looks like. a mip mapped volume of cubemaps. wth. i was close. cubemaps enlarge my data estimate by x1536. the storage implications of this volume are humongous. and it’s still not doing offscreen. years or 6 months ago.
it’s a nice illumination technique, they used it for their game and it looks good for their perpective. but… still got it’s technical limits in the grand scheme of things. it’s like any other “product” / technique.
either way… i think we’re derailing the feedback with wishes and tech banter. /tangent
I have no technical idea about this. Just letting you (and the Lumen team, specifically) know the existence of this guy. Maybe he could even give a hand with Lumen, who knows.
Just to finish, where is the orange lighting coming from?
(i noticed: for some reason shadow mapping kinda broke in 5.3.2. right hand prop doesn’t cast mapped shadows anymore. raytraced shadows still look fine tho. soft and hard contacts. (i did a dirt cheap fix on the queen’s chromatic function, btw. i dunno what the shader artist thought there :)). i’ll have to find a way to load the lite city park in this config. it runs great in it’s own minimalist setup. in the full blown project i can’t load the showcase map anymore.)
fixed it. the lights were stationary. the shadows appeared in editor, but not ingame. i set them to movable and they worked again. dunno for sure if i changed mobility or this was always “broken” like that. hmm. the shadows are actively rendering either way.
The reason why his GI doesn’t have noise is because it isn’t designed on the crutch of TAA/frame blending as an option. He mentioned his can work fine for offscreen information using world space information.
Seems like it needs a small amount of fine tuning.
Now I have seen he mentions Lumen too, so it’s an informed guy presenting a (presumibly) new/unknown technique, as he is up to date about already existing methods and techniques:
As far as I can understand he seems to mention that Lumen is using one unique (or two, not sure) resolution for the probes, while his technique uses high resolution for closests areas and sucesive lower resolutions for farer ones, being exponentially cheapers without loosing quality. And I think he says it doesn’t need denoising, quite interesting regarding Lumen’s noise.
This is Lumen’s grid… in a random scene with default (cinematic) settings:
Probe resolution is actually variable to an extent, for world probes at least. Probes nearest to the camera are supersampled, although I’m forgetting the heuristics that drive it. There could be more variability but I would need to reread the presentation.
Stochastic Shadows question for @Krzysztof.N (As there isn’t currently an SS thread), will stochastic shadows support translucency, or should they only be considered an opaque shadowing solution?
For the love of god, if they are Stochastic , allow them to accumulate independently of TAA and Upscalers.
This is Lumen’s grid… in a random scene with default (cinematic) settings:
@Krzysztof.N
It would be worth investing in a jitter pattern that only has upper right diagonal point, and a lower left diagonal point. Two frame accumulation is extremely responsive. I would say lumen just need better logic to pick good candidate parts of the screen of light channel interpolation.
Also, many games use a static environment but have moving suns. Do you think there would be a way to bake probe trace information only for directional lights movement patterns?
how did you produce that grid? i can’t get that done. isn’t this direct lighting in the first place? what’s the light source? this could be the issue there.
edit: nvm. dirt cheap to test. an hdri with a sharp sun exposes the lumen light grid or some sort of grid like structures (depending where it hits).
Not this again.
You can already set the existing Lumen to accumulate as few or as many frames as you want, and can set the jitter width. r.Lumen.ScreenProbeGather.Temporal.MaxFramesAccumulated r.LumenScene.Radiosity.Temporal.MaxFramesAccumulated r.Lumen.Reflections.Temporal.MaxFramesAccumulated
You can also set TAA to just 2 frames if you want. r.TemporalAASamples
But you fill find responsiveness has a price, and while you can fine tune things to your project’s needs, most of the cvars are what they are for good reason.
With proper motion vectors, TAA and related tech - especially DLSS - have extremely minimal smearing and blurring. Add to that the fact that deferred rendering doesn’t really have any other viable antialiasing besides FXAA and here we are. Tech like ray reconstruction has just pushed responsiveness even more.
We’re probably a good long while before it is possible to get acceptable real time raytracing without temporal accumulation and upscaling. Your opinions regarding these techniques have been loud and clear on this and several other threads, there is no need to keep derailing this thread for points you have already made repeatedly. Particularly when your feedback is not really actionable given current technology, and multiple community members have already called out the distraction.
No one likes unresponsive lighting or blurriness or smearing. But every generation of tech has its frogs to swallow, and most of the industry and most of gamers are willing to accept the compromise.
But if you hate temporal effects and upscaling so much, perhaps use a forward renderer or turn off real time raytracing and use FXAA. No one is stopping you from making a game completely free of temporal accumulation or upscaling - you just may have to give something up to get something back.
why you derailing this LUMEN topic with a TAA rant?
what’s wrong with TAA? looks good. it’s upscaled and dlssed ofc. looks just like tsr, which is available too. and against expectations, there’s seriously not alot of aliasing on this fully dithered hair. one of those things that usually aliases a ton.
capture is 48 fps. cause 144 Hz. jsyk. in case it stutters on 60 hz.
eye reflection is working great. skin tone too. lumen certainly improves the shading of skin, compared to direct lighting. gotta get outta the uncanny valley. yo
on that note. the hair shading model is kinda scuffed. very odd illumination. it’s anisotropic or some tangent f*ckery but lit from the back it looks like crap. surely not a lumen issue either tho. more likely a weird shader.
real ordered dithering? for texture alpha sampling? i can’t picture how that is supposed to work. it’s a 4x4 pixel mask. nice size for a tensor core to smudge it. but when rendering this pattern you’d get huge artefacts instead of the lil ones that are there on a smaller 2x2 ( which i think that it implemented rn). i mean… i could actually check the code, but i can eyeball that on the cloud temporal artefacts. it’s a 4 frame loop.
and well… i think i’m allowed to insult gamers that only play and ask for things while coders like i am to some degree too try to figure stuff out. some stuff is just not practical or just doesn’t work like you think it does. alpha testing for foliage and hair and all the semi transparent stuff and smoothing that has been and still is a complex issue. back in the days we cheated the engines with rendering alphatest and doubled it up with translucent for the edges. in these day’s games with the insane amounts of foliage it’s not the most performant choice. you know?!?
simple dithering and taa and all the temporal variations gonna stay for a while.
I have encountered this issue in some different scenarios, not only when using an HDRI. I have prepared a scene isolating the issue. Obviously, this is a test scene with a very certain situation, but I faced this before in real case scenarios (which I can’t share), so a “lab” context is needed, just created in some minutes. It may be quite possible to force other scenarios within more time.
The grid is always there, I think; it’s just related to a combination of your lighting intensities, materials and/or exposures, to increase/decrease the contrast in some way, and expose the grid:
Yellow means the mesh is too small to be included in Lumen. Lumen culls small objects for performance. Increasing the lumen scene detail will keep them longer. You can also mark the mesh as an emissive light source to keep it longer (even if it doesn’t emit any light).
are you joking or trolling or wth? this needs no test, tbh. you overexposed an almost black surface to look almost white. that’s an abnormal lighting condition. at normal 0 exposure level and the skylight dialed in sun against white walls (you gotta eyeball it ofc) it works just fine and looks great. mmh
are you joking or trolling or wth? I have also included a more white scene with light materials… making it dark is just to expose it more. The previous scene I posted, with an HDRI in the background, as using white materials and completely normal values (and not, the lighting was not coming from the HDRI, but from the Sky, with a HDR image as source, which is supposed to work as intended.)
And sometimes, you may have dark materials in your scene.
As I pointed, I have encountered this issue before, in normal scenes, but I see you only read what you want and you are so happy with Lumen and its limitations. Congrats
