What is OpenGL?

ArticleCategory: [Choose a category for your article]

AuthorImage:[Here we need a little image from you]

TranslationInfo:[Author and translation history]

original in en Miguel A Sepulveda

AboutTheAuthor:[A small biography about the author]

Abstract:[Here you write a little summary]

ArticleIllustration:[This is the title picture for your article]

ArticleBody:[The article body]

OpenGL is without a doubt the prevailing industry API for developing 2D and 3D graphical applications. It can be considered the successor to the formidable Silicon Graphics IRIS GL-library which made so popular SGI workstations as the predilect platform for scientific, engineering and special effects development. SGI put into OpenGL a great deal of their expertise to make an easy-to-use, intuitive, portable and network aware API for the future. At the same time we can credit SGI for realizing the importance of open standards. Several hardware and software makers took part in OpenGL's specification and stand behind it. Thanks to this, OpenGL applications can be ported quite easily to virtually any platform in the market, from PC windows95, to our glorious Linux system, high-end UNIX workstations, right up to mainframe supercomputers. The Architectural Review Board oversees OpenGL specifications, accepting or rejecting changes and proposing conformance tests.

In contrast to the old IRIS GL-library of SGI, OpenGL is by design, platform and operating system independent. It is aware of the network, so it is possible to separate our OpenGL application into a server and a client which actually renders the graphics. There is a protocol to move through the network OpenGL commands between server and client. Thanks to its OS independence, server and client do not have to run on the same type of platform. Quite commonly the server may be a supercomputer running a complex simulation and the client a simple workstation mostly devoted to the graphical visualization. OpenGL allows developers to write applications that can be easily deployed across many platforms.

Above all OpenGL is a streamlined, high-performance graphics rendering library and there are many graphic accelerator cards and specialized 3D cards that implement OpenGL primitives at the hardware level. Until recently these advanced graphic cards used to be very expensive and only available for SGI stations and other UNIX workstations. Things are changing rapidly and thanks to Silicon Graphics' generous licenses and driver development kit we are going to see more and more OpenGL hardware for PC users. Linux users can enjoy this opportunity, Yes! A company named 3Dfx Interactive provides a series of 3D graphics cards and support for the Linux OS through their Glide library. There is another article in this series by Phillip Ross (3Dfx Graphics Cards) that describes in detail the 3Dfx cards available to us. This shows a change of attitude by some hardware manufacturers which finally realize that the Linux market is here to stay. Linux fans should support and encourage this type of initiative.

To achieve OpenGL's hardware independence, commands for windowing tasks as well as commands for obtaining user input were excluded. This sounds like it would be a serious drawback to using OpenGL, but as we will see later (See the GLUT Programming series), it is possible to combine OpenGL with other flexible programming libraries that will handle windowing tasks and obtain user input. Furthermore, OpenGL does not provide any commands for describing complex models (molecules, airplanes, houses, birds, etc.). In OpenGL you will find only the most primitive geometric objects (points, lines, and polygons). The developer has to construct his/her own models based on these few simple primitives. There are OpenGL-related libraries that provide more complex models, and any user can use these libraries to build their own.

In our series of articles about OpenGL programming we will use the C interface for OpenGL because this is the most popular. However the reader should be aware that there are bindings available in other languages: FORTRAN, C++, Ada and Java. Later in our series, after the reader is familiar with the C interface for OpenGL we will say something about Open-Inventor, a C++ library extension to OpenGL.

Without going into too much detail, the following describes some of the features OpenGL implements:

• Geometric Primitives Allow you to construct mathematical descriptions of objects. The current primitives are: points, lines, polygons, images and bitmaps.
• Color coding in RGBA (Red-Green-Blue-Alpha) or in color index mode.
• Viewing and Modeling permits arranging objects in a 3-dimensional scene, move our camera around space and select the desired vantage point for viewing the scene to be rendered.
• Texture mapping helps to bring realism into our models by rendering images of realistic looking surfaces on to the faces of the polygon in our model.
• Materials lighting is an indispensable part of all 3D graphics. OpenGL provides commands to compute the color of any point given the properties of the material and the sources of light in the room.
• Double buffering helps to eliminate flickering from animations. Each successive frame in an animation is built in a separate memory buffer and displayed only when rendering of the frame is complete.
• Anti-aliasing reduces jagged edges in lines drawn on a computer display. Jagged lines often appear when lines are drawn at low resolution. Anti-aliasing is a common computer graphics technique that modifies the color and intensity of the pixels near the line in order to reduce the artificial zig-zag.
• Gouraud shading is a technique used to apply smooth shading to a 3D object and provide subtle color differences across its surfaces.
• Z-buffering keeps track of the Z coordinate of a 3D object. The Z-buffer is used to keep track of the proximity of the viewer's object. It is also crucial for hidden surface removal.
• Atmospheric Effects like fog, smoke and haze make images rendered by computer more realistic. Without atmospheric effects images appear sometimes unrealistically sharp and well defined. Fog is a term that really describes an algorithm that simulates haze, mist, smoke, pollution or simply the effect of air, adding depth to the image.
• Alpha blending uses the Alpha value (diffuse-material value) of the RGBA code, allowing one to combine the color of the fragment being processed with that of the pixel already stored in the frame buffer. Imagine, for example, drawing a transparent light blue window in front of a red box. Alpha blending allows simulating the transparency of the window object so the box seen through the glass will appear with a magenta tone.
• Stencil Planes restrict the drawing to certain portions of the screen.
• Display lists permit storage of drawing commands in a list for later rendering. When properly used, display lists can greatly enhance rendering performance.
• Polynomial Evaluators serve to support non-uniform rational B-splines. This is to help draw smooth curves through a few reference points, saving the need to store numerous points in between.
• Feedback, Selection and Picking features let you create applications that allow the user to select a region of the screen or pick an object drawn on the screen. The feedback mode permits the developer to obtain the results of rendering calculations.
• Raster primitives (bitmaps and pixel rectangles)
• Pixel Operations
• Transformations: rotation, scaling, translations, perspectives in 3D, etc.

