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."
Ahhh it seems like only yesterday I was sooo impressed by mario, blocky graphics and plain colors with no frills really. Then I was impressed by doom, 3-d, awesome action, multi-player, toystory-animated movie? WOW! Final Fantasy-Good animated movie! double WOW! Now what next? The way things advance today it really is getting hard to tell real world film scenes from CG stuff, I just watched lord of the rings and it really is hard to tell real from CG, now with the hardware getting cheaper and software becoming more advanced what was only a fantastic dream in the 80's, a big movie corp with render farm only dream in the 90's is now becoming possible for the home user. Don't know about you, but I'm still impressed, and I can't wait to see what is just over the horizon.
My own feelings on the little debate is rather simple. 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.
DirectX9 is really about games - render less polygons on the fly, and it only works with one operating system (any guesses on which one?).
As games and movies start to approach each other in graphical abilities, I wonder if OpenGL will become more important as the Unix graphics programmers start getting pulled from their Toy Story 3 seats to help with the guys making Toy Story 3: The Game.
Right now, the #1 reason why OpenGL is still in a good number of Windows machines is John Carmack. Will things change? Maybe, maybe not. But I still wonder about the future.
52 Weeks, 52 Religions with John Hummel
But this is all going to be great fun for gaming, VR, simulation, and so on.
Bruce
Bruce Perens.
problem: Slashdot posts a story it covered a day ago because the Editors aren't into the idea of actually earning their pay.
conflict: user posts a message pointing out that the Editors are asleep at the wheel.
resolution: WHAP! WHAP! Score: 0, Offtopic.
the quality of this blog gets lower and lower. does anyone disagree?
As computers get more powerful, our demands on them get greater. The time it takes to render a single frame of a animated feature has stayed pretty much constant over the last few years.
I mean, come on people, it's apples and oranges here. Two similar tools for two VERY different purposes. Rendering 80 FPS at 1600x1200 makes good games, but I doubt there will ever be a day when film frames are rendered in real-time. There's just no reason to!
That's not to say that yesterday's movies couldn't be rendered on today's technology. Absolutely! But tommorow's movies are a different story.
It may be the case that in, say, 2005 for example, you can create CGI graphics on your home computer that are equal to the quality of 2002 movie graphics. But the movie graphics standard won't be sitting still - it will always be ahead. Both will always get better. CGI studios will always be willing to invest more in their equipment than a home user, and they will always be able to get better results by spending more money. You can't convince me that someday the $200 video card in my home PC will be equal to the cluster of high-end hardware sitting in Lucas Arts server room at that same moment.
I get sick of hearing this crap. "When will my graphics card be able to do rendering?!", "When will my graphics card be able to display pixar-quality rendering?!", "When will my graphics card be able to put out graphic realism?" ect, ect, ect.
This is a bunch of crap. By the time your playstation 6 or ge-force 7 or whatever the hell it's going to be gets to a point where it can run enough cycles to achieve toy-story quality pictures in real time (which is still years off) the bar will be raised again for cgi.
Just as moores law doubles technology, the technolgy of rendered cgi doubles. Think back when cray supercomputers rendered frames and took about an hour a frame for untextured geometry with little of the properties that are avaliable today. Today, the images still take 1 hour a frame, even though the technology is billions times faster. Why is that? Because cgi artists will continually pump in as much as they can per frame. If it took 20 minutes last year, it's going to take 20 minutes this year because studio x is going to add some new thing that improves quality but still retains their time margin.
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? Perhaps sometime - but when it does pre rendered images will feature something new that real-time can't match. Face it - real time graphics will never replace the quality of pre-rendered.
While it isn't addressed in the article, there are a LOT of things that need to be handled in the hardware that just isn't there.
- Orders of magnitude more polygons. Artists want more polys. I personally would want at least four polys per pixel at any view, just to make sure that the rendering would be correct.
- Raytracing and Radiosity. Both of these have been proposed in realtime, there is a realtime ratracer (RTRT, google on it) and Realtime Radiosity is a siggraph paper (look it up, too.). BUT they only work with limited numbers of objects. They need to work with the number of polygons given above, and they can't.
- Lights and light maps. Current video cards are limited to just a few lights. The latest generation can only do 8 lights. That works for games, Quake uses just a few and artists hate being limited to them. The video cards would need to handle thousands of light sources, and be able to process light maps (for shadows) in realtime.
- Textures. Currently we use textures to hide the fact that we don't have detail. But as long as that detail is missing, things will look bad up close. The 'ideal image' is not a wireframe with a texture draped over it. The 'ideal image' is based completely on the vertex lists. To build a model at the right detail, each pixel in the texture would need to be replaced with a vertex, including color and other material properties, normals, edges, etc. So each value goes from a 32-bit RGBA color entry to a fairly big (about 1000-bit) structure.
- RAM and BUS speed, and model size. Once we have these massive scenes, we have the bottlenecks of RAM and the system bus. We have always fought these in graphics, which is why the push from ISA to PCI to AGP. Trying to make the graphics better will just compound the problem.
The facts are that these won't go away. We will continue making texture mapped wireframe models for the near future. By the time the graphics card industry can do realtime what movie studios do in months today, the movie studios will be playing with the ideas above.A perfect rendering system is almost near-infinite recursive, requires infinitely detailed models, and takes a long time to render. We can't do the infinite perfect system, but we can tell our artists to let it run for about an hour per frame. That means 'no realtime top of the line movies', no matter what.
frob.
//TODO: Think of witty sig statement
Not true... in fact, the opposite is the truth. Rasterization - which I assume is used here to refer to zbuffering - is very highly parallelizable, while raytracing is only moderately so. The fundamental reason for this is that zbuffering needs only serial access to the database of polygons, while raytracing needs unpredictable access to the polygons depending on where rays are reflected and where lights cast shadows. This means that raytracing is subject to a high degree of unpredictable memory needs and disk accesses, whereas zbuffering can be nicely predicted, pipelined, and parallelized. This is why hardware implementations of zbuffering are a dime a dozen, while the only hardware implementations I've seen of raytracing parallelizes only one very tiny portion of the rendering pipeline and has all kinds of problems that as yet are not addressed sufficiently for practical needs.
.
- First they ignore you, then they laugh at you, then ???, then profit.
Not quite, generally one does something along the lines of BSP processing on the scene before raytracing, excluding any elements that move outside of said nodes in the BSP tree. This can vastly reduce one's search space for polygonal access. Furthermore, if one wishes to use reflections or shadows with a rasterizer, one is still required to use non-serial access to the polygon list.
Raytracing is quite parallelizable in macroscopic sense (shared source data). Each pixel carries no dependancies on any other. But one problem is the need for a large cache of intermediary data during processing for a single pixel, which penalizes multiple rendering paths; they would each require as much memory. I imagine a raytracing chip will not evaluate the pixels in the image but speed up common operations (color mixing, vector operations, ray intersections, texture calc. etc.)
Finally, raytracing opens up new avenues for modelling and realizing objects as polygon counts skyrocket: it allows one to rasterize non-triangular objects whose intersections and normals are easily formulated for example quadrics, planes, spheres and simple NURBs.