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
Again, yes and no. Not even path-tracers necessarily have caustics (due to the expense), and ray-tracing is just a mathematical operation at its’ core, not an algorithm per-se. Caustics are very hard to do because they break some of the assumptions that let real-time RT work efficiently in a scene: translucency means performing refraction calculation, so the light could bounce around a lot before leaving a surface, very expensive in a paradigm where even a single bounce of GI is very expensive.
Furthermore, caustics mean tracing rays from a diffuse surface, through a refracting/absorbing specular media, and to a light source. It’s extremely expensive to do, and a great deal of work has gone into making them renderable even on offline machines.
NVRTX has real-time caustics rendering, which I’ve tested out and reviewed. It is very technically impressive but rather finicky, which may have changed in newer updates.
No matter what, I don’t think any feature of real-time RT should be taken for granted, but especially not caustics given their complexity. Support is doubtless on the way, but it will take time.
1 Like
i wonder, if they use some fake caustics or approximations based on the normals of the selected materials, and made a more convinient version of their older way of realizing/faking caustics.
is there any chance to compare the caustics that D5 generates with a specific model with a render made with some offline render with the same model etc.?
I don´t mind good fakes, because most probably couldn´t tell the difference, especially, if they happen in real time and are constantly changing ^.^
1 Like
There’s a high level overview of how the GI is done but I couldn’t find any useful info about translucent caustics
Edit: Some (but not much) info about their caustics here: Realistic Shimmering Lighting: Real-time Caustics in D5 Render
2 Likes
Given that their GI looks like a mashup of GIBS (Global Illumination Based on Surfels, Frostbite’s work) and ReSTIR, I wouldn’t be surprised if they heavily borrowed from Nvidia’s real-time caustics implementation. It sounds like world-space photon mapping with screen-space splatting, which is Nvidia’s implementation more or less.
Bottom line, the quality is definitely quite impressive, and the combination of ReSTIR with surfel caching is clever.It definitely makes sense that a dedicated rendering system can support more advanced features easier than a game engine with a gigantic codebase.
Epic or D5? Epic has a caustics baker in their water plugin that’s actually quite good. Caustics approximations in general have existed as long as there’s been attempts at water rendering, but most of them are crude tiling textures or light pattern trickery.
Nvidia’s real-time implementation is a little special, because it’s sort of similar to what lumen does in GI: they actually are performing photon mapping and getting information on how light would reflect and refract, but they’re accumulating, filtering, and reprojecting it in a way that’s more complex than path-tracing. It uses a lot of rasterization, but the end result is pretty exceptional and close to the ground truth.
Yes, I have been using hardware ray tracing to obtain reflections, but the rendering speed has dropped significantly compared with Lumen.
And worryingly, hardware ray tracing is marked as obsolete, I don’t know if I can keep using it.
Another confusing thing is that although hardware ray tracing is marked as abolished, UE5.2 still updates the function of hardware ray tracing.
Hardware raytracing is not obsolete, the engine has many different hardware raytracing features (they can even be used for particle collision in Niagara), certain ones are being deprecated because they are made redundant by Lumens hardware raytracing.
You should be using the “Use Hardware Raytracing if Available” setting in the Lumen section of the project settings, not the deprecated features.
1 Like
Even though lumen uses hardware ray-tracing, it has a far more efficient implementation than the ‘standalone’ RT behavior. Smaller payload, more efficient traversal and culling, host of other things. Comparing standalone RT to lumen RT is apples and oranges, but you’d definitely get better performance out of lumen by and large.
Thanks for the Restir GI and SER optimization on driver side, the demo I showed you is actually based on ‘standalone’ RT but significantly higher quality and perform much better.
1 Like