24 minutes ago, NikiTo said:

But i think if Ray Lights dont reach an area, it will create ambient occlusion and should be pretty accurate with Ray Tracing.

It will be a more accurate approximization and it will look better, yes. But in reality light not reaching a surface does not create 'ambient occlusion', or even 'shadows', it only causes less light reflecting form that surface and that's it. I only pointed this out because you seemed thinking that AO is based on real world physics which it is not. Reason is, thinking about AO or shadows makes understanding lighting more complicated than it really is, no matter if you are a painter or a programmer.

I read a lot of comments actually from people not very impressed with ray tracing in first upcoming games. They do not try to spot errors like you do, but they just are not so impressed for the hype.

This only shows how hard it became to impress people with better graphics, and how far we already are. For example the hardest thing to calculate fast, diffuse interreflection, has a very subtile effect on the image in comparision with baking or faking it. Even it is the most missing piece towards photorealism, it will be hard to market, because it is not as noticeable to the untrained eye as the first shadows in Doom 3. Another example would be area lights. Super important because point lights make everything ugly, but it will be hard to impress people just by that. (But there still are enough rich kids to by Ti models like crazy it seems, haha)

Personally i am very impressed of Battlefield reflections or things i've seen in other games. They (who ever ) have achieved a lot in short time.

7 minutes ago, JoeJ said:

They do not try to spot errors like you do, but they just are not so impressed for the hype.

Maybe I am too critic...

