original in en Miguel A Sepulveda
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:
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.