In another post you mentioned Ghosts of Tsushima using custom BRDF among some other things to implement a form of indirect lighting. I don’t recall the lighting differentiating itself from other open world games of the time. Is there any real world benefit to their unique approach?
They have a custom BRDF in their forward shading pipeline to simulate the appearance of anisotropic fuzz. For their indirect lighting system, they first pick one of their dynamic reflection probes (total of 128) to relit/shadow and the results get baked into a compressed BC6H format. The entire process from the relighting/shadowing and texture compression all happens once per frame inside an async compute queue. They're basically balancing the dynamic indirect specular lighting update rate and use HDR texture compression to minimize the memory consumption on their reflection probes ...
And the result are shadows like that:
www.computerbase.de
If you're going to be fixated on just a singular methodology (ray tracing), you're going to miss out on grasping at the beauty offered in other subjects of real-time graphics like their GPU driven procedural grass system ...And the result are shadows like that:
Ghost of Tsushima im Technik-Test: Spielkritik und Fazit
Ghost of Tsushima im Test: Spielkritik und Fazit / Wie gut ist Ghost of Tsushima? / Ein malerisches Setting
This game lacks any kind of modern rendering features and yet needs the same performance as games with Raytracing. So no there isnt "more to graphics technology than just ray tracing". There maybe be alternatives but they should be at least the same quality or be much faster.
You picked like the worst case scenario for the game, 99% of the time it looks much better than that.And the result are shadows like that:
Ghost of Tsushima im Technik-Test: Spielkritik und Fazit
Ghost of Tsushima im Test: Spielkritik und Fazit / Wie gut ist Ghost of Tsushima? / Ein malerisches Setting
This game lacks any kind of modern rendering features and yet needs the same performance as games with Raytracing. So no there isnt "more to graphics technology than just ray tracing". There maybe be alternatives but they should be at least the same quality or be much faster.
Or maybe some people are fixated on attributing unique properties to rasterization because the current consoles hardware is lackluster in RT. However, things tend to change. The PS5 Pro alone promises more changes and performance gains in RT than anywhere else. It's only logical to expect RT to gain disproportionately more attention compared to rasterization in future generations of consoles.
Final Fantasy 15 used Tesselation for the "GPU driven procedural grass systems". The problem with these ports is they are used the most inefficient way to solve a problem because the hardware plattform itself used outdated GPU IP. Fixation on one plattform will always result in worst quality.
Yes, essentially
But that's not true as these are subjects that can be applied in many contexts beyond rasterization! By no means is real-time graphics a completely solved field with ray tracing ...
I didn't claim that they were "not compatible", however you won't gain a deeper interpretation of those problem sets just purely out of understanding the theory of ray tracing as they are orthogonal concepts to each other ...
I have a feeling that you might not know what the term "GPU driven" truly entails. It has nothing to do with tessellation or geometry. It's a very abstract concept about the "absence of a CPU-GPU feedback system" in rendering. With indirect rendering APIs, we evolved from elementary indirect APIs like draw/dispatch indirect (GPU generated commands for shader dispatches) to ExecuteIndirect (GPU generated commands to change shader input bindings) and finally Work Graphs (nested parallelism/forward progress w/ persistent threads) especially w/ the mesh nodes extension (GPU generated commands for PSO swapping)!
Never said graphics was solved with RT. RT is simply more flexible. There are more problems that can be solved with it, and the rest are current API/SW limitations, which can be solved.
Yes, they are orthogonal, that's why I wouldn't attribute any advantages of deferred texturing to rasterization to begin with, because they are present due to limitations in the graphics pipeline in the first place. You don't suffer from quad overshading in RT, so you don't need visibility buffers and other redundant abstractions with it.
Deferred texturing is useful for more things than just reducing quad overshading. It can be helpful for sorting pixels into complete tiles to run full waves of the same batch (no divergent textures/constants too!) as seen with Horizon Forbidden West ...
With indirect rendering APIs, certain aspects can be challenging, such as debugging and profiling, as has been noted in many presentations, optimization guides, and other resources. On the PS4, there might have been command buffers patched directly from compute shaders, bypassing the command processor entirely given that the prehistoric PS4 Pro GPU managed stable 30 FPS at 2560x1440 resolution. In contrast, the much more capable and modern RTX 2070 Super, which should be closer to the PS5, can't maintain the stable 30 FPS at max settings in the same resolution, which is ridiculous. It may be that their ExecuteIndirect implementation is lackluster if they're hitting a command processor bottleneck here. They should have tried other approaches or at least optimized it better because hitting bottlenecks that limit user experience on 80% of your audience's PCs is bad for everyone. In my opinion, the problem with those low level constructs is that they typically offer no visual improvement compared to more conservative approaches, while performance can suffer greatly and optimization becomes a nightmare, making games appear less and less optimized to an audience that doesn't care about all the low level details.
Guess what? You can do the same with RT without deferred texturing.
Except, I can't see a much better abstraction to translate Ghost of Tsushima's GPU driven procedural grass system aside from doing it with Work Graphs ...
Well technically speaking, both GTA 3 and GTA Vice City were released on PS2 alone first, then got ported to PC to almost a year later, then later to Xbox. Devil May Cry games (like Devil May Cry 3) did the same. In fact, I think many games did that, I just can't remember them all.
Looked briefly through the presentation. The pipeline looks like a perfect match for the mesh shaders with the task shaders, which should have helped to bypass the potential command processor bottleneck.
They probably want to address as large a market as possible. Are there any better solutions that would work on GPUs that don't support mesh shaders?