`

8 minutes ago, JoeJ said:

This only shows how hard it became to impress people with better graphics, and how far we already are.

What i think is breaking the notion of realism is the instability of the rendering. If we have an approximation, the brain will adapt and the experience will feel real, but if there are disappearing shadows, disappearing and reappearing lights etc, this calls the attention of the player a lot.

24 minutes ago, NikiTo said:

If we have an approximation, the brain will adapt and the experience will feel real

I don't think so. We get to the point where approximations no longer work, but we do not know the reason. E.g. think of one of those UE4 architectural visualization demos. They have accurate baked lighting and now with RT you can add proper reflections. But if you open / close a door, something would feel wrong. You would not know it is the slight change of indirect lighting you miss, but you would know something is wrong, even this is not obvious like popping or aliasing.

The missing things are subtile, but equally important if not more. And even we, as developers are not yet aware what's missing, because most of us have not seen realtime GI. We know movie CGI can look real, but that's really something different.

I had text here it got deleted....

I meant to not back up the shadows but to use a decent engine and keeping with it. No blooms are better than blooms that disappear and appear randomly.

Thor looks green screened here:

3 hours ago, JoeJ said:

It may have already happened. We do not know how dedicated RT cores on RTX work. I guess it's about clustering and sheduling to compromise work and memory divergence, but there must be more because you can do this with compute as well.

I guess it have no sence to make. Classical RT is trade betwin efficiency , realism and hardware abilities where global diffuse lightng is sacraficed for efficiency and z-buffer efficiency sacraficed for low memory usage. z-buffer is other trade that sacraface precisious reflection, refractions and shadows for efficiency. But again z-buffer is mathematicaly same as 1-st RT step. So ask a question may be it can be found z-buffer ways to 2-nd and other steps? And it way mathematically exists. Imagine a G-buffer filled by fast z-rendering. It content a normal, depth and color information for each pixel. Only that needed to finish image is to compute lighing. In real world lighting comes from any directions of hemisphere. By the way we z-buffer rendering able to render up to hemisphere screen.  So we can just place a set of cameras on each pixel pointed along normal and render again to calculate lighting and make same for any other step. Same with refractions. It technique able to solve any issues of global diffuse lighting, area lights and anything other,  and  only require to increase usual GPU efficiency.

I really hope, as response to RTX, AMD to bring us simply a huge brute power. And a good RT library. This way old school will be glad, ray tracers will be glad and coins miners will be glad too.

RTX is basically a marketing term. 

The DXR/VKRT APIs and DirectML / Khronos equivalent expose new abstractions that can be implemented on current GPUs, but also allow for new HW architectures to accelerate them. 

DirectML (API) and NV Tensor cores (HW) allow massive matrix multiplications to be expressed succinctly (API) and executed efficiently. Building specific HW specifically for this task allows a 10-100x speed up over using general purpose shading cores for the same task. So they're staying. NV is as much an 'AI' / deep learning company as a graphics company now (things like self-driving cars are driving their architecture choices as much as what gamers want). Apple has already made this kind of specialized matrix crunching hardware (aka "neural hardware") standard in their products. It's staying around. We can use it for image filters, but other apps on the system will be using it for voice recognition, facial recognition, spatial reasoning, etc, etc... 

As for DXR, there's two major new HW developments that are required to accelerate it properly. 

1) Fine grained thread scheduling. This emerged first in Volta. Traditionally with GPU work we want to Batch, Batch, Batch, and have the CPU send large workloads. In recent years with indirect draw/dispatch the GPU has been able to feed itself somewhat, but you still want to batch large amounts of threads together. However, with DXR, and surface might randomly want to emit a SINGLE ray, which enqueues a SINGLE ray vs scene query, which results in a SINGLE hit shader thread invocation. It was mentioned earlier in the thread that CPUs are better at RT for this reason... Well that's the hype/newsflash now!  These new GPUs are built specifically to tackle this! Details are scarce so far, but they must be able to re-pack many individual thread requests into thread-groups for optimal execution. This is paving the way to entirely new execution models on GPU general purpose shader cores. It's basically CPU style delegates. 

2) Fixed function hardware for ray-triangle intersection and BVH traversal, added now with Tesla. If we're going to be doing these operations a lot, then fixed function HW is going to beat shader cores. If your GPU doesn't have this HW, DXR can implement these operations using the shader cores, but on Tesla, you'll get ray-triangle intersection "for free"... This will stick around for the same reason that GPUs still have fixed function rasterization HW, depth buffer HW, and ROPs. It's also worth noting that while the API does allow drivers to provide 'black box' BVH implementations (in order to allow it to be baked into Silicon), you can also provide your own custom BVH and intersection shaders to be run on compute cores (which benefit from innovation #1, above). 

That out of the way, in the future, the flexible GPU threading model (#1) above is going to have knock on hidden benefits EVERYWHERE. All sorts of workloads besides ray-tracing will be able to be mapped onto these future GPU's much more efficiently now, if this trend continues.

RT specifically will have slow uptake because the best-of-the-betst stupidly expensive HW can only manage something like 4spp at 4k 30Hz, and all other hardware can likely do <1spp... But it's on the roadmap now. We'll be slowly creeping towards the day where more and more of our images are built from ray queries instead of raster queries.

Games have already shipped using hybrid Raster/RT shadows (throwing a few ray queries in to improve quality / remove aliasing -- and this is well before specialized RT hardware existed!!!), so those kinds of tricks will continue. 

NV has shown off a nice adaptive AA technique, where problematic edges are detected and a few extra samples can be collected in those areas on demand by casting some late rays. 

Area shadows can benefit greatly - again, probably a hybrid shadowmaps + ray approach, where better estimations of the penumbra size can be obtained with a few ray queries. 

Reflections are obvious and will be in all the tech demo's... However, even things like baking light probes for "traditional" reflections can benefit... 

It's been mentioned that full path tracing will be too slow - that's true, but, I've worked on games where I've done a 30s light bake of the scene during the loading screen, to allow semi-dynamic scenes (e.g. user created, but static in gameplay). Tesla can do 300 billion ray queries in that time - probably enough for a nice path traced light bake

Two weeks ago i started to create a 3D demo(that is slowly becoming an engine against my intention). The demo is using rasterization.

Should I just throw all that away, because of the RT "revolution"?

7 hours ago, Fulcrum.013 said:

So we can just place a set of cameras on each pixel pointed along normal and render again to calculate lighting and make same for any other step. Same with refractions. It technique able to solve any issues of global diffuse lighting, area lights and anything other,  and  only require to increase usual GPU efficiency.

That's basically what i'm doing with my realtime GI tech, similar to older ideas like Many LoDs or imperfect shadow maps. I think those and other techniques have not yet received enough attention in comparison to voxel cone tracing. My big fear about RTX is that now everybody stops looking at alternatives, and this could act as an innovation blocker on the long run, similar to what happened when first fixed function GPUs have been introduced.

6 hours ago, NikiTo said:

I really hope, as response to RTX, AMD to bring us simply a huge brute power. And a good RT library.

I doubt that. I've skimmed over their Radeon Rays code and it looks like a rushed implementation of classical raytracing, ignoring advanced clustering necessary to limit divergence on GPU (sorry if i'm wrong). They seem to struggle with competing Optix, they will have a big problem in competing RTX even if they keep up their lead in compute performance. In any case, WE should make that library, not AMD or NV. WE are the software guys - they are the hardware guys, and i want to keep it that way. Assuming next console gen will be still AMD it becomes very interesting how software RT will compete against hardware RT.

5 hours ago, Hodgman said:

That out of the way, in the future, the flexible GPU threading model (#1) above is going to have knock on hidden benefits EVERYWHERE. All sorts of workloads besides ray-tracing will be able to be mapped onto these future GPU's much more efficiently now, if this trend continues.

The seperation of general purpose and RT cores makes it unlikely we can utilize improved sheduling for anything else than raytracing. And even if so, the black box prevents it. I assume it will take many years until this changes, similar to the time it took until compute exposed shader cores. This is the whole reason of my criticism: The black box will remain until NVs RT lead has shrunken to zero i'm afraid of, and this won't happen anytime soon. (I hope i'm too pessimistic here.)

2 hours ago, NikiTo said:

Should I just throw all that away, because of the RT "revolution"?

Eventually you should not spend too much effort on things that can be done better with RT, and you should keep a future transition towards RT in mind. The current RT API makes it very easy to do the change, e.g. by still supporting shader per material. (If you focus on AO, i would preorder RTX already ) 

1 hour ago, JoeJ said:

Eventually you should not spend too much effort on things that can be done better with RT, and you should keep a future transition towards RT in mind. The current RT API makes it very easy to do the change, e.g. by still supporting shader per material. (If you focus on AO, i would preorder RTX already ) 

I am still writing the parser. It optimizes the imported model to save 20% of GPU work. I downloaded Aloy from internet but the textures of the model are a mess. Still she has tons of furs on her clothes and I would like to see how my demo will handle those.
Preorder one for me, cuz i am broke I would need too: i8, 32GB+ RAM and SSD to not make the GPU feels like living in a poor neighborhood. Buy me water cooling connected to a fridge too because of the global warming(this summer here is an oven).

1 hour ago, JoeJ said:

My big fear about RTX is that now everybody stops looking at alternatives, and this could act as an innovation blocker on the long run

I agree. The trickery was making it interesting. If people can drop something directly into the editor and the editor to throw it directly into the GPU, creativity would be not needed anymore. Like just drop the models from the editor to the GPU and the GPU will brute force rain billions of rays on it without need to change the code. All realistic games will just throw models at the GPU suing the same code. If somebody wants to make something specific like silhouette effects, then he would have to write some code. For the rest, just drop it to the GPU, it will brute force the scene. Just like we are no longer writing code to rasterize triangles.