• Nehe Tutorials
• Zeus Tutorials
• Public API Implementations
• OpenGL ES Implementations
• Glut
• Glut ES
• GlUT Windows Libraries
• GLUT on Windows

struct _ObjMesh *m_pNext; ObjFile m_iMeshID; unsigned char m_iMode; unsigned long int m_iDisplayListNum; } ObjMesh;

Each of the Vertices,Normals and Texture coordinates are also described in a structure:

typedef struct {

} ObjTexCoord;


In the source file, each row of the file will be read in the loadFile(”file.obj”) method and the values will be recorderd in the structure. In order to draw the shape the DrawObj() method will be used.

The first character of each line specifies the type of command. If the first character is a pound sign, #, the line is a comment and the rest of the line is ignored. Any blank lines are also ignored. The file is read in by a tool and parsed from top to bottom just like you would read it. In the descriptions that follow, the first character is a command, followed by any arguments. Anything shown in square brackets is optional.

# a comment line

These are always ignored. Usually the first line of every OBJ file will be a comment that says what program wrote the file out. Also, its quite common for comments to contain the number of verticies and/or faces an object used.

v x y z

The vertex command, this specifies a vertex by its three coordinates. The vertex is implicitly named by the order it is found in the file. For example, the first vertex in the file is referenced as ‘1’, the second as ‘2’ and so on. None of the vertex commands actually specify any geometry, they are just points in space.

vt u v [w]

The vertex texture command specifies the UV (and optionally W) mapping. These will be floating point values between 0 and 1 which say how to map the texture. They really don’t tell you anything by themselves, they must be grouped with a vertex in a ‘f’ face command.

vn x y z

The vertex normal command specifies a normal vector. A lot of times these aren’t used, because the ‘f’ face command will use the order the ‘v’ commands are given to determine the normal instead. Like the ‘vt’ commands, they don’t mean anything until grouped with a vertex in the ‘f’ face command.

f v1[/vt1][/vn1] v2[/vt2][/vn2] v3[/vt3][/vn3] …

The face command specifies a polygon made from the verticies listed. You may have as many verticies as you like. To reference a vertex you just give its index in the file, for example ‘f 54 55 56 57’ means a face built from vertecies 54 – 57. For each vertex, there may also be an associated vt, which says how to map the texture at this point, and/or a vn, which specifies a normal at this point. If you specify a vt or vn for one vertex, you must specify one for all. If you want to have a vertex and a vertex normal, but no vertex texture, it will look like: ‘f v1//vt1’. The normal is what tells it which way the polygon faces. If you don’t give one, it is determined by the order the verticies are given. They are assumed to be in counter-clockwise direction. If you aren’t using vn’s to specify the normal and you wanted to ‘flip the normal’ you would reverse the order of the verticies. In most 3D programs, if the normal points the wrong way, there will appear to be a hole in the object. g name

The group name command specifies a sub-object grouping. All ‘f’ face commands that follow are considered to be in the same group.

usemtl name

The use material command lets you name a material to use. All ‘f’ face commands that follow will use the same material, until another usemtl command is encountered. For all of the Poser OBJ files I’ve seen, all ‘g’ commands should be followed by a ‘usemtl’ command.

Remember that for verticies, they can be interspersed throughout the file, only the order they appear makes a difference. The faces can also be spread throughout the file, except they must follow the verticies they use (I think), and they will be part of whichever group and/or material they follow. That said, most OBJ files follow a consistant layout. Now the ‘normal’ layout of the file will be:

# comment about what application generated this file. # all of the ‘v’ commands will be listed v x y z v … # all of the ‘vn’ commands will be listed, although most Poser OBJ files # do not use the ‘vn’ commands vn x y z vn … # all of the ‘vt’ commands will be listed vt x y z vt … # the object and its material will be set g object usemtl material # all of the ‘f’ commands are listed f 1/1 2/2 3/3 4/4 f ….

Additional Items:

If you had two OBJ files and wanted to merge them, you can cut all the ‘v’, ‘vt’, and ‘vn’ commands from the second file and paste them at the end of the first. However, you cannot just copy over the ‘f’ commands, because they will have to have all their verticies offset. I’m thinking there has to be a tool out there somewhere that will do this for you, but I don’t know of any.

Hair objects with separate pieces like the ponytails that have a hairtie that can be colored separately, are actually a single group. They use additional usemtl commands to perform their magic. You can setup the additional material parameters in the .hr2 file (MAC). Example OBJ:

v x y z v … g hair usemtl hair f 1 2 3 4 f … # there is NOT another g command here usemtl hairTie f 10 11 12 13 f …

