Seems to be the case. There are plenty of small draw calls (grass) that GPUs don't like, tons of grass leaves - small triangles which GPUs don't like, far draw distances of foliage and grass - lots of overdraw. I wish there were games with RT visibility pass to fix all those shortcomings.
GART: Games and Applications using RayTracing
- Thread starter BRiT
- Start date
Doesn’t the rasterized depth pass accomplish the same thing? In a lot of RT games the depth pass runs in parallel with the BVH build so RT visibility may not be a win.
Depth prepass doesn't solve neither of these issues, it can reduce overdraw, but the gain will vary from scene to scene. In the case of foliage overdraw will always be here by design because depth prepass won't cull too much of it, it works the best in the case of large occluders.
RT visibility would produce the same per-pixel depth as a depth pass. Why would RT visibility be any better at culling foliage?
It would be better because unlike rasterizers, RT doesn't care about triangle sizes, and there is 0 overdraw because all 3D scene is already in BVH so you trace 1 ray from camera to the closest object in scene, then stop at the 1 hit if material is opaque, no need to draw anything behind this, and foliage can heavily rely upon instancing.
Here is a few billion polygons scene running in real time for example.
Oh you meant rendering primary visibility via RT. I thought you were talking about rendering just the depth buffer using RT. RT primary visibility isn’t happening in AAA games anytime soon. RESTIR DI + denoising is still very heavy with basic environment detail like in Portal RTX.
It really has nothing to do with the basic environment detail of Portal, but rather with how RESTIR DI + denoising are heavy by themselves. You can put it in a Cornell box and still get the same FPS.
Cyberpunk 2077 Overdrive will be a AAA game with this, thought it would not be able to leverage this advantage.
As in fully raytraced CP with no rasterization whatsoever? That would be amazing. Is that confirmed? I assumed the RESTIR in Overdrive was yet another coat of RT paint over the rasterized image.
Would a RT depth prepass, filling the depth buffer from the BVH, help for an otherwise conventional renderer?
Don't think so, depth prepass is so cheap because it's 4x speed in comparison with color fill, RT is more heavy than color fill when triangles are large.
Hogwarts Legacy getting RT reflections, shadows, and AO
So where's the cut-off if the rays do more, like G-buffer fill? It's a constant time rasterization, one ray per pixel, no overdraw, no scene sorting, culling is still needed. And wahhlah there's your G-buffer in O(pixels*log(scene complexity)).
2 million rays/frame at 1080p seems extremely cheap for gigarays/second GPUs: 1080p60 is 120M rays/sec, 4k@144Hz is 1,2Grays/sec. Would this help raster performace for weak rasterizing GPUs? What about consoles with their cheaper BVH building? At least it would make the RT units useful on the lowest tier of RT GPUs
.Filling in the BVH for dynamic stuff (like moving foliage, i.e. millions of blades of grass) is probably not so cheap. And the software development costs are, ofc, insane.
Heavily depends on scene's characteristics. While rasterization can't handle multi billion triangles scenes without advanced LODs/culling and perfect scene sorting, it's optimized for handling dozens of pixels per triangle and there is a lot of HW to back this up, so GPUs are certainly fine tuned for current average gaming workloads. The question is what would happen if somebody would push rasterizers beyond what they have been optimized for. There are no dedicated HW rasterizers for efficient microtriangles for example, so going below 3-4 pixels per triangle can already be faster with RT, but then there are the compute SW rasterizers that can still be faster if overdraw is low, so only tests can tell.
The next frontier is multiple shadow casting lights. We’re going to see a few titles on PC lead that charge but it’s going to take another console generation for it to show up there. Which means it’s going to be the console generation after that when current games start looking dated. So 10+ years to go.
I would quess the RT becomes more interesting choice when you do motion blur and depth of field in camera.
Subframe time aware shading, light and shadows can be very nice for quality.
For rasterization you might do just time aware shading, or try to do sampling of surfaces aware of dof/mb or full blown stothastic rasterizer.
Though I'm not sure if any of them can be close in quality and most likely far in elegance of RT solution.
Subframe time aware shading, light and shadows can be very nice for quality.
For rasterization you might do just time aware shading, or try to do sampling of surfaces aware of dof/mb or full blown stothastic rasterizer.
Though I'm not sure if any of them can be close in quality and most likely far in elegance of RT solution.
Frenetic Pony
Regular
I mean, just scatter samples interpolated between previous frame and current frame along the given pixel's path. Probably no one will be able to tell in most side by sides with a six axis motion vector and filtering after, it even includes time dependent shading.
UE's new depth of field is also really close to "no one can tell". A slight modification, stochastic transparency for "inward" (foreground) blurred pixels so the odd dissoclussion artifacts it has from hallucinating those pixels vanishes would help, but that's probably enough of a fix.
The primary use of RT right now is right where it should be, making developers jobs easier so there's less/no baking. The art pipeline has become the major blocker in tons of AAA titles moreso than anything else, so that's at the top of the list. Motion blur/depth of field might be cool, I'm totally open to being proven wrong, but even if its it feels far down on the list.
talking of which, DXVK 2.1 has been released, with (finally!) HDR support. Linux doesn't support HDR yet, but this is a step in the right direction.
Release Version 2.1 · doitsujin/dxvk
HDR support On systems supporting HDR10 color spaces, HDR can now be enabled by setting the environment variable DXVK_HDR=1, or by setting the option dxgi.enableHDR = True in the configuration fil...
github.com
