OpenGL : Interaction

File (s) are available for download. You must login to access the file(s).

The model for interpretation of OpenGL commands is client-server. An application (the client) issues commands, which are interpreted and processed by OpenGL (the server). In this sense, OpenGL is network-transparent. A server can maintain several GL contexts, each of which is an encapsulated GL state. A client can connect to any one of these contexts. The required network protocol can be implemented by augmenting an already existing protocol or by using an independent protocol. No OpenGL commands are provided for obtaining user input.

The effects of OpenGL commands on the frame buffer are ultimately controlled by the window system that allocates frame buffer resources. The window system determines which portions of the frame buffer OpenGL may access at any given time and communicates to OpenGL how those portions are structured. Therefore, there are no OpenGL commands to configure the frame buffer or initialize OpenGL. Frame buffer configuration is done outside of OpenGL in conjunction with the window system; OpenGL initialization takes place when the window system allocates a window for OpenGL rendering.

Display Lists :

A display list is simply a group of OpenGL commands that has been stored for subsequent execution. The glNewList() command begins the creation of a display list, and glEndList() ends it. With few exceptions, OpenGL commands called between glNewList() and glEndList() are appended to the display list, and optionally executed as well. To trigger the execution of a list or set of lists, use glCallList() or glCallLists() and supply the identifying number of a particular list or lists. You can manage the indices used to identify display lists with glGenLists(), glListBase(), and glIsList(). Finally, you can delete a set of display lists with glDeleteLists().

GLUT :

The OpenGL Utility Toolkit (GLUT) is a programming interface with ANSI C bindings for writing window system independent OpenGL programs. The toolkit supports the following functionality:

One of the major accomplishments in the specification of OpenGL was the isolation of Window System dependencies from OpenGL’s rendering model. The result is that OpenGL is window system independent. Window system operations such as the creation of a rendering window and the handling of window system events are left to the nativewindow system to define. Necessary interactions between OpenGL and the window system such as creating and binding an OpenGL context to a window are described separately from the OpenGL specification in a window system dependent specification.

Removing window system operations from OpenGL is a sound decision because it allows the OpenGL graphics system to be retargeted to various systems including powerful but expensive graphics workstations as well as mass-production graphics systems like video games, set-top boxes for interactive television, and PCs.

Unfortunately, the lack of a window system interface for OpenGL is a gap in OpenGL’s utility. Learning native window system APIs such as the MFC, QTor X Window System is daunting task.

GLUTis designed to fill the need for a window system independent programming interface for OpenGL programs. The interface is designed to be simple yet still meet the needs of useful OpenGL programs.

GLUT simplifies the implementation of programs using OpenGL rendering. The GLUT application programming interface (API) requires very few routines to display a graphics scene rendered using OpenGL. The GLUT API (like the OpenGL API) is stateful. Most initial GLUT state is defined and the initial state is reasonable for simple programs.

The GLUT routines also take relatively few parameters. No pointers are returned. The only pointers passed into GLUT are pointers to character strings (all strings passed to GLUT are copied, not referenced) and opaque font handles.

The GLUT API is (as much as reasonable) window system independent. For this reason, GLUT does not return any native window system handles, pointers, or other data structures. More subtle window system dependencies such as reliance on window system dependent fonts are avoided by GLUT; instead, GLUT supplies its own (limited) set of fonts.

For programming ease, GLUT provides a simple menu sub-API.While the menuing support is designed to be implemented as pop-up menus, GLUT gives window system leeway to support the menu functionality in another manner (pull-down menus for example).

GLUT is designed for simple to moderately complex programs focused on OpenGL rendering. GLUT implements its own event loop. For this reason, mixing GLUT with other APIs that demand their own event handling structure may be difficult. The advantage of a builtin event dispatch loop is simplicity.

GLUT routines are logically organized into several sub-APIs according to their functionality. The sub-APIs are:

Initialization: Command line processing, window system initialization, and initial window creation state are controlled by these routines.

The Author

Sandip is a successful serial entrepreneur in CAx space. He co-founded CCTech, Zeus Numerix, and Adaptive 3D Technologies in the span of last seven years. Sandip has more than 10 years of product development experience, in the field of CAD, CAM, CFD and Graphics simulations. He has done major contribution in conceptualizing, designing, and developing 3D CAD application, faceted geometry kernel, faceted Boolean, mesh generation software with automatic fluid volume extraction for dirty CAD and Point cloud meshing.

Sandip’s passion for CAx development leads to six month's CAD development program at CCTech which created 100s of CAx developers. Prior to entrepreneurial pursuit Sandip was employed with SolidWorks through 3D PLM Software, where he held the position of Sr. Developer in Part Development Team. He holds M.Tech. in Aerospace Engineering from IIT Bombay. Sandip is also the National Award winner for Mechanical Engineering Design.