Slashdot Mirror
The Future of Real-Time Graphics
Bender writes "This article lays out nicely the current state of real-time computer graphics. It explains how movie-class CG will soon be possible on relatively inexpensive consumer graphics cards, considers the new 'datatype rich' graphics chips (R300 and NV30), and provides a context for the debate shaping up over high-level shading languages in OpenGL 2.0 and DirectX 9. Worth reading if you want to know where real-time graphics is heading."
Basically, the explanation is that rasterization takes a time proportional to the number of polygons to render a frame, while raytracing takes time proportional to the log of the number of polygons. That might make you think raytracing should be always faster, which it clearly isn't -- the reason it isn't is that the constant factor in each is very different. So you have a*N vs b*log(N), where b is much bigger than a. As N gets bigger (apparently in the neighborhood of 10 million polygons), the difference between a and b becomes less important than the difference between N and log(N).
The main benefits of raytracing over rasterizing is that it is very easy to get things like reflections, shadows, refraction, and other important effects with raytracing, but with rasterizing, you need to do a lot of complicate and CPU-intensive hacks to get the same effect. Another benefit is that raytracing is parallelizable while rasterization generally isn't. That means that if you have a raytracing accelerator card in your PC, you can nearly double the frame rate or resolution by adding a second raytracing card.
Of course, it's all a chicken-and-egg sort of thing, nobody's going to buy a raytracing card until it's a cheap way to do the rendering they want, and it won't be available unless there is a market. Fortunately, there is research into using the next generation of rasterizing graphics cards to greatly speed up raytracing. This will help bridge the gap, by making raytraced games possible using soon-to-be-existing hardware.
You only need all that detail for nearby objects, which is what subdivision surfaces and level of detail processing are for. With procedural shaders and bump mapping, you don't need that much for most surfaces. The detail may be there in the model, but only a small fraction of it needs to go through the graphics pipeline for any given viewpoint. Given that pixel size is finite and human vision has finite resolution, at some point you max out.
For fixed lighting, you can do radiosity in realtime. (Check out Lightscape, now called 3D Viz.) The radiosity map only has to be recomputed when the lights move. Mostly this is used for architectural fly-throughs. Of course, Myst and Riven are basically architectural fly-throughs. (They're rendered with multiple hand-placed lights in Softimage, though; when they were made, the radiosity renderers couldn't handle a scene that big.)
I tend to agree, but at some level of detail, you can render geometry into a texture (maybe with a bump map) and use that until you get really close. Microsoft prototyped a system for doing this automatically a few years back, called Talisman. Talisman was a flop as a graphics card architecture, but as a component of a level of detail system, it has potential.
Moving around in a big virtual world is going to require massive data movement. But we're getting there. This may be the driver that makes 64-bit machines mainstream. Games may need more than 4GB of RAM.
Rendering isn't the problem, anyway. Physics, motion generation, and AI are the next frontiers in realism.
Do you honestly think that gpu's are going to be able to achieve real-time radiosity in next couple years? Real time raytracing like renderes have now? Hundreds of thousands of blades of grass with no tricks? Individual hairs? Do you think that will happen anytime soon?
I used to think as you do. That was before I got a large amount of education while attending Siggraph this year.
At Siggraph, I saw a live demonstration of a real-time raytracer that was also computing a diffuse interreflection solution (radiosity-like, for those who don't understand) on the fly. I also saw a real-time recursive raytracer written by Stanford researchers that was implemented in a GPU's pixel shader. There is currently research on displacement map "textures" that could conceivably let you render thousands of blades of grass or individual hairs without having to send all of that geometry down the AGP bus.
All of these things blow the doors off what people think a graphics chip can do. Your post would have been accurate last year. Not now.
I will agree with one point: software-based rendering will always be able to compute certain effects that will be difficult or cumbersome to do in a GPU. But I'll also claim that the gap is dramatically shrinking.
I'll also say that the two techniques are not really in conflict. You can use them both in conjunction with each other. You can use a hardware-accelerated Z-buffer to help a raytracer determine first-level occlusion. You can use a raytracer to generate textures and maps for a GPU. In the future, we will see both techniques used to compliment each other.