The first type of silhouette edge is sometimes troublesome to handle because it does not necessarily correspond to a physical edge in the CAD model. The reason that this can be an issue is that a programmer might corrupt the original model by introducing the new silhouette edge into the problem. Also, given that the edge strongly depends upon the orientation of the model and view vector, this can introduce numerical instablities into the algorithm (such as when a trick like dilution of precision is considered).

[edit] Computation

To determine the silhouette edge of an object, we first have to know the plane equation of all faces. Then, by examining the sign of the point-plane distance from the light-source to each face

Using this result, we can determine if the face is front- or back facing.

The silhouette edge(s) consist of all edges separating a front facing face from a back facing face.

A convenient and practical implementation of front/back facing detection is to use the unit normal of the plane (which is commonly precomputed for lighting effects anyhow), then simply applying the dot product of the light position to the plane's unit normal:

Note: The homogeneous coordinates, w and d, are not always needed for this computation.

This is also the technique used in the 2002 SIGGRAPH paper, "Practical and Robust Stenciled Shadow Volumes for Hardware-Accelerated Rendering"

[edit] External links

• http://wheger.tripod.com/vhl/vhl.htm

Shadow volumes are a technique used in 3D computer graphics to add shadows to a rendered scene. They were first proposed by Frank Crow in 1977^[1] as the geometry describing the 3D shape of the region occluded from a light source. A shadow volume divides the virtual world in two: areas that are in shadow and areas that are not.

The stencil buffer implementation of shadow volumes is generally considered among the most practical general purpose real-time shadowing techniques utilizing the capabilities of modern 3D graphics hardware. It has been popularized by the computer game Doom 3, and a particular variation of the technique used in this game has become known as Carmack's Reverse (see depth fail below).

This technique as well as shadow mapping has become popular real-time shadowing techniques. The main advantage of shadow volumes is that they are accurate to the pixel (though many implementations have a minor self-shadowing problem along the silhouette edge, see construction below), whereas the accuracy of a shadow map depends on the texture memory allotted to it as well as the angle at which the shadows are cast (at some angles, the accuracy of a shadow map unavoidably suffers). However, the shadow volume technique requires the creation of shadow geometry, which can be CPU intensive (depending on the implementation). The advantage of shadow mapping is that it is often faster, the reason for which is that shadow volume polygons are often very large in terms of screen space and require a lot of fill time (especially for convex objects), whereas shadow maps do not have this limitation.

[edit] Construction

In order to construct a shadow volume, project a ray from the light through each vertex in the shadow casting object to some point (generally at infinity). These projections will together form a volume; any point inside that volume is in shadow, everything outside is lit by the light.

For a polygonal model, the volume is usually formed by classifying each face in the model as either facing toward the light source or facing away from the light source. The set of all edges that connect a toward-face to an away-face form the silhouette with respect to the light source. The edges forming the silhouette are extruded away from the light to construct the faces of the shadow volume. This volume must extend over the range of the entire visible scene; often the dimensions of the shadow volume are extended to infinity to accomplish this (see optimization below.) To form a closed volume, the front and back end of this extrusion must be covered. These coverings are called "caps". Depending on the method used for the shadow volume, the front end may be covered by the object itself, and the rear end may sometimes be omitted (see depth pass below).

There is also a problem with the shadow where the faces along the silhouette edge are relatively shallow. In this case, the shadow an object casts on itself will be sharp, revealing its polygonal facets, whereas the usual lighting model will have a gradual change in the lighting along the facet. This leaves a rough shadow artifact near the silhouette edge which is difficult to correct. Increasing the polygonal density will minimize the problem, but not eliminate it. If the front of the shadow volume is capped, the entire shadow volume may be offset slightly away from the light to remove any shadow self-intersections within the offset distance of the silhouette edge (this solution is more commonly used in shadow mapping).

The basic steps for forming a shadow volume are:

1. Find all silhouette edges (edges which separate front-facing faces from back-facing faces)
2. Extend all silhouette edges in the direction away from the light-source
3. Add a front-cap and/or back-cap to each surface to form a closed volume (may not be necessary, depending on the implementation used)

[edit] Stencil buffer implementations

After Crow, Tim Heidmann showed in 1991 how to use the stencil buffer to render shadows with shadow volumes quickly enough for use in real time applications. There are three common variations to this technique, depth pass, depth fail, and exclusive-or, but all of them use the same process:

1. Render the scene as if it were completely in shadow.
2. For each light source:
   1. Using the depth information from that scene, construct a mask in the stencil buffer that has holes only where the visible surface is not in shadow.
   2. Render the scene again as if it were completely lit, using the stencil buffer to mask the shadowed areas. Use additive blending to add this render to the scene.

The difference between these three methods occurs in the generation of the mask in the second step. Some involve two passes, and some only one; some require less precision in the stencil buffer. (These algorithms function well in both OpenGL and Direct3D.)

