Hi. I can’t get Raytraced reflections to work in Unreal 5.1. See screenshot. The glass statue looks good but the reflection of the spheres is wrong. Is there something more I need to do?
1 Like
You’ll always get bad results trying to use standalone raytraced reflections with Lumen. They are not designed to work well together.
1 Like
To build on that, it won’t even make things look better in all circumstances. When I was testing UE5.1 with thin, mostly occluded emissives, I noted that reference mode made the scene look notably worse. If you’re dealing with smoothly transitioning indirect lighting, it gives more accurate results, but it can compromise emissive scenes quickly.
For context, a default screen probe will trace 64 rays (last time I checked the presentation at least). 1024 is 16x that ray count, and it will kill performance in anything but trivial scenes. It’s meant as, well, reference, not gameplay tech.
Yes, I am pretty sure it’s meant for comparisons with the path tracer, which has been used as the reference for lumen. They probably use it to exclude light transport inaccuracy caused by the low ray count interpolated result, when comparing the lumen output with the path tracer output.
1 Like
Are there any plans to add Lumen support for scene capture cubes soon? I take it from the Lumen support commit for the scene capture 2D that it wasn’t added for performance reasons. Would Lumen be unusable with cube captures with the current implementation?
It is indeed possible in the current state of the engine. It would require you to build from source and make some minor modifications to the scene capture cube component. I have tested it and confirmed it worked with a previous version, but haven’t tried it in 5.1.
The performance cost was quite heavy as it requires a second lumen scene, but it can still be useful for baking cube-maps for use in a variety of things. I would like to see it added in the same manner as the 2d capture moving forward. 2d captures also allow you to down-res the lumen scene to manage costs. I think it’s critical feature to add, as without it, manually baked environment captures will not accurately reflect the in game scene.
My engine ran stable with the above modifications, but I wouldn’t want to try and capture every frame for any real time application with it.
Hmm. I already tried the solution in that thread and it didn’t work for me, at least for the cube capture. The original solution was intended for the 2D capture.
If it’s worked for you, would you mind sharing a patch? I’ll give it another go in the meantime.
I’m pretty sure I don’t have the build anymore, but if I remember correctly I just adapted the same changes to the cube component as I saw in the SC2D. I’m on vacation this week so I won’t have a chance to take a look.
What is the CVars to reduce this flickering effect, I’m using Raytracing along with the following commands
r.Lumen.ScreenProbeGather.FullResolutionJitterWidth = 5
r.Lumen.ScreenProbeGather.ReferenceMode = 1
Also, when I put in the commands from above, I get this temporal effect, whenever I move the camera in the editor environment? Is there a CVars for reducing this effect?
Have you tried using Cinematic scalability settings?
Usually ghosting like that means lumen is working only in screen space, make sure your lumen scene debug views look like a close proxy to the actual scene.
Using these prompts seems to resolve this issue for me
r.Lumen.ScreenProbeGather.ImportanceSample = 0
r.Lumen.ScreenProbeGather.ReferenceMode = 0
r.Lumen.ScreenProbeGather.ScreenSpaceBentNormal = 0
Although, has anyone managed to find a way to tweak the graphical fidelity of indirect shadows to make them close to pathtracing? GI bounces? They seem to appear to not meet with the corners of walls like this one for example
r.Lumen.ScreenProbeGather.ReferenceMode defaults to 0, so you can just omit it completely. Just don’t set it to 1 (non default) in the first place.
Once you are sure reference mode is off, are you really certain that turning off the importance sampling with r.Lumen.ScreenProbeGather.ImportanceSample makes the things better, not worse?
r.Lumen.ScreenProbeGather.ScreenSpaceBentNormal set at 0 is actually one of the things that destroys the contact shadows, so that could be part of the issue why your contact shadow is off.
But even if it wasn’t, for a realtime GI, that amount of accuracy is honestly already very impressive.
You seem to be just randomly turning cvars on and off and then using a “bro science” to arrive to some random combination of cvars, half of which have the opposite effect of what you are trying to achieve.
Anyway, for performance reasons, lumen doesn’t run at full screen resolution, so if you are interested in indirect shadow accuracy, your best bet is probably to find settings related to downsampling and fiddling with those:
I’d suggest trying to reduce r.Lumen.ScreenProbeGather.DownsampleFactor. It defaults to 16. You should be able to get more accurate indirect shadowing by lowering that value.
1 Like
UE-170986 SkyLight is not affecting the volumetric fog
2 Likes
Hello everybody,
I updated to 5.1.1 and there is a lot of noise appearing in my scene, which was not the case in 5.1.0
1 Like
Hello,
In addition to my previous message, here is a video that illustrates my problem, a lot of noise appeared without changing parameters just with the update 5.1.1, why?
I couldn’t be sure, but you may want to look at your lumen scene for any differences in behavior.
I will say though, that is a very unoptimal scene for lumen GI. That corner with both the thin geometry and the emissive lighting will be pushing the solver very hard.
Look the scene before update…
This scene worked perfectly before the 5.1.1 update and ran at 60fps without problem or noise…I don’t understand why this happens, all the parameters are the same.
In addition to the modifications in the 2D screen capture PR, I had to add a couple of flags to force Lumen lighting and reflections for the cube capture:
diff --git a/Engine/Source/Runtime/Renderer/Private/SceneCaptureRendering.cpp b/Engine/Source/Runtime/Renderer/Private/SceneCaptureRendering.cpp
index 8967cdbddaa..c295279af3c 100644
@@ -1153,6 +1154,8 @@ void FScene::UpdateSceneCaptureContents(USceneCaptureComponentCube* CaptureCompo
bCaptureSceneColor, &PostProcessSettings, 0, CaptureComponent->GetViewOwner(), faceidx);
SceneRenderer->ViewFamily.SceneCaptureSource = CaptureComponent->CaptureSource;
+ SceneRenderer->Views[0].FinalPostProcessSettings.DynamicGlobalIlluminationMethod = EDynamicGlobalIlluminationMethod::Lumen;
+ SceneRenderer->Views[0].FinalPostProcessSettings.ReflectionMethod = EReflectionMethod::Lumen;
FTextureRenderTargetCubeResource* TextureRenderTarget = static_cast<FTextureRenderTargetCubeResource*>(TextureTarget->GameThread_GetRenderTargetResource());
FString EventName;
Curious I didn’t see a performance drop with Lumen turned on.
Huh, that is indeed baffling. I think filing a bug report would be in order, assuming all other variables are unchanged.