3-D Graphics and OpenGL
Performance
The focus of 3-D graphics programming to date has been on squeezing
the most performance possible out of inadequate hardware. Inadequate?
Relatively speaking, of course. What I mean is that if you're a gamer
or an imaginative graphics programmer then no matter how many millions
of polygons per second your card renders, and as beautiful and engaging
as the result seem today, you'll always be able to conceive of some scene
or effect that your graphics adapter can't render at speeds suitable for
animation.
Because it's all about pushing the envelope of the hardware, the
key to getting the best possible rendering performance is obviously optimising
your code. But there are two complementary aspects to optimisation which
fall into the categories of analysis/design on the one hand and implementation
on the other. Regardless of your chosen implementation language and your
target microprocessor, the biggest gains are made early on by applying
some lateral thinking (or 'Zen' as Michael Abrash calls it) to your algorithms.
Then, when it comes to choosing a language and writing code, an important
factor will be how much you can make your knowledge of that language work
for you to make your code as trim and fast as it can be. For example,
do you know what the code that your compiler generates looks like at the
machine level? If you used a different syntax in that loop, how would
it affect the generated code? Is the use of that virtual function costing
you anything? Have you tried data recursion instead of code recursion?
Ultimately, is the generated code good enough? For most applications the
answer is yes, but sometimes it may be necessary to drop down to assembly
language. If you're writing at the machine level then you need to learn
the idiosyncracies of your target microprocessor in order to squeeze the
most use out of every processor cycle. This is particularly true of the
x86 family.
The choice of programming language involves some trade-off between
greater ease of use at the high-level, and greater scope for optimisation
(and hence greater performance) at the low-level. Higher-level languages
offer convenience; they relieve the programmer of many responsibilities
for the actual code generated, and they offer various libraries of functionality
for re-use. Low-level languages offer control; which is a blessing if
you need it, and a liability if you don't. The principle that decreased
responsibility brings with it decreased control is taken even further
when it comes to the use of a graphics library, the justification for
which I'll go into next.
There is an enormous amount of work involved in rendering a scene of three-dimensional objects (known as models). All three-dimensional models, no matter how complex, are constructed from what are called primitives. Primitives are faces, lines and vertices (i.e. points), so a cube for example has six faces, the faces are constructed from twelve lines (faces share lines), and those lines are constructed from eight vertices (lines share vertices). Clearly, you can break down any model into a set of vertices. Vertices are points in three-space and each vertex is described by either three or four numbers, depending on the choice of co-ordinate system (something I won't go into here).
Vertices (and consequently models) having been defined, they must be rotated, scaled, translated, textured, lit, perspective projected and rasterized. All of which is, as I've said, an enormous amount of work for your code to do. If you don't trust anyone else to make that code as fast as it can be then you'll have to develop it yourself and lovingly hone and polish it until it can't be optimised any further. Fortunately for anyone with other things to do with the rest of their life, in most cases there's no need to go to such obsessive lengths. The alternative is to make use of the services of a mature rasterisation library such as OpenGL or Microsoft's Direct3D.
Microsoft DirectX is an advanced suite of multimedia APIs built into Microsoft Windows operating systems, and offering all the benefits of COM.
Using the OpenGL and Windows® SDKs, in just a few pages of source code you can create your window, select an OpenGL rendering context into it, prepare your initial state, perform modelview and perspective transformations, then write your primitives into the OpenGL pipeline. If you start a timer and successively adjust your modelview transformation parameters in response to it then you've made your scene's appearance a function of time. That's animation.
SGI™ OpenGL - The industry's foundation for high-performance graphics.
Silicon Graphics Inc™ describe their OpenGL graphics library as 'the industry's foundation for high-performance graphics.' Their enthusiasm is no surprise; but they're not alone in it. Such eminent graphics programming luminaries as John Carmack (
id
Software) and Michael Abrash (ex-id) consider OpenGL both impressively
powerful and easy to use.
Id Software is, by general acknowledgement, the coolest game shop in the world. Named for the instinctual part of the human psyche first identified by Freud, id’s software development team continues to make gaming history.
Although now sadly no longer trading, a company called 3Dfx Interactive made the chips on some of the first good, affordable graphics adapters to support OpenGL hardware acceleration. I bought a Voodoo and then a Voodoo2 card and was very impressed with their capability. For a time, the 3Dfx chips were unsurpassed in their ability to run GLQuake at smooth speeds and high resolutions. By the way, the leap in visual quality between the standard Quake and hardware-accelerated GLQuake was stunning - luminous coloured lighting which flared across the architecture, and bilinearly filtered textures which no longer became pixelated when you got close to them. These features have been standard in games for a long time now but for me the impact of first seeing them hasn't been equalled by subsequent advances in graphics card technology.
More recently another company, nVidia, has released an even more powerful range of chips which has shifted more and more of the graphics processing pipeline's workload from the over-stressed host processor onto the silicon of the card. I have bought two cards based on nVidia's chips, both of which combine regular 2-D Windows acceleration with 3-D acceleration of both OpenGL and DirectX. An innovation of later nVidia products (effectively a hardware implementation of DirectX 8.0's Vertex Shader) allows the programmer to prime the card with a limited number of bytes of assembly-type instructions; in effect a (very) mini program, which the hardware will apply to each vertex rendered. This is a way of altering the properties of each vertex as it is processed by the card, thus retaining the benefits of hardware acceleration. What's interesting is that the instruction set is small and similar to assembly language, and there is a critically small amount of available program space on the card. In what seems to be something of a revival of dated practices, this does place a premium on being able to optimise your machine-readable instructions.
NVIDIA's mission is to be the most important 3D graphics company in the world.
What does the future of graphics and hardware acceleration hold? Who knows. But I know what I hope it holds. I'd like to see applications generate scenes whose information is as complex and rich as the frames of a movie and to do so at high frame rates. I think this may require a similar approach to image-making as that of the Impressionists in the visual arts. I'd like there to be enough processor cycles between the main CPU and the graphics adaptor to simultaneously model the motion and interaction of huge numbers of graphical elements and particles according to unadulterated physical rules. I wonder if, rather than brute force host processing, some parameterised means of simulating dynamical systems might be built into graphics adaptor silicon. Unlike digital circuitry, analog machines are naturally good at simulating dynamical systems so a fruitful avenue of research may be to hybridise a digital computer with an analog one, whose state is sampled periodically by the digital system.
Finally, holovideo. This is certain to become a consumer commodity one day, hopefully sometime soon. It involves the real-time generation of full-colour, three-dimensional, holographic moving pictures and in fact it has already been achieved - in 1989 by the MIT Spatial Imaging Group led by Mark Lucente. There is a wealth of information on computer-generated holography on the WWW but an enigmatic silence regarding progress in the field since MIT's early breakthroughs. Right now I'd be interested to hear anything about the state of progress in holovideo; it's a wonderfully exciting prospect.
Mark Lucente's holovideo page. Some incredible research which I hope has not sunk without trace. Mark moved from MIT to IBM to a firm which seems to have nothing to do with holovideo.