Shadow volumes tend to cover large portions of the visible scene, and as a result consume valuable rasterization time (fill time) on 3D graphics hardware. This problem is compounded by the complexity of the shadow casting objects, as each object can cast its own shadow volume of any potential size onscreen. See optimization below for a discussion of techniques used to combat the fill time problem.

[edit] Depth pass

Heidmann proposed that if the front surfaces and back surfaces of the shadows were rendered in separate passes, the number of front faces and back faces in front of an object can be counted using the stencil buffer. If an object's surface is in shadow, there will be more front facing shadow surfaces between it and the eye than back facing shadow surfaces. If their numbers are equal, however, the surface of the object is not in shadow. The generation of the stencil mask works as follows:

1. Disable writes to the depth and colour buffers.
2. Use back-face culling.
3. Set the stencil operation to increment on depth pass (only count shadows in front of the object).
4. Render the shadow volumes (because of culling, only their front faces are rendered).
5. Use front-face culling.
6. Set the stencil operation to decrement on depth pass.
7. Render the shadow volumes (only their back faces are rendered).

After this is accomplished, all lit surfaces will correspond to a 0 in the stencil buffer, where the numbers of front and back surfaces of all shadow volumes between the eye and that surface are equal.

This approach has problems when the eye itself is inside a shadow volume (for example, when the light source moves behind an object). From this point of view, the eye sees the back face of this shadow volume before anything else, and this adds a −1 bias to the entire stencil buffer, effectively inverting the shadows. This can be remedied by adding a "cap" surface to the front of the shadow volume facing the eye, such as at the front clipping plane. There is another situation where the eye may be in the shadow of a volume cast by an object behind the camera, which also has to be capped somehow to prevent a similar problem. In most common implementations, because properly capping for depth-pass can be difficult to accomplish, the depth-fail method (see below) may be licensed for these special situations. Alternatively one can give the stencil buffer a +1 bias for every shadow volume the camera is inside, though doing the detection can be slow.

There is another potential problem if the stencil buffer does not have enough bits to accommodate the number of shadows visible between the eye and the object surface, because it uses saturation arithmetic. (If they used arithmetic overflow instead, the problem would be insignificant.)

Depth pass testing is also known as z-pass testing, as the depth buffer is often referred to as the z-buffer.

[edit] Depth fail

Around 2000, several people discovered that Heidmann's method can be made to work for all camera positions by reversing the depth. Instead of counting the shadow surfaces in front of the object's surface, the surfaces behind it can be counted just as easily, with the same end result. This solves the problem of the eye being in shadow, since shadow volumes between the eye and the object are not counted, but introduces the condition that the rear end of the shadow volume must be capped, or shadows will end up missing where the volume points backward to infinity.

1. Disable writes to the depth and colour buffers.
2. Use front-face culling.
3. Set the stencil operation to increment on depth fail (only count shadows behind the object).
4. Render the shadow volumes.
5. Use back-face culling.
6. Set the stencil operation to decrement on depth fail.
7. Render the shadow volumes.

The depth fail method has the same considerations regarding the stencil buffer's precision as the depth pass method. Also, similar to depth pass, it is sometimes referred to as the z-fail method.

William Bilodeau and Michael Songy discovered this technique in October 1998, and presented the technique at Creativity, a Creative Labs developer's conference, in 1999[1]. Sim Dietrich presented this technique at a Creative Labs developer's forum in 1999 [2]. A few months later, William Bilodeau and Michael Songy filed a US patent application for the technique the same year, US patent 6384822, entitled "Method for rendering shadows using a shadow volume and a stencil buffer" issued in 2002. John Carmack of id Software independently discovered the algorithm in 2000 during the development of Doom 3 [3]. Since he advertised the technique to the larger public, it is often known as Carmack's Reverse.

Bilodeau and Songy assigned their patent ownership rights to Creative Labs. Creative Labs, in turn, granted id Software a license to use the invention free of charge in exchange for future support of EAX technology. [4]

[edit] Exclusive-Or

Either of the above types may be approximated with an Exclusive-Or variation, which does not deal properly with intersecting shadow volumes, but saves one rendering pass (if not fill time), and only requires a 1-bit stencil buffer. The following steps are for the depth pass version:

1. Disable writes to the depth and colour buffers.
2. Set the stencil operation to XOR on depth pass (flip on any shadow surface).
3. Render the shadow volumes.

[edit] Optimization

• One method of speeding up the shadow volume geometry calculations is to utilize existing parts of the rendering pipeline to do some of the calculation. For instance, by using homogeneous coordinates, the w-coordinate may be set to zero to extend a point to infinity. This should be accompanied by a viewing frustum that has a far clipping plane that extends to infinity in order to accommodate those points, accomplished by using a specialized projection matrix. This technique reduces the accuracy of the depth buffer slightly, but the difference is usually negligible. Please see SIGGRAPH 2002 paper Practical and Robust Stenciled Shadow Volumes for Hardware-Accelerated Rendering, C. Everitt and M. Kilgard, for a detailed implementation.

• Rasterization time of the shadow volumes can be reduced by using an in-hardware scissor test to limit the shadows to a specific onscreen rectangle.

