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."
Already has happened. I remember in the 80s when the hot CAD workstation setup was a 386-20 with a TMS34010 driven EGA(yes, this was pre-VGA) card. The 34010 was a 32 bit processor running at (IIRC) 66Mhz vs the 32-bit 20Mhz CPU.
> How does the equation change when you consider the resolution used for each animated frame (of Toy Story), and resolutions that are common in the gaming arena?
Not a lot.
Toy Story was rendered at approx 1536 x 922, only 8% more pixels than 1280 x 1024.
The problem with this is that a company will never believe that such a miniaturization rate is possible.
They prefer to think of that as "silly"
("silly" == "you are trying to rip them off")
The proper way to do this is what most companies that make RAID servers and other computers with large hardware arrays are doing:
1: Build large motherboard with low circut density
2: Build case roughly the size of small wardrobe. 3: Attach motherboard inside case, and fit parts to motherboard.
4: Put lots of flashy lights on case, contemplate adding machine which goes 'bing'.
5: Use lots of external connections, so that there is lots of assembly required and there are lots of bells, whisles, cords, and dongles hanging from the case after assembly.
6: Next year, make the case about 2" smaller in each direction and raise the price about $250 per unit
You think I'm kidding - our school's grade server has less than half the volume of the one that was replaced, and they're not that different in performance.
Remember - size may not matter if you know how to use it, but it may stop you from getting the chance to use it in the first place.
"Who am I" and "Why are we here" are not the problems.
The problem is when someone asks "Why are they here."
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.
NVidia has released a compiler for their GPU's, Cg (C for graphics). I had great fun playing with it and see different effects (charcoal, dynamic fur, ...) in real time (pixel & vertex shading). It's even open source :P
See http://developer.nvidia.com/view.asp?PAGE=cg_main and www.cgshaders.org.
Sack the sigs.
There is already a high-level shading language, even LGPLed, the API is from Apple's QuickDraw3D, it is called Quesa, http://www.quesa.org/. It can sit above any other API, such as OpenGL or Direct3D. It is scene ordinated. It is a pretty cool api, it is a lot easier to use than Direct3D or OpenGL. The file format to save the scene is 3DMF binary or text (XML like); in fact the binary format was appointed to be the binary format for VMRL.
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.
>>Unix machines (Linux, SGI, OS X) are becoming the standard for Hollywood level style movies - they're powerful, you can cluster them with relative ease, and they don't crash that often.
Actually, SGI is the standard and has been for a while. Linux is becoming one and OSX probably never will be. And yes these machines do crash alot. Speaking from experience as someone who was one of the sys admin's of a render farm at an effects house, our 8 and 16 proc. Origin 2k's went down alot. Not because the OS was messed up or we were bad admins, but because we pushed them really, really hard. I used to replace disks in arrays and on systems at least once a week. The workstations used to puke all the time. Why? NFS, SAN, memory, that crazy Maya script someone wrote, etc. etc. Any number of reasons.
Unix is great and it gets the job done better over all, but keep in mind how hard these guys/gals are pushing this equipment. Linux on a pumped x86 is the next workstation of the movie industry as they look to cut costs, there's a lot of reasons that film studios and FX houses are looking at Linux, cost being probably the most important. Keeping the per shot/frame cost down of matte painting and animation is really the key for the accountants and producers at these places.
Remember, most CG work is stuff you don't notice in the movies, like color correction, background things like snow or rain, lighting effects, etc. Stuff like LoTR, tho more common these days, isn't the bread and butter of FX houses. It's the utility work that gets these guys through the times between the big projects.
Side note: I don't dislike OSX, however to say it's going to be the "film" standard is probably not correct. OSX with Maya will find it's way in to ad agencies and boutique design houses who are very mac centric, but the hardware cost is high overall and the software selection is poor. Many might argue with me, but the big fx houses are very invested in SGI hardware right now and are starting to put in Linux based hardware to take advantage of the costs.
-s
Well, it's getting real close.
This 3D package has it:
http://www.equinox3d.com
The first two scenes on he following page run around 4-30 frames per second, fully ray-traced (multiple reflections, refractions etc.) at low resolutions (~160x120) on an Athlon 2000XP.
http://www.equinox3d.com/News.html
The renderer will be released in a couple of weeks.
The program runs on Linux and it's free (shareware).
The author.