* Various people in the Advanced Coding forum on OpenGL.org
* Ian Romanick, IBM (idr 'at' us.ibm.com)
* No known IP issues.
* $Date: 2004/07/28 08:45:00$ $Revision: 0.3$
* OpenGL 1.1 is required. This extension is written against the OpenGL 1.5 specification.
* In existing element based drawing APIs in OpenGL, changing the location of vertex data can be an expensive operation. GL_ARB_vertex_buffer_objects potentially makes this operation even more expensive. Since lots of vertex data can be packed into a single vertex array or vertex buffer object, meshes with the same topology can avoid this expense by reusing the same element data with a different base element for each draw call. The API in this extension provides the ability for applications to do that. This extension came from a discussion on the Advanced Coding forum on OpenGL.org. <a href="http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012219">http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012219</a>
1. Is MESAX_array_element_base the right name for this extension? The name choice and the choice of enum and function names was based on the EXT_compiled_vertex_array extension. * YES. Nobody seems to have a better name, and nobody seems to object to the current name. 1. Should !ArrayElementBaseMESAX calls be compiled into display lists? * YES. The functionality does not seem very useful, but it is consistent with the rest of the API. 1. Should there be a separate element base for each vertex array target? It may be useful to use a different set of position and normal data for each mesh, but keep the same texture coordinate data, for example. * NO. Having a per-array base isn't really any different than resetting the pointer for the array. The two main optimizations possible with this extension are having a single API call and being able to use a hardware base-index "register". Having a per-array base defeats both. 1. Should this extension really be MESAX? * YES. This is experimental functionality. The resolution of issue #3 in particular may change the API radically. Not only that, ISVs may find this extension to not be useful, and it will just go away. 1. What happens when base+i overflows the range of the datatype supplied to DrawElements or DrawRangeElements? * UNRESOLVED. The current thinking is that it won't matter due to the way the extension is defined. It is defined as a modification to the behavior of ArrayElement. The type passed to ArrayElement is a signed int. Some words may need to be added to the fifth paragraph on page 25 stating that if (base+i) overflows a signed int, the behavior is undefined. 1. What happens if base+i is outside the [start, end] range passed to DrawRangeElements? * RESOLVED. No special wording is needed. The 1.5 spec is very clear, on page 27, that it is the values in the supplied array that are contrained to [start, end]. Since it specifically states that it is the values in the indices array, the base value is never taken into consideration for the range clamping. 1. Should negative base values be allowed? * NO. While this is somewhat arbitrary, it's not known how hardware with a base-index register would handle a negative value. It also seems like a negative base value would "encourage" cases where (i+base) < 0. If this extension is every promoted to a higher status, this issue may be revisited.
New Procedures and Functions
* `ArrayElementBaseMESAX( uint base );`
* Accepted by the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev, or GetBooleanv: * `ARRAY_ELEMENT_BASE_MESAX 0xXXXXX`
Additions to Chapter 2 of the OpenGL 1.5 Specification (OpenGL Operation)
* - (2.8, p. 25) Third paragraph changed to: "The n<sup>th</sup> element of every enabled array is transferred to the GL by calling: * `void ArrayElement(int i);` For each enabled array, it is as though the corresponding command from section 2.7 or section 2.6.2 were called with a pointer to element n. n is the sum of i and the current value of ARRAY_ELEMENT_BASE_MESAX...." - (2.8, p. 25) Fifth paragraph changed to:
"Specifying i < 0, even if the sum of i and ARRAY_ELEMENT_BASE_MESAX is >= 0, results in undefined behavior. Generating the error INVALID_VALUE is recommended in this case."
- (2.8, p. 25) After the fifth paragraph insert: "The base element of all vertex arrays is set by calling:
void ArrayElementBase(int i);
Specifying i < 0 generates the error INVALID_VALUE."
Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)
Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment Operations)
Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions)
Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State Requests)
Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)
Additions to the AGL/GLX/WGL Specifications
Interactions with EXT_draw_range_elements
* All functions whose operation is defined in terms of ArrayElement calls are implicitly and automatically affected by this extension. This includes but is not limited to DrawArrays, DrawElements, DrawRangeElements, MultiDrawArrays, MultiDrawElements, !MultiModeDrawArraysIBM, and !MultiModeDrawElementsIBM.
* Modified State in Table 6.6 (p. 232): <table class="mointable"> <tr> <td>Get Value </td> <td>Get Command </td> <td>Type </td> <td>Initial Value </td> <td>Description </td> <td>Section </td> <td>Attribute</td> </tr> <tr> <td>ARRAY_ELEMENT_BASE_MESAX </td> <td>GetIntegerv </td> <td>Z+ </td> <td>0 </td> <td>Base array element index </td> <td>2.8 </td> <td>vertex-array</td> </tr>
New Implementation Dependent State
* <table class="mointable"> <tr> <td>2004/07/26 </td> <td>0.1 </td> <td>idr </td> <td>Initial draft version.</td> </tr> <tr> <td>2004/07/27 </td> <td>0.2 </td> <td>idr </td> <td>Added issues #5 and #6. Added initial contributors list.</td> </tr> <tr> <td>2004/07/28 </td> <td>0.3 </td> <td>idr </td> <td>Added issue #7. Fixed the wording of issue #2. Resolved issues #1 and #3.</td> </tr>