• NVIDIA has implemented a hardware capability called the depth bounds test that is designed to remove parts of shadow volumes that do not affect the visible scene. (This has been available since the GeForce FX 5900 model.) A discussion of this capability and its use with shadow volumes was presented at the Game Developers Conference in 2005. [5]

• Since the depth-fail method only offers an advantage over depth-pass in the special case where the eye is within a shadow volume, it is preferable to check for this case, and use depth-pass wherever possible. This avoids both the unnecessary back-capping (and the associated rasterization) for cases where depth-fail is unnecessary, as well as the problem of appropriately front-capping for special cases of depth-pass.

[edit] See also

• Silhouette edge
• Shadow mapping, an alternative shadowing algorithm
• Stencil buffer
• Depth buffer
• List of software patents

[edit] External links

• The Theory of Stencil Shadow Volumes
• The Mechanics of Robust Stencil Shadows
• An Introduction to Stencil Shadow Volumes
• Shadow Mapping and Shadow Volumes
• Stenciled Shadow Volumes in OpenGL
• Volume shadow tutorial
• Fast shadow volumes at NVIDIA
• Robust shadow volumes at NVIDIA
• Advanced Stencil Shadow and Penumbral Wedge Rendering

[edit] Regarding depth-fail patents

• "Creative Pressures id Software With Patents". Slashdot (July 28, 2004). Retrieved on 2006-05-16.
• "Creative patents Carmack's reverse". The Tech Report (July 29, 2004). Retrieved on 2006-05-16.
• "Creative gives background to Doom III shadow story". The Inquirer (July 29, 2004). Retrieved on 2006-05-16.

[edit] References

This unofficial AutoCAD history site is a service to fellow users and trivia aficionados.

This site includes detailed command and system variables that have changed with each release and even some screen shots of old release material.

Regards,
Shaan Hurley
shaan.hurley@autodesk.com

AutoCAD DWG Version History by Release for the past 20+ years
The first six bytes of a DWG file identify its version. In a DXF file, the AutoCAD version number is specified in the header section. The DXF system variable is $ACADVER.

AutoCAD 2008 can read DWG files back from AutoCAD version 2.0 released in 1984.

OpenGL Vertex Buffer Object (VBO)

Related Topics: Vertex Array, Display List, Pixel Buffer Object
Download: vbo.zip, vboSimple.zip

• Creating VBO
• Drawing VBO
• Updating VBO
• Example

GL_ARB_vertex_buffer_object extension is intended to enhance the performance of OpenGL by providing the benefits of vertex array and display list, while avoiding downsides of their implementations. Vertex buffer object (VBO) allows vertex array data to be stored in high-performance graphics memory on the server side and promotes efficient data transfer. If the buffer object is used to store pixel data, it is called Pixel Buffer Object (PBO).

Using vertex array can reduce the number of function calls and redundant usage of the shared vertices. However, the disadvantage of vertex array is that vertex array functions are in the client state and the data in the arrays must be re-sent to the server each time when it is referenced.

On the other hand, display list is server side function, so it does not suffer from overhead of data transfer. But, once a display list is compiled, the data in the display list cannot be modified.

Vertex buffer object (VBO) creates "buffer objects" for vertex attributes in high-performance memory on the server side and provides same access functions to reference the arrays, which are used in vertex arrays, such as glVertexPointer(), glNormalPointer(), glTexCoordPointer(), etc.

The memory manager in vertex buffer object will put the buffer objects into the best place of memory based on user's hints: "target" and "usage" mode. Therefore, the memory manager can optimize the buffers by balancing between 3 kinds of memory: system, AGP and video memory.

Unlike display lists, the data in vertex buffer object can be read and updated by mapping the buffer into client's memory space.

Another important advantage of VBO is sharing the buffer objects with many clients, like display lists and textures. Since VBO is on the server's side, multiple clients will be able to access the same buffer with the corresponding identifier.

Creating VBO

Creating a VBO requires 3 steps;

1. Generate a new buffer object with glGenBuffersARB().
2. Bind the buffer object with glBindBufferARB().
3. Copy vertex data to the buffer object with glBufferDataARB().

glGenBuffersARB()

glGenBuffersARB() creates buffer objects and returns the identifiers of the buffer objects. It requires 2 parameters: the first one is the number of buffer objects to create, and the second parameter is the address of a GLuint variable or array to store a single ID or multiple IDs.

glBindBufferARB()

Once the buffer object has been created, we need to hook the buffer object with the corresponding ID before using the buffer object. glBindBufferARB() takes 2 parameters: target and ID.

Target is a hint to tell VBO whether this buffer object will store vertex array data or index array data: GL_ARRAY_BUFFER_ARB, or GL_ELEMENT_ARRAY_BUFFER_ARB. Any vertex attributes, such as vertex coordinates, texture coordinates, normals and color component arrays should use GL_ARRAY_BUFFER_ARB. Index array which is used for glDraw[Range]Elements() should be tied with GL_ELEMENT_ARRAY_BUFFER_ARB. Note that this target flag assists VBO to decide the most efficient locations of buffer objects, for example, some systems may prefer indices in AGP or system memory, and vertices in video memory.