As we mentioned, to make OpenGL truly portable and platform independent it was necessary to sacrifice all the commands that interface with the windowing system; for example: opening a window, closing a window, scaling a window, reshaping a window, reading the cursor position; and also with input devices as reading keyboard input etc.. All these actions are highly operating system dependent. Originally the GL-library had its own set of commands for window and peripheral handling but those were IRIX specific (SGI's UNIX operating system). It is up to the developer of OpenGL to know their own platform and take care of handling windows with the native platform.

Thanks to Mark J. Kilgard from SGI, there is an additional library that works around this problem. Mark wrote the GLUT-library, a GL utility toolkit library that substitutes the old AUX library (never mind what the AUX library was, forget about it!). The GLUT library is freely available. Like OpenGL, you can find the source code for GLUT as well as binary versions for Linux. The GLUT library is platform dependent, and it offers a common paradigm for the windowing and peripheral devices. Therefore, when an OpenGL application wishes to open a window for a graphics animation, it uses the GLUT command set and this takes care of the underlying windowing system. In a sense, GLUT hides from the developer the dirty details of the specific windowing systems (X11, windose, Motif, etc..) and lets one concentrate on the task at hand - the OpenGL code. Another nice advantage of using GLUT is that it makes your code platform independent. I have personally written protein and gel simulations that use GLUT and OpenGL and I have been been able to compile and run then without a problem nor a single line of machine dependent code in Linux-Intel, Linux-Alpha, or Windows 95. (I confess I do use windows 95 from time to time ;-) I strongly recommend everyone interested in writing OpenGL applications to use GLUT as your windowing handler.

Clearly knowing how to use GLUT is as important as learning OpenGL so in the current LinuxFocus series about OpenGL we will also include a number of articles that explain, step-by-step, how to use GLUT and handle peripheral devices comfortably.

In closing this short introduction, we cannot forget to mention another of the "Masters of the Universe," Brian Paul, who is steadily and patiently implementing an OpenGL-like library for Linux named Mesa. At the moment Mesa only does software rendering, meaning that it is up to the CPU to perform all the rendering tasks that might otherwise be delegated to 3D hardware, but Mesa contains hooks that are implemented internally that allows drivers for accelerated hardware to be written and utilized. Currently, drivers only exist for Mondello, S3 Virge (Win95 only), GLINT, and Voodoo 3Dfx chipsets. Thanks to the Voodoo driver (written by David Bucciarelli) Mesa can reach the same performance levels as expensive SGI stations, so if you are interested in high performance 3D-accelerated graphics go and buy a 3Dfx card.

Finally, I cannot help telling you about a personal experience on my Alpha-PC (21164 550MHz 164MRam Linux 2.0.32). I use the Mesa library for a Gel simulation program I am writing. There is no hardware support in my system for the Mesa library because up to this moment the Glide library has not been released for the Alpha system (PLEASE HURRY!!!!). Well, when Phil Ross and I recently compared the performance of his Pentium PC + 3Dfx and my Alpha PC + Matrox Millennium card we were a bit surprised to see that my gel animation run as smoothly on my own PC as on his. The OpenGL demos run even better on my system (of course, those that did not use textures). In other words, the lack of hardware support for the OpenGL calls was compensated for by the brute force of the Alpha CPU. To give you an idea of the work in each of the frames of the gel animation, every frame contained a Gel structure modeled with tens of thousands of spheres and cylinders plus all the lighting computations on it. On the PC we couldn't really see a gel with that many monomers because the computations prove to be too much for the poor Intel CPU... the Alpha on the other hand, no problem!. I can't wait to see my Alpha PC with a 3Dfx card and hardware support for Mesa.

• Read Hardware Review: 3Dfx Graphics Card.
• Consult http://www.opengl.org/.
• Read other articles by the same author:GLUT Programming: Windows and Animation, OpenGL Programming: Simple Polygone Rendering.
• Silicon Graphics
  
• OpenGL specs
  
• OpenGL FAQ
  
• 3Dfx Interactive