PowerVR GR6500: Ray tracing is the future and the future is now

I don't see why it's harder for artists to control the results... can you elaborate? It seems like it's going to be 90% the same. You have a point on a surface, you have a camera vector and light vectors, you supply a small piece of code and out pops a color. The major differences in the pipeline are in the scaffolding: depth tests, reflections, and shadows will be done in different ways. The differences for artists are that they'll have to learn a system with different limitations.

My guess is that game graphics are going to follow the developments in movie CGI. Pixar switched to ray tracing in 2013, and games will switch when hardware powers up and expertise filters down.

If raytraced scenes were hard to control, why would every single animated movie be raytraced?

Raytracing really is the be all and end all of graphics. The more rays you can render, the more realistic your scene will be, up to 100% realism.

Of course, we can come pretty far with the hacks as well, and it's hard to say if hardware raytracing can come close to the quality hardware shader hacks can achieve on traditional GPU's in real time.

In contrast to that technique you have "radiosity", where the illumination at each point on a surface is calculated based on its environment. Radiosity is better at rendering diffuse light, ray tracing is better at rendering reflected light.

The underlying difficulty is that illumination is a maddeningly combinatorial problem. In principle every part of every object in a scene contributes illumation to every part of every other object. The light falling on a desk lamp from the LEDs of a clock also illuminates the desk itself, and so on. Radiosity and ray tracing attempt to solve those problems by making simplifying assumptions and performing a subset of the calculations necessary to illuminate and render a scene completely faithfully. In principle a more proper ray tracing algorithm would be to send out a huge number of rays in every direction for every image field ray, then follow each of those through their evolution, sending out yet more for surfaces each fall on, and so on. But that's far too computationally intensive (it's an O(n!) level problem).

Path tracing is similar to these techniques but makes different simplifying assumptions. And the most important aspect is that instead of deterministically calculating everything in a specific way it uses a monte-carlo method of statistically sampling different "paths" then using the data to estimate the resulting illumination/image rendering. Path tracing results in a compromise between ray tracing and radiosity of being able to render both reflective and diffuse light well, though it has its own short-comings.

I had a similar experience working a bit with Radiance years ago. The output looked mediocre, at best, but it was reporting a real view of the scene; it's call to fame is that it outputs real energy values in physical units (like energy per unit solid angle or luminance or such). But despite the cartoony models I provided, it did demonstrate subtleties that weren't hacks (needed for this application), things that you wouldn't think to or bother implementing directly.

This? This grabs a lot of needed visual artifacts faster and more correctly without crazy hacks (or so it seems - it does say hybrid rendering).

It takes A LOT of work and planning to get light and shadow correct in a raster setting. Most AAA games don't bother. Raytracing makes it easy to get them right, which will make all the difference in the world.

There's a reason Nvidia employs top CG talent for their hardware demos. A pretty demo sells more than an ugly one, even if they essentially pull off the same effect.

Before it was renamed "povray", it was called "dkbtrace". I printed the entire dkbtrace source and studied it, to see how a real Ray Tracer worked; and through it, I learned how efficient vtbls work (it was 1990 C, and though C++ was already starting to become visible and popular, it was still "that new language that may or may not become popular" - dkbtrace implemented all the OO inside).

Thanks, D.K.B.

Nope. I'd say the "raytracing pipeline" really does replace only the rasterization step, and once the triangle to draw is "found", you do whatever shading/lighting/fx/fragshader you want to draw it with? Wouldn't this be the most sensible approach?

Rasterization in lay-man's terms really is just "figure out which triangle, if any, is 'hit' at this pixel", so a historically much faster and very neat hack to avoid the tracing of a ray..

But you don't get cheap soft-shadowing / ambient occlusion / reflect-refract and you'd need to do occlusion culling seperately for current-gen "complex" scenes to avoid a drawcall for all kinds of hidden objects. That's where at some point raytracing as it becomes more feasible also becomes much more attractive. Potentially also reducing geometry-LODing headaches etc..

I can't imagine these ever being cheaper than ASICs.

Ugh. Never. Computing a hash won't be any faster on these GPUs.

Also, if they put FP64 support in their gaming cards they wouldn't be able to charge scientists and engineers extra.