Once glBindBufferARB() is first called, VBO initializes the buffer with a zero-sized memory buffer and set the initial VBO states, such as usage and access properties.

glBufferDataARB()

You can copy the data into the buffer object with glBufferDataARB() when the buffer has been initialized.

Again, the first parameter, target would be GL_ARRAY_BUFFER_ARB or GL_ELEMENT_ARRAY_BUFFER_ARB. Size is the number of bytes of data to transfer. The third parameter is the pointer to the array of source data. If data is NULL pointer, then VBO reserves only memory space with the given data size. The last parameter, "usage" flag is another performance hint for VBO to provide how the buffer object is going to be used: static, dynamic or stream, and read, copy or draw.

VBO specifies 9 enumerated values for usage flags;

GL_STATIC_DRAW_ARB
GL_STATIC_READ_ARB
GL_STATIC_COPY_ARB
GL_DYNAMIC_DRAW_ARB
GL_DYNAMIC_READ_ARB
GL_DYNAMIC_COPY_ARB
GL_STREAM_DRAW_ARB
GL_STREAM_READ_ARB
GL_STREAM_COPY_ARB

"Static" means the data in VBO will not be changed (specified once and used many times), "dynamic" means the data will be changed frequently (specified and used repeatedly), and "stream" means the data will be changed every frame (specified once and used once). "Draw" means the data will be sent to GPU in order to draw (application to GL), "read" means the data will be read by the client's application (GL to application), and "copy" means the data will be used both drawing and reading (GL to GL).

Note that only draw token is useful for VBO, and copy and read token will be become meaningful only for pixel/frame buffer object (PBO or FBO).

VBO memory manager will choose the best memory places for the buffer object based on these usage flags, for example, GL_STATIC_DRAW_ARB and GL_STREAM_DRAW_ARB may use video memory, and GL_DYNAMIC_DRAW_ARB may use AGP memory. Any _READ_ related buffers would be fine in system or AGP memory because the data should be easy to access.

glBufferSubDataARB()

Like glBufferDataARB(), glBufferSubDataARB() is used to copy data into VBO, but it only replaces a range of data into the existing buffer, starting from the given offset. (The total size of the buffer must be set by glBufferDataARB() before using glBufferSubDataARB().)

glDeleteBuffersARB()

You can delete a single VBO or multiple VBOs with glDeleteBuffersARB() if they are not used anymore. After a buffer object is deleted, its contents will be lost.

The following code is an example of creating a single VBO for vertex coordinates. Notice that you can delete the memory allocation for vertex array in your application after you copy data into VBO.

GLuint vboId;                              // ID of VBO
GLfloat* vertices = new GLfloat[vCount*3]; // create vertex array
...
// generate a new VBO and get the associated ID
glGenBuffersARB(1, &vboId);
// bind VBO in order to use
glBindBufferARB(GL_ARRAY_BUFFER_ARB, vboId);
// upload data to VBO
glBufferDataARB(GL_ARRAY_BUFFER_ARB, dataSize, vertices, GL_STATIC_DRAW_ARB);
// it is safe to delete after copying data to VBO
delete [] vertices;
...
// delete VBO when program terminated
glDeleteBuffersARB(1, &vboId);

Drawing VBO

Because VBO sits on top of the existing vertex array implementation, rendering VBO is almost same as using vertex array. Only difference is that the pointer to the vertex array is now as an offset into a currently bound buffer object. Therefore, no additional APIs are required to draw a VBO except glBindBufferARB().

// bind VBOs for vertex array and index array
glBindBufferARB(GL_ARRAY_BUFFER_ARB, vboId1);         // for vertex coordinates
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, vboId2); // for indices
// do same as vertex array except pointer
glEnableClientState(GL_VERTEX_ARRAY);                 // activate vertex coords array
glVertexPointer(3, GL_FLOAT, 0, 0);                   // last param is offset, not ptr
// draw 6 quads using offset of index array
glDrawElements(GL_QUADS, 24, GL_UNSIGNED_BYTE, 0);
glDisableClientState(GL_VERTEX_ARRAY);                // deactivate vertex array
// bind with 0, so, switch back to normal pointer operation
glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0);

Binding the buffer object with 0 switchs off VBO operation. It is a good idea to turn VBO off after use, so normal vertex array operations with absolute pointers will be re-activated.

Updating VBO

The advantage of VBO over display list is the client can read and modify the buffer object data, but display list cannot. The simplest method of updating VBO is copying again new data into the bound VBO with glBufferDataARB() or glBufferSubDataARB(). For this case, your application should have a valid vertex array all the time in your application. That means that you must always have 2 copies of vertex data: one in your application and the other in VBO.

The other way to modify buffer object is to map the buffer object into client's memory, and the client can update data with the pointer to the mapped buffer. The following describes how to map VBO into client's memory and how to access the mapped data.

