Hacker News Reader

> Rendering a million photorealistic objects is not much more compute-intensive than rendering a hundred cartoon objects

Increasing the object count by that many orders of magnitude is definitely much more compute intensive.

Only if you have more than 1 bounce. Otherwise it’s the same. You’ll cast a ray and get a result.

No, searching the set of triangles in the scene to find an intersection takes non-constant time.

I believe with an existing BVH acceleration structure, the average case time complexity is O(log n) for n triangles. So not constant, but logarithmic. Though for animated geometry the BVH needs to be rebuilt for each frame, which might be significantly more expensive depending on the time complexity of BVH builds.

Yeah, this search is O(log n) and can be hardware-accelerated, but there's no O(1) way to do this.

What if we keep the number of triangles constant per pixel, independently of scene complexity, through something like virtualized geometry? Though this would then require rebuilding part of the BVH each frame, even for static scenes, which is probably not a constant operation.

For static geometry we could but for animated geometry or dynamic geometry it would have to be calculated during a mesh shader step.

It's also only O(log n) if the scene is static. Which is what is often missed in the quest for more photo-realistic graphics - it doesn't mean anything if what you are rendering only looks realistic in still frames but doesn't behave realistically if you try to interact with it.

> Rendering a million photorealistic objects is not much more compute-intensive than rendering a hundred cartoon objects

Surely ray/triangle intersection tests, brdf evaluation, acceleration structure rebuilds (when things move/animate) all would cost more in your photorealistic scenario than the cartoon scenario?

Matrix multiplication is all that is and GPUs are really good at doing that in parallel already.

So I guess there is no need to change any of the hardware, then? I think it might be more complicated than waving your hands around linear algebra.

Yes there is, to improve ray tracing…

Combining both ray tracing (including path tracing, which is a form of ray tracing) and rasterization is the most effective approach. The way it is currently done is that primary visibility is calculated using triangle rasterization, which produces perfectly sharp and noise free textures, and then the ray traced lighting (slightly blurry due to low sample count and denoising) is layered on top.

> However, full-scene ray tracing has essentially a fixed cost: the hardware needed depends primarily on the resolution and framerate, not the complexity of the scene.

That's also true for modern rasterization with virtual geometry. Virtual geometry keeps the number of rendered triangles roughly proportional to the screen resolution, not to the scene complexity. Moreover, virtual textures also keep the amount of texture detail in memory roughly proportional to the screen resolution.

The real advantage of modern ray tracing (ReSTIR path tracing) is that it is independent of the number of light sources in the scene.

>Consoles don't have that problem, because not providing perfect backwards compatibility for 20+ years of games isn't a dealbreaker there.

I'm not sure that's actually true for Sony. You can currently play several generations of games on the PS5, and I think losing that on PS6 would be a big deal to a lot of people.

Maybe they can pull the old console trick of just including a copy of the old hardware inside the new console.

However I suspect that this isn't as cost and space effective as it used to be.

So create a system RT only GPU plus a legacy one for the best of both worlds?