Only with lumen enabled?
honestly i havent tried turning it off,
is there a chance that you know why anti aliasing isnt working on metahumans also, there appear to be some black boxes on top of them them
I would first turn it off and test, then you can know if it’s lumen or not. Also try changing the bloom method from standard to convolution or vice-versa, it seems like bloom can break metahumans for reasons I don’t understand.
2 Likes
This video is set to private, no besides you can watch it that way 
1 Like
We do have caustics via the PT, but if I had to guess it’s because the engineers are handling other features first, as caustics are an incredible phenomenon but probably not as essential to most users as simply getting lumen to run better, or have less noisy GI.
Nvidia does, for the record, have real-time caustics in Unreal. I did a pretty big review of their tech a big ago, and my bottom line is that it’s a technical marvel held back by poor UI (although that has been partly rectified to my knowledge).
There is a presentation about Lumen from SIGGRAPH 2021 :
" Radiance Caching for Real-Time Global Illumination"
and at the end shows a few pictures. Most are made with “half a ray per pixels” but there are a few with 2 rays per pixel for a much higher quality.
First picture attached is with half a ray and the second is with 2 rays per pixels.
What are the cvars or the controls in Lumen to change that magical “rays per pixel” ?
3 Likes
Would also be interested in that one.
This is, thankfully, pretty easy to answer.
My understanding is that .5 RPP and 2 RPP are settings conjured up by default by switching from high to epic. If you want the specific lumen scalability CVars, Epic already has a page setup for lumen performance optimization:
That being said, the concept of ‘RPP’ is a little meaningless with lumen GI. They aren’t actually tracing a ray per a given pixel for diffuse lighting; instead, it’s referring to the # of rays shot per screen probe, which is then interpolated to the Gbuffer for diffuse lighting. Just a bit of technical minutiae, but still.
It seemed like it would be maybe an undocumented and easy way to get past the known methods of improving quality. Even if those 2 rays per pixel seemed like it would be very high quality, when rendering with MRQ you don’t care how slow it is, you just want to increase the quality as high as possible, or until the render starts to resemble the path tracer.
“the concept of ‘RPP’ is a little meaningless with lumen GI” ? But the guy from the video used those terms, plus he was also talking about Lumen.
And that said, I’m not sure which parameter from the " Lumen Performance Guide" would be the equivalent to “rays per pixel”.
There’s another document where they also talk about - ray per pixel. Seems in technical documents and videos they use this term - but in official help documentation they are not.
1 Like
I completely agree with you, Daniel Wright did use the terms ray per pixel, and I certainly don’t mean to say I know more than him; more that, rays-per-pixel as a concept isn’t a useful way to think about performance when rays aren’t actually being traced per-pixel IMO.
This is the same scene that they showed off, at epic settings, UE5.3 (there are some lighting and exposure differences). This is a visualization of all of the rays being traced from one of the screen probes at standard settings, with stronger light appearing more opaque. This is 64 rays per probe I believe, equivelent to 2SPP.
Now this is lumen’s final gather at .25, the lowest value. Notice how incredibly blotchy it is (obviously)
Now, this is lumen’s final gather quality set to 6, the highest value. I don’t know the exact # it’s tracing off the top of my head, but it’s very big.
The final gather quality directly controls what could be considered samples-per-pixel (conceptually), but I’m not sure how it ties into scalability and everything else.
I have read through and referenced this documentation multiple times, you are entirely correct that they use the term as such- I just mean to say that, for diffuse GI, rays aren’t actually being traced from the Gbuffer pixels, rather from downsampled probes. It’s technical and doesn’t really matter in practice, and reflections are traced from Gbuffer pixels to my knowledge anyhoo. No offense meant.
Thanks. So the final gather slider should control the mythical RPP. No cvars needed. Well that control definitely increases the quality, but I was under the impression (falsely maybe) that FG is some sort of averaging and smoothing sampling thing which will obviously help with the perceived quality, but I was hoping for high frequency details increase.
The sort of details you think about when you hear the word “rays” . Sort of an equivalent to the path trace or raytrace rays. But I guess they used “rays” as a sort of “equivalent” concept ?
1 Like
It’s a ray in that it’s a line with a definitive terminus (the camera) and drawn into the scene, like an arrow). By definition that’s a ray, not a line-segment (with two ends) or a line (goes on forever in each direction). It’s like when we say transform vs rotation or scaling; the context is giving you additional information.
Yes, I am being pedantic, and no not trying to be a jerk. It’s just a terminology thing… You start here and go on for a distance (potentially forever, hence the line-ish/ray part).
If it’s hardware supported, it would depend on what data-structure it’s being pushed through. Might not be something serviceable on a card.
1 Like
D5 is software based on unreal raytracing
it has glass caustics
why we dont have perfect glass caustics in lumen and ue5?
1 Like
Wow, I didn’t know D5 was running on unreal engine. It’s probably heavily modified though, no?
Heavily modified is probably putting it mildly, it doesn’t use Lumen, it uses a surfel based GI solution
1 Like
D5 is based on UE4
I think they are using nvidia branch not epic source code!
epic should bring better glass and caustics for us in ue5
1 Like
why we dont have perfect glass caustics in lumen and ue5?
Because it’s not ray or path tracing. Lumen’s design mimics/fakes those true algorithms at a much faster computing rate to use them in game production.
Is there good information/documentation on how D5 does what it does? I haven’t even heard of it until this thread.
1 Like