glMapBufferARB()

VBO provides glMapBufferARB() in order to map the buffer object into client's memory.

If OpenGL is able to map the buffer object into client's address space, glMapBufferARB() returns the pointer to the buffer. Otherwise it returns NULL.

The first parameter, target is mentioned earlier at glBindBufferARB() and the second parameter, access flag specifies what to do with the mapped data: read, write or both.

GL_READ_ONLY_ARB
GL_WRITE_ONLY_ARB
GL_READ_WRITE_ARB

Note that glMapBufferARB() causes a synchronizing issue. If GPU is still working with the buffer object, glMapBufferARB() will not return until GPU finishes its job with the corresponding buffer object.

To avoid waiting (idle), you can call first glBufferDataARB() with NULL pointer, then call glMapBufferARB(). In this case, the previous data will be discarded and glMapBufferARB() returns a new allocated pointer immediately even if GPU is still working with the previous data.

However, this method is valid only if you want to update entire data set because you discard the previous data. If you want to change only portion of data or to read data, you better not release the previous data.

glUnmapBufferARB()

After modifying the data of VBO, it must be unmapped the buffer object from the client's memory. glUnmapBufferARB() returns GL_TRUE if success. When it returns GL_FALSE, the contents of VBO become corrupted while the buffer was mapped. The corruption results from screen resolution change or window system specific events. In this case, the data must be resubmitted.

Here is a sample code to modify VBO with mapping method.

// bind then map the VBO
glBindBufferARB(GL_ARRAY_BUFFER_ARB, vboId);
float* ptr = (float*)glMapBufferARB(GL_ARRAY_BUFFER_ARB, GL_WRITE_ONLY_ARB);
// if the pointer is valid(mapped), update VBO
if(ptr)
{
updateMyVBO(ptr, ...);                 // modify buffer data
glUnmapBufferARB(GL_ARRAY_BUFFER_ARB); // unmap it after use
}
// you can draw the updated VBO
...

Example

This demo application makes a VBO wobbling in and out along normals. It maps a VBO and updates its vertices every frame with the pointer to the mapped buffer. You can compare the performace with a traditional vertex array implementation.

It uses 2 vertex buffers; one for both vertex coords and normals, and the other stores index array only.

Download the source and binary: vbo.zip, vboSimple.zip.

vboSimple is a very simple example to draw a cube using VBO and Vertex Array. You can easily see what is common and what is different between VBO and VA.

I also include a makefile (Makefile.linux) for linux system in src folder, so you can build an executable on your linux box, for example:

OpenGL Vertex Array

Related Topics: Vertex Buffer Object, Display List
Download: vertexArray.zip

Instead you specify individual vertex data in immediate mode (between glBegin() and glEnd() pairs), you can store vertex data in a set of arrays including vertex coordinates, normals, texture coordinates and color information. And you can draw geometric primitives by dereferencing the array elements with array indices.

Take a look the following code to draw a cube with immediate mode.

Each face needs 4 times of glVertex*() calls to make a quad, for example, the quad at front is v0-v1-v2-v3. A cube has 6 faces, so the total number of glVertex*() calls is 24. If you also specify normals and colors to the corresponding vertices, the number of function calls increases to 3 times more; 24 of glColor*() and 24 of glNormal*().

The other thing that you should notice is the vertex "v0" is shared with 3 adjacent polygons; front, right and up face. In immediate mode, you have to provide the shared vertex 3 times, once for each face as shown in the code.

glBegin(GL_QUADS);      // draw a cube with 6 quads
glVertex3fv(v0);    // front face
glVertex3fv(v1);
glVertex3fv(v2);
glVertex3fv(v3);
glVertex3fv(v0);    // right face
glVertex3fv(v3);
glVertex3fv(v4);
glVertex3fv(v5);
glVertex3fv(v0);    // up face
glVertex3fv(v5);
glVertex3fv(v6);
glVertex3fv(v1);
...                 // draw other 3 faces
glEnd();

Using vertex arrays reduces the number of function calls and redundant usage of shared vertices. Therefore, you may increase the performance of rendering. Here, 3 different OpenGL functions are explained to use vertex arrays; glDrawArrays(), glDrawElements() and glDrawRangeElements(). Although, better approach is using vertex buffer objects (VBO) or display lists.

Initialization

OpenGL provides glEnableClientState() and glDisableClientState() functions to activate and deactivate 6 different types of arrays. Plus, there are 6 functions to specify the exact positions(addresses) of arrays, so, OpenGL can access the arrays in your application.

• glVertexPointer():  specify pointer to vertex coords array
• glNormalPointer():  specify pointer to normal array
• glColorPointer():  specify pointer to RGB color array
• glIndexPointer():  specify pointer to indexed color array
• glTexCoordPointer():  specify pointer to texture cords array
• glEdgeFlagPointer():  specify pointer to edge flag array

Each specifying function requires different parameters. Please look at OpenGL function manuals. Edge flags are used to mark whether the vertex is on the boundary edge or not. Hence, the only edges where edge flags are on will be visible if glPolygonMode() is set with GL_LINE.

