I don’t know if fixing this is the Lumen teams responsibility, but I feel like this has been overlooked as a tool for improving interior lighting in Lumen scenes. One of the simplest ways to get better interior lighting is to just enlarge window openings. Design wise this can’t always be done, but we should be able to at least open up the area a bit in the SDF scene.
Conveniently we have the ability to do this by using a replacement mesh for mesh distance field generation… as long as we aren’t using Nanite… It has never worked with Nanite which is incredibly frustrating, and now the issue is backlogged.
To illustrate my point here is an example: Here I have a wall with a 50x50 cm opening, with an SDF replacement mesh that enlarges the opening to 1x1m in the distance field scene. With Nanite enabled, the replacement mesh is unused and the quality suffers.
We experience the same issues in our project. The lighting is not fully updated when some lights are turned off or when it switches from daylight to night time. It starts to disappear only when the user starts looking around, moving around with the camera. Without that, these surfaces keep glowing in the dark even for minutes but maybe forever.
well… from a game or experience design perspective… why are you switching day and night cycles that quickly, anyway?
a game usually has a flow. you run a map at certain time of day. irl the sun is slow. why speed it up? or change it at all. if you transition to a level or scene you clear the cache and rebuild the initial mood before you present it to the player.
in an experience you can clear the cache and use a transition effect too.
hmm. this is a rabbit hole of speed consumers. needs some chill.
why are you switching day and night cycles that quickly, anyway
For baked lighting it makes sense( AC mirage)
(You can only do this on benches which are limited so those transitions are easy to tune for the predictive angle)
Lumen produces noise and slow speed update becuase it’s accounting for every frame for dynamic changes in geometry and only has access to this information and not developer related logic(like the time zone thing etc).
not periodically, but… say you have an archvis app and show a customer a design in different times of day. you can throw in a command and the customer will not complain. the command is
r.LumenScene.SurfaceCache.Reset
as posted by miguel a couple posts above.
in a game this is certainly not always possible, but i reckon even this ac mirage effect, posted above, could be done without the surface cache updating. just gotta make the cache rebuild part of the visual effect. that’s the thinking.
“You can force it to be two sided by selecting “Two-Sided Distance Field Generation” in the static mesh settings.”
Unfortunately doing this severely underoccludes the asset so we are left with a very flat looking foliage asset in our test cases, opposed to an overoccluded one. I strongly suggest considering adding a switch for this or generally looking at the described scenario; if most of the assets geometry has an opaque material assigned to it (what % I’m not sure of), any parts with a two sided foliage material will be overoccluded. Lumen weakens the distance fields when the ratio is within a certain range, but this doesn’t take into account not all meshes will fit in that range.
Hi all, I am new to Unreal and I am getting crazy with an issue for days now.
I’ve used Datasmith to import a scene from 3ds Max.
When I use Lumen everything is fine, once I turn ON Raytracing Shadows or Raytracing GI I get a weird blue result which you can see in the attached image.
I’ve noticed that this is due to the BP_LightStudio element or in general to the Sky Atmosphere Element. What am I doing wrong? Outside of the walls everything is perfect by the way, take a look at the plants for example, inside is a “mess”.
I would like to use the Harware Raytracing as the Lumen ones
are too blurry to me. I’ve tried to use this command:
r.Lumen.Reflections.DownsampleFactor off
But the quality option doesn’t change anything at the end, 200 is the same as 10 or less.
This is why I need the HW raytracing for some future glass elements as well.
I would change this question to: why not? We are supposed to evolve and to be able to achieve new effects, not to just keep sticky in old techniques. Said this, I think not all products are games. Lot of products (and Unreal is a flagship here) are for industries so, a 10 minutes day-night cycle should be a completely normal thing.
You can use the Glitchered’s cvar I pointed before but, it will make a huge blink in all GIs, so it will be clearly noticeable, specially during day scenes. You could make a transition effect like a fast camera’s fadein-fadeout, but this shouldn’t be (ideally, I mean) needed for a continuos day-night cycle.
Do you mean Ray traced reflections? It won’t reflect Lumen GI, so the result you are getting is not extrange. You should use Lumen reflections when using Lumen GI. You can reduce blurryness disabling the cvar which says something like “… lumen … reflections … temporal”, but it will make noise more noticeable.
Exactly. We use it for our archviz app, so fade in and out and such effects might look good in a game, but not ideal for other industries.
What I ended up doing is using the r.LumenScene.SurfaceCache.ResetEveryNthFrame command, which is resetting the surface cache every nth frame as the command says too. This ensures that although after several seconds only, but at least the glowing parts of the night scene are reset once the user advances the time of day.
The other command could also be used from code whenever the user switches from day to night scene.
Yes, that cvars will do the same than the Reset one, but after X frames. But the huge blinking due to GI resets will be very noticeables too.
I finally preferred the Reset one over that one, because you can execute it only when you relly needed it (for example, after being completely in night, just after sunset).
GI Raytracing and Raytraced shadows got replaced with lumen and VSM. Generally you shouldn’t be using them as they are depreciated and not as well supported as lumen or vsm.
agreed. they are very much supported. and they are further improved in 5.4 and 5.5. the vsm alternative for low video memory specs, given the gpu can hande all the rays. they are maybe not the right choice when you spam overlapping nanite instances but in a well designed game world they are totally usable. hmm
RTGI definitely got deprecated bc it was quite bad, RT reflections as well I think bc lumen can do everything they did and better (including working with static lighting). RTAO still exists, but I believe that’s because RTAO is nonphysical and not part of a coherent lighting system like lumen.
