It’s based on the same threshold as dedicated reflection rays - r.Lumen.Reflection.MaxRoughnessToTrace. In UE-Main it’s now also exposed in PPV.
The idea is to only remove RTGI and RTR as those should be fully covered by Lumen now.
It’s based on the same threshold as dedicated reflection rays - r.Lumen.Reflection.MaxRoughnessToTrace. In UE-Main it’s now also exposed in PPV.
The idea is to only remove RTGI and RTR as those should be fully covered by Lumen now.
Anyone have any good strategies for improving the result of distant lighting?
Also interesting to look at the pattern on the ground away from the light source:
Appears to be related to the radiance cache probe resolution/density, but I don’t know if increasing them is really a good idea.
I see, I’m with you now.
Out of curiosity, do you know what we may expect in terms of features/upgrades for 5.4? I’d completely understand if it’s all too early to tell, simply curious.
FWIW there’s a public long-term roadmap now; https://portal.productboard.com/epicgames/1-unreal-engine-public-roadmap/c/1264-lumen-hardware-ray-tracing
Seems one of the priorities is getting HWRT down to 4ms on next gen consoles.
I had no idea, thank you!
Wow, some of those features are absolutely killer. Nanite dynamic displacement looks awesome, and I’m really curious what features compute mats could enable.
Something I’m actually quite curious about @Krzysztof.N, do you and the rest of the lumen team feel that the SWRT/HWRT paradigm has delivered on your original architectural goals for lumen where performance is concerned?
While there are certainly scenes that SWRT has performed markedly better at than HWRT (valley of the ancients comes to mind), it seems that the performance delta between the two hasn’t been matched the quality differences. There are scenes I’ve come across where SWRT doesn’t run significantly better than HWRT while looking significantly worse, especially where foliage is concerned. Is this part of the impeteus for trying to decrease HWRT costs significantly to make it more viable on console; if so, will there be a defocus on SWRT for next-gen platforms?
This is assuming SWRT doesn’t evolve too much; given new techniques like Ray-aligned occupancy maps, perhaps there is more performance on the table than I understand there to be.
Just found an issue with Lumen reflection. I have two basic Substrate materials, one is blue emissive, the other is red basecolor, nothing else.
It’s innate to lumen’s architecture for now, unfortunately.
EDIT: I misunderstood potentially, you posted a photo of a wall with clear surface cache coverage and I inferred. The noise in the PT can be resolved with more samples, the denoiser isn’t great at the moment though.
speckles
You mean flickering? Yes
Ignore the reply to the other person and read the “un-hided” part. Flickering is related to Lumen downscale factor Cvars and temporal accumulation
EDIT: Wait, my eyes unfortunately skipped over the “path traced” detail.
Hi @Krzysztof.N and @Daniel_Wright ,
Maybe you have already thought about it, but what about making Lumen work in baked scenarios? Almost any game needs ALL the meshes to be movable, so this could give you (and us) the headroom to gain more performance too. A whole baked scenario qith just a few dinamic objects.
I think Lumen could work just with dynamic meshes + stationary/movable lights only (when static lighting is set to Allowed), instead of throwing tons of rays in all directions, against all actors.
It could be (in my immagination) something like only throwing rays along a radius of action from the light source (like the attenuation distances of every light), and only when a movable actor is detected inside the light frustrum. And, from that certain object, throw the bouncing (maybe just 1 bounce) rays to project GI and/or AO over the neighbour actors (also determined by a radius falloff, for example).
While I have no idea how that would be implemented, it does make me think back to Distance Field Indirect Shadows and the like. That was a per-mesh distance field, that could use interpolated GI from baked probes to cast accurate indirect shadows. I wonder if one could have a per-object surface cache parameterization as well, such that you could have a totally baked scene with only a handful of dynamic objects, and only need to pay the surface cache cost for a few of them.
All that said, Epic is clearly moving in the broad direction of entirely dynamic lighting, but the performance just isn’t there yet, at least not on consoles.
It would be nice if we could “pre-calculate” the probes and stuff, unless we specifically put a “box” there that says: calculate this all the time please.
that said, I am not that sure which part of lumen needs what amount of compute.
But… then again, with Graphics Hardware advancing fast (aside from midrange -.-), this would be obsolete quite quickly.
While I am largely with you on the obsolescence, given how messy this console generation transition was, there are no guarantees that we’ll get a serious next-gen console upgrade anytime soon (barring some unexpected technical breakthrough). A solution that can ship on current consoles will matter a lot to scale, even as anyone with a PC gets access to real-time path-tracing and many other things consoles couldn’t possibly support.
unless we specifically put a “box” there that says: calculate this all the time please.
I had that same idea but I came across one scenario where is might not be workable due to innate architecture of Lumen: Moving lights would invalidate the pre-calculated.
Funny enough jblackwell mentioned interpolated GI which could solve the pre-calculated profiles(time of day) of the world.
MGSV(2014) used ambient lights/probes(skylight blockers) for every hour of the day and every weather change. The ambient lights used 1/4th resolution cubemaps(not sure what was base resolution) of their static surrounding and then interpolated the those ambient lights as the time of day and weather changed.
I would say this worked visually and performance wise extremely well EXCEPT for a one kind of scenario. When any character would go beneath a strong light in a dark area, the model would not receive any lighting except from the strong light which resulted in the objects being almost pitch black in most areas which looked terrible.
With a “GI calculate box”. You could solve that by attaching that box to any dynamic or stationery/destructible such as the character to absorb proper bounce light.
This is what I mean by lack a per scene optimization tools if anyone was wondering about that when I first said it(I think Miguel1900 or Arkiras). More tools and ideas to save computing on areas where we don’t need computing.
Personally, I think we’re not getting these tools because UE targets FN. FN is a uncommon and worst case scenario because you can’t bake anything(because everything is destructible) meanwhile most open worlds(and successful ones) mostly consist of static objects like the environment.
But, hey I’ll throw out some ideas here.
Hey guys.
I have two bugs in Unreal 5.3.1
First
Translucent material does not appear in reflection.
I’m using Lumen
Second
When I enable PathTracing the translucent material appears in the reflection, but the floor with reflection always has these stripes
Can you help me please?
Translucent materials aren’t currently reflected by lumen, unfortunately.
This is so sad.
And this bug in the mirror material in path tracer?
Floors with mirrored material appear these stripes.
Does anyone have a solution to this problem?
Make sure the origin of the object isn’t too far from world origin and that the scale of object also isn’t some insane large number.
Hi. I have noticed that High Quality Translucency Reflections is not working in Unreal 5.3.1. Can’t get any improvement on reflection quality of translucent meterials by checking “High Quality Translucency Reflections”. It works in 5.2.
NvRTX Caustics indeed support it slight_smile:
not sure what you expect it to look like. translucent support refraction and is properly reflecting. it will not show up in mirrors tho.
if you want that you gotta use masked with a semi control via the dithering effect. it’s temporarily unstable ofc.
i gotta add… some options required for this type of sceneario are not properly applying in the postprocessing editor nor when switching into game mode. they work however when you enable them via commandline on begin play or map load. that’s for proper ingame control to only use them where you need them.