Notice that vertex arrays are located in your application(system memory), which is on the client side. And, OpenGL on the server side gets access to them. That is why there are distinctive commands for vertex array; glEnableClientState() and glDisableClientState() instead of using glEnable() and glDisable().

glDrawArrays()

glDrawArrays() reads vertex data from the enabled arrays by marching straight through the array without skipping or hopping. Because glDrawArrays() does not allows hopping around the vertex arrays, you still have to repeat the shared vertices once per face.

glDrawArrays() takes 3 arguments. The first thing is the primitive type. The second parameter is the starting offset of the array. The last parameter is the number of vertices to pass to rendering pipeline of OpenGL.
For above example to draw a cube, the first parameter is GL_QUADS, the second is 0, which means starting from beginning of the array. And the last parameter is 24: a cube requires 6 faces and each face needs 4 vertices to build a quad, 6 × 4 = 24.

GLfloat vertices[] = {...}; // 24 of vertex coords
...
// activate and specify pointer to vertex array
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
// draw a cube
glDrawArrays(GL_QUADS, 0, 24);
// deactivate vertex arrays after drawing
glDisableClientState(GL_VERTEX_ARRAY);

As a result of using glDrawArrays(), you can replace 24 glVertex*() calls with a single glDrawArrays() call. However, we still need to duplicate the shared vertices, so the number of vertices defined in the array is still 24 instead of 8. glDrawElements() is the solution to reduce the number of vertices in the array, so it allows transferring less data to OpenGL.

glDrawElements()

glDrawElements() draws a sequence of primitives by hopping around vertex arrays with the associated array indices. It reduces both the number of function calls and the number of vertices to transfer. Furthermore, OpenGL may cache the recently processed vertices and reuse them without resending the same vertices into vertex transform pipeline multiple times.

glDrawElements() requires 4 parameters. The first one is the type of primitive, the second is the number of indices of index array, the third is data type of index array and the last parameter is the address of index array. In this example, the parameters are, GL_QUADS, 24, GL_UNSIGNED_BYTE and indices respectively.

GLfloat vertices[] = {...};     // 8 of vertex coords
GLubyte indices[] = {0,1,2,3,   // 24 of indices
0,3,4,5,
0,5,6,1,
1,6,7,2,
7,4,3,2,
4,7,6,5};
...
// activate and specify pointer to vertex array
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
// draw a cube
glDrawElements(GL_QUADS, 24, GL_UNSIGNED_BYTE, indices);
// deactivate vertex arrays after drawing
glDisableClientState(GL_VERTEX_ARRAY);

The size of vertex coordinates array is now 8, which is exactly same number of vertices in the cube without any redundant entries.

Note that the data type of index array is GLubyte instead of GLuint or GLushort. It should be the smallest data type that can fit maximum index number in order to reduce the size of index array, otherwise, it may cause performance drop due to the size of index array. Since the vertex array contains 8 vertices, GLubyte is enough to store all indices.

Different normals at shared vertex

Another thing you should consider is the normal vectors at the shared vertices. If the normals of the adjacent polygons at a shared vertex are all different, then normal vectors should be specified as many as the number of faces, once for each face.

For example, the vertex v0 is shared with the front, right and up face, but, the normals cannot be shared at v0. The normal of the front face is n0, the right face normal is n1 and the up face is n2. For this situation, the normal is not the same at a shared vertex, the vertex cannot be defined only once in vertex array any more. It must be defined multiple times in the array for vertex coordinates in order to match the same amount of elements in the normal array. See the actual implementation in the example code.

glDrawRangeElements()

Like glDrawElements(), glDrawRangeElements() is also good for hopping around vertex array. However, glDrawRangeElements() has two more parameters (start and end index) to specify a range of vertices to be prefetched. By adding this restriction of a range, OpenGL may be able to obtain only limited amount of vertex array data prior to rendering, and may increase performance.

The additional parameters in glDrawRangeElements() are start and end index, then OpenGL prefetches a limited amount of vertices from these values: end - start + 1. And the values in index array must lie in between start and end index. Note that not all vertices in range (start, end) must be referenced. But, if you specify a sparsely used range, it causes unnecessary process for many unused vertices in that range.

GLfloat vertices[] = {...};     // 8 of vertex coords
GLubyte indices[] = {0,1,2,3,   // 24 of indices
0,3,4,5,
0,5,6,1,
1,6,7,2,
7,4,3,2,
4,7,6,5};
...
// activate and specify pointer to vertex array
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);
// draw first half, range is 6 - 0 + 1 = 7 vertices
glDrawRangeElements(GL_QUADS, 0, 6, 12, GL_UNSIGNED_BYTE, indices);
// draw second half, range is 7 - 1 + 1 = 7 vertices
glDrawRangeElements(GL_QUADS, 1, 7, 12, GL_UNSIGNED_BYTE, indices+12);
// deactivate vertex arrays after drawing
glDisableClientState(GL_VERTEX_ARRAY);