The Vincent Mobile 3D Rendering Library an OpenGL ES implementation that can be used for both commercial and non-commercial projects without having to pay license fees. Another great feature is that the library arrives standard with window management functions, allowing applications to be setup quickly and easily.

Hybrid’s “Rasteroid” Implementation

The Hybrid implementation is a commercial library which can be used freely for non-commercial use. License fees need to be payed if you wish to develop a commercial application using this library. The Hybrid implementation does offer advantages over the Vincent library. Some advantages I have come across include a higher frame rate for tested devices as well as the ability to use a depth buffer with greater precision.

GLUT|ES

The GLUT|ES library will be used in conjunction with these implementations as it greatly simplifies the creation and usage of an OpenGL ES window.

In creating OpenGL ES 1.0, much functionality has been stripped from the original OpenGL API and a little bit added.

The definition given by the Khronos group:

« OpenGL® ES is a royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems – including consoles, phones, appliances and vehicles. It consists of well-defined subsets of desktop OpenGL, creating a flexible and powerful low-level interface between software and graphics acceleration. OpenGL ES includes profiles for floating-point and fixed-point systems and the EGL™ specification for portably binding to native windowing systems. OpenGL ES 1.X is for fixed function hardware and offers acceleration, image quality and performance. OpenGL ES 2.X enables full programmable 3D graphics. OpenGL SC is tuned for the safety critical market. » (http://www.khronos.org/opengles/)

Several versions of the OpenGL ES specification now exist. OpenGL ES 1.0 is drawn up against the OpenGL 1.3 specification, OpenGL ES 1.1 is defined relative to the OpenGL 1.5 specification and OpenGL ES 2.0 is defined relative to the OpenGL 2.0 specification. Version 1.0 and 1.1 both have common and common lite profiles, the difference being that the common lite profile only supports fixed-point in lieu of floating point data type support, whereas common supports both.

OpenGL ES 1.1 adds to the OpenGL ES 1.0 functionality by introducing additional features such as mandatory support for multitexture, better multitexture support (with combiners and dot product texture operations), automatic mipmap generation, vertex buffer objects, state queries, user clip planes, and greater control over point rendering.

The common profile for OpenGL ES 2.0, publicly released in August 2005, completely eliminates all fixed-function API support in favor of an entirely programmable model, so features like the specification of surface normals in the API for use in a lighting calculation are eliminated in favor of abstract variables, the use of which is defined in a shader written by the graphics programmer.

OpenGL ES also defines an additional safety-critical profile that is intended to be a testable and demonstrably robust subset for safety-critical embedded applications such as glass cockpit avionics displays.

OpenGL ES has been chosen as the official graphics API in Symbian OS.

Using GLUT comes at the price of some flexibility.Because OpenGL doesn’t provide routines for interfacing with a windowing system or input devices, an application must use a variety of other platform-specific routines for this purpose.

The result is nonportable code.Furthermore, these platform-specific routines tend to be full-featured, which complicates construction of small programs and simple demos.

The 2 most commonly used graphics APIs are OpenGL and Microsoft’s DirectX.

A great advantage of OpenGL is that it is platform independent, allowing your applications to be developed for Windows, Linux, Mac OS and other operating systems.

Porting a graphics program requires only that you install the appropriate OpenGL libraries on the new machine. The application itself requires no change: it calls the same functions in this library with the same parameters, and the same graphical results are produced.

OpenGL is often called an « application programming interface »(API). The interface is a collection of routines that the programmer can call, along with a model of how the routines work together to produce graphics. The programmer sees only the interface, and is therefore shielded from having to cope with the specific hardware work in a somewhat restricted fashion.

Many modern graphics systems are windows-based and manage the display of multiple overlapping windows. Using OpenGL the user can move the windows around the screen using the mouse and can resize them.

Another property of most windows-based programs is that they are event driven. This means that the program responds to various events, such as mouse click, the press of a keyboard key, or the resizing of the screen window.

The three main OpenGL libraries of interst are:

1. Basic GL : The fundamental OpenGL library. It provides functions that are a permanent part of OpenGL. Each OpenGL function starts with the characters «GL ».

2. GLUT: the GL Utility Toolkit, is in connection with opening windows, developing and managing menus, and managing events.

3. GLU: the GL Utility Library, which provides high-level routines to handle certain matrix operations, the drawing of quadratic surfaces such as spheres and cylinders. GLU also assists in the decomposition of nonconvex and nonsimple polygons into simple shapes such as triangles.

4. GLUI: the User Interface Library, as long as GLUT is available, GLUI will operate properly.The GLUI provides programmers with the ability to add sophisticated controls and menus to their OpenGL applications.