Yes. I have somewhat solved it. Apparently i didn’t have skylight lower hemisphere to solid color and black. But Exponential height fog, fog inscattering color still affects skylight
Something @ may want to take a look at: surface cache corrupts and propagates errors all throughout the scene, lighting takes on a sort of ‘disco ball’ look. It may have something to do with virtual texture pool memory overflow, but I’m unsure. I’ve experienced this before on previous maps but couldn’t replicate it until now.
It’s not surface cache. It’s a VRAM corruption bug that happens when you run out of GPU memory pool. It corrupts some texture data in memory until the engine is restarted. I remember seeing some info about it, but I heard/read that it was a deeper issue which will require cooperation with nVidia to fix it on a driver level.
1 Like
this is the differences my material on UE 5.0.3 and 5.1.1, Metal material.
I dont know what happens, but it almost black.
That is very strange, what is the lumen scene showing?
And, HWRT I presume?
Hi guys, would like to report some problem I noticed with Lumen. I have created some landscape material and added a fresnel node. As soon as I start increasing the exponent variable, the bouncing light diminishes basically. Look at the examples below. The landscape material’s color barely changes, but the bouncing light dies off.
This is the default one with fresnel node’s exponent set to 0:
This is with exponent set to 0.3:
This is the only variable being changed:
In the landscape material’s color, there is barely any visible change, but the bouncing light’s amount changes drastically and anything above 0.3 makes the bouncing light nonexistent.
Certain material nodes aren’t evaluated/represented in the Lumen scene. Some of these may be intentional and others may be under development or a bug.
I suspect this may be the cause of your issue.
As you can see on the images, it is represented in the Lumen scene, it is changing it, while in the normal viewmode, there is barely any change in the color of the material
That’s exactly my point. The lumen scene representation of the material is significantly different than the final render. Clearly there’s a disconnect between how that material feature is working in Lumen and the base pass. Some part of the materials instructions is likely not being evaluated properly on one of the passes.
You could potentially isolate which by building a fresnel manually, and seeing which node is mismatched.
Did some more poking around to test my theory. One possible explanation and solution:
The camera vector in the lumen scene surface cache is not the same as the camera vector in the actual scene. This is because the surface cache representation is created by using cards - so the camera vector will be generated based on
these pre-computed camera positions.
Left: Surface cache with camera vector from precomputed card generation
Right: Hit lighting for material evaluation (I changed the exponent between screengrabs, so the disregard the change in the Fresnel)
One way to fix this is to enable the more expensive “hit lighting” mode for Lumen. If you aren’t already using it, give it a try and see if your scenes match.
1 Like
Thanks for your efforts, I’m gonna give it a try. Do you think it is a bug and gonna be fixed or it is something that we have to live with and take into account when creating materials whenever using a fresnel node…?
Unfortunately this is working as intended in the case of the surface cache. It’s a material optimization.
For now the Hit Lighting method is the workaround and is part of why it was added. But even that has some material nodes it doesn’t support.
@
Hey . Is there an ETA for Lumen GI hair strands support? Atm they just render pitch black when not directly lit.
From what I’ve been reading in Github, character lighting in lumen has received some improvements; I don’t know about hair specifically, but it might be worth pulling down and testing the _main version.
This came in about five hours ago. As of the latest _main version, lumen now supports multi-bounce (recursive) reflections. To my knowledge, lumen reflections now have full feature parity with standalone RT reflections, minus support for lightmass.
In addition, translucent reflections now support rough surfaces with a subsequent denoising pass, though that update came a bit ago.
4 Likes
I understand the same about that Lumen Reflections feature! Thanks for sharing!
1 Like
Hello
i was wondering if there is a way to activate raytraced ao (RTAO) to work with lumen?
i know we can activate ssao with lumen with a command line and make the material ao work with lumen if you disable static lighting but i cant find any information on RTAO working with lumen. any advice?
thanks
Pardon me asking, but what is your content utility for combining RTAO with lumen? Lumen is already a full-stack light transportation solver, which includes some of what RTAO does. I’m not doubting you don’t have a good use case, just seeking to understand.
If you’re looking to control levels of occlusion from lumen, you can control that in the post-process volume. In addition, color grading can be a very useful tool for controlling the apparent amounts of occlusion in a scene.
1 Like
lumen looks a little flat and unnatural in areas where geometry intersects or meets like where the floor or the ceiling meets the wall or the cornice.
enabling ssao in my opinion improves this.