You can find out maximum number of vertices to be prefetched and the maximum number of indices to be referenced by using glGetIntegerv() with GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES.

Note that glDrawRangeElements() is available OpenGL version 1.2 or greater.

Example

This demo application renders a cube with 4 different ways; immediate mode, glDrawArrays(), glDrawElements() and glDrawRangeElements().

Download the source and binary: vertexArray.zip.

In order to run this program properly, video card must support OpenGL v1.2 or greater because of glDrawRangeElements(). Make sure your video driver supports version 1.2 or higher with glinfo.

OpenGL Rendering Pipeline

OpenGL Pipeline has a series of processing stages in order. Two graphical information, vertex-based data and pixel-based data, are processed through the pipeline, combined together then written into the frame buffer. Notice that OpenGL can send the processed data back to your application. (See the grey colour lines)

OpenGL Pipeline

Display List

Display list is a group of OpenGL commands that have been stored (compiled) for later execution. All data, geometry (vertex) and pixel data, can be stored in a display list. It may improve performance since commands and data are cached in a display list. When OpenGL program runs on the network, you can reduce data transmission over the network by using display list. Since display lists are part of server state and reside on the server machine, the client machine needs to send commands and data only once to server's display list. (See more details in Display List.)
 

Vertex Operation

Each vertex and normal coordinates are transformed by GL_MODELVIEW matrix (from object coordinates to eye coordinates). Also, if lighting is enabled, the lighting calculation per vertex is performed using the transformed vertex and normal data. This lighting calculation updates new color of the vertex. (See more details in Transformation)
 

Primitive Assembly

After vertex operation, the primitives (point, line, and polygon) are transformed once again by projection matrix then clipped by viewing volume clipping planes; from eye coordinates to clip coordinates. After that, perspective division by w occurs and viewport transform is applied in order to map 3D scene to window space coordinates. Last thing to do in Primitive Assembly is culling test if culling is enabled.
 

Pixel Transfer Operation

After the pixels from client's memory are unpacked(read), the data are performed scaling, bias, mapping and clamping. These operations are called Pixel Transfer Operation. The transferred data are either stored in texture memory or rasterized directly to fragments.
 

Texture Memory

Texture images are loaded into texture memory to be applied onto geometric objects.
 

Raterization

Rasterization is the conversion of both geometric and pixel data into fragment. Fragments are a rectangular array containing color, depth, line width, point size and antialiasing calculations (GL_POINT_SMOOTH, GL_LINE_SMOOTH, GL_POLYGON_SMOOTH). If shading mode is GL_FILL, then the interior pixels (area) of polygon will be filled at this stage. Each fragment corresponds to a pixel in the frame buffer.
 

Fragment Operation

It is the last process to convert fragments to pixels onto frame buffer. The first process in this stage is texel generation; A texture element is generated from texture memory and it is applied to the each fragment. Then fog calculations are applied. After that, there are several fragment tests follow in order; Scissor Test ⇒ Alpha Test ⇒ Stencil Test ⇒ Depth Test.
Finally, blending, dithering, logical operation and masking by bitmask are performed and actual pixel data are stored in frame buffer.
 

Feedback

OpenGL can return most of current states and information through glGet*() and glIsEnabled() commands. Further more, you can read a rectangular area of pixel data from frame buffer using glReadPixels(), and get fully transformed vertex data using glRenderMode(GL_FEEDBACK). glCopyPixels() does not return pixel data to the specified system memory, but copy them back to the another frame buffer, for example, from front buffer to back buffer.

See more detail here how to extract vertex data from OpenGL pipeline.

From Wikipedia, the free encyclopedia

COLLADA is a COLLAborative Design Activity for establishing an interchange file format for interactive 3D applications.

COLLADA defines an open standard XML schema for exchanging digital assets among various graphics software applications that might otherwise store their assets in incompatible formats. COLLADA documents that describe digital assets are XML files, usually identified with a .dae (digital asset exchange) filename extension.

[edit] History

Originally created by Sony Computer Entertainment as the official format for PlayStation 3 and PlayStation Portable development, it has since become the property of the Khronos Group, a member-funded industry consortium, which now shares the copyright with Sony. Several graphics companies collaborated with Sony from COLLADA's beginnings to create a tool that would be useful to the widest possible audience, and COLLADA continues to evolve through the efforts of the Khronos contributors. Early collaborators included Alias Systems Corporation, Criterion Software, Autodesk, Inc., and Avid Technology. Dozens of commercial game studios and game engines have adopted the standard.

[edit] Tools and compatibility

COLLADA was intended originally as an intermediate format for transporting data from one digital content creation (DCC) tool to another. Applications exist to support that usage for several DCCs, including Maya (using ColladaMaya); 3ds Max (using ColladaMax); LightWave 3D (version 9.5); Maxon|Cinema 4D R11; Softimage|XSI; Side Effect's Houdini; MeshLab; SketchUp, Blender and modo. COLLADA .dae files can be used in Adobe Photoshop software since version CS3. Game engines, such as Unreal engine, have also adopted this format.

Two open-source utility libraries are available to simplify the import and export of COLLADA documents: the COLLADA DOM and the FCollada library. The COLLADA DOM is generated at compile-time from the COLLADA schema. It provides a low-level interface that eliminates the need for hand-written parsing routines, but is limited to reading and writing only one version of COLLADA, making it difficult to upgrade as new versions are released. In contrast, Feeling Software's FCollada provides a higher-level interface and can import all versions of COLLADA. FCollada is used in ColladaMaya, ColladaMax and several commercial game engines.

However, some applications have adopted COLLADA as their native format or as one variety of native input rather than simply using it as an intermediate format. Google Earth (release 4) has adopted COLLADA (1.4) as its native format for describing the objects populating the earth. Users can simply drag and drop a COLLADA (.dae) file on top of the virtual Earth. Alternatively, Google SketchUp can also be used to create .kmz files, a zip file containing a KML file, a COLLADA (.dae) file, and all the texture images.

[edit] COLLADA Physics

As of version 1.4, physics support was added to the COLLADA standard. The goal is to allow content creators to define various physical attributes in visual scenes. For example, one can define surface material properties such as friction. Furthermore, content creators can define the physical attributes for the objects in the scene. This is done by defining the rigid bodies that should be linked to the visual representations. More features include support for ragdolls, collision volumes, physical constraints between physical objects, and global physical properties such as gravitation.

Physics middleware products that support this standard include Bullet Physics Library, Open Dynamics Engine, PAL, nVidia's PhysX and Algoryx's AgX Multi Physics. These products support by reading the abstract found in the COLLADA file and transferring it into a form that the middleware can support and represent in a physical simulation. This also enables different middleware and tools to exchange physics data in a standardized manner.

The Physics Abstraction Layer provides support for COLLADA Physics to multiple physics engines that do not natively provide COLLADA support including JigLib, OpenTissue, Tokamak physics engine and True Axis. PAL also provides support for COLLADA to physics engines that also feature a native interface.

[edit] Versions

• 1.0: October 2004
• 1.2: February 2005
• 1.3: June 2005
• 1.4.0: January 2006; added features such as character skinning and morph targets, rigid body dynamics, support for OpenGL ES materials, and shader effects for multiple shading languages including the Cg programming language, GLSL, and HLSL. First release through Khronos.
• 1.4.1: July 2006; primarily a patch release.

[edit] See also

• U3D
• X3D / VRML
• 3DMLW (3D Markup Language for Web)
• List of vector graphics markup languages
• PAL XML physics format

[edit] External links

• Official homepage
• Forum
• COLLADA book
• COLLADA DOM, COLLADA RT, and COLLADA FX libraries are on sourceforge
• Bullet Physics Library - First open source rigid body dynamics simulator with COLLADA Physics import
• C++ Data Binding for COLLADA
• ColladaLoader. An open source application to load and visualize COLLADA files in real time using OpenGL.

Moving Image Resources:

虽然网上商店形式多样,每个站点有自己的特色,但也有其一般的共性,单就"商品的变化,以便及时通知订户"这一点,是很多网上商店共有的模式,这一模式类似Observer patern观察者模式.

具体的说,如果网上商店中商品在名称 价格等方面有变化,如果系统能自动通知会员,将是网上商店区别传统商店的一大特色.这就需要在商品product中加入Observer这样角色,以便product细节发生变化时,Observer能自动观察到这种变化,并能进行及时的update或notify动作.

Java的API还为为我们提供现成的Observer接口Java.util.Observer.我们只要直接使用它就可以.

我们必须extends Java.util.Observer才能真正使用它:
1.提供Add/Delete observer的方法;
2.提供通知(notisfy) 所有observer的方法;

我们注意到,在product类中 的setXXX方法中,我们设置了 notify(通知)方法, 当Jsp表单调用setXXX(如何调用见我的另外一篇文章),实际上就触发了notisfyObservers方法,这将通知相应观察者应该采取行动了.

下面看看这些观察者的代码,他们究竟采取了什么行动:

Jsp中我们可以来正式执行这段观察者程序:

执行改Jsp程序,会出现一个表单录入界面, 需要输入产品名称 产品价格, 点按Submit后,还是执行该jsp的
if (request.getParameter("save")!=null)之间的代码.


由于这里使用了数据javabeans的自动赋值概念,实际程序自动执行了setName setPrice语句.你会在服务器控制台中发现下面信息::

NameObserver :name changet to ?????(Jsp表单中输入的产品名称)

PriceObserver :price changet to ???(Jsp表单中输入的产品价格);

这说明观察者已经在行动了.!!
同时你会在执行jsp的浏览器端得到信息:

产品数据变动 保存! 并已经自动通知客户

上文由于使用jsp概念,隐含很多自动动作,现将调用观察者的Java代码写如下:

你会在发现下面信息::

NameObserver :name changet to 橘子红了

PriceObserver :price changet to 9.22

这说明观察者在行动了.!!

更多相关话题讨论