1Name 2 3 EXT_draw_range_elements 4 5Name Strings 6 7 GL_EXT_draw_range_elements 8 9Version 10 11 $Date: 1997/5/19 12 13Number 14 15 112 16 17Proposal: 18Add a new vertex array rendering command: 19 20void glDrawRangeElementsEXT( 21 GLenum mode, 22 GLuint start, 23 GLuint end, 24 GLsizei count, 25 GLenum type, 26 const void *indices 27); 28 29Add two implementation-dependent limits for describing data size 30recommendations for glDrawRangeElementsEXT: 31 32GL_MAX_ELEMENTS_VERTICES_EXT 0x80E8 33GL_MAX_ELEMENTS_INDICES_EXT 0x80E9 34 35glDrawRangeElementsEXT is a restricted form of glDrawElements. All 36vertices referenced by indices must lie between start and end inclusive. 37Not all vertices between start and end must be referenced, however 38unreferenced vertices may be sent through some of the vertex pipeline 39before being discarded, reducing performance from what could be achieved 40by an optimal index set. Index values which lie outside the range will 41cause implementation-dependent results. 42 43glDrawRangeElementsEXT may also be further constrained to only operate 44at maximum performance for limited amounts of data. Implementations may 45advertise recommended maximum amounts of vertex and index data using the 46GL_MAX_ELEMENTS_VERTICES_EXT and GL_MAX_ELEMENTS_INDICES_EXT enumerants. 47If a particular call to glDrawRangeElementsEXT has (end-start+1) greater 48than GL_MAX_ELEMENTS_VERTICES_EXT or if count is greater than 49GL_MAX_ELEMENTS_INDICES_EXT then the implementation may be forced to 50process the data less efficiently than it could have with less data. An 51implementation which has no effective limits can advertise the maximum 52integer value for the two enumerants. An implementation must always 53process a glDrawRangeElementsEXT call with valid parameters regardless 54of the amount of data passed in the call. 55 56GL_INVALID_VALUE will be returned if end is less than start. Other 57errors are as for glDrawElements. 58 59Motivation: 60Rendering primitives from indexed vertex lists is a fairly common 61graphics operation, particularly in modeling applications such as VRML 62viewers. OpenGL 1.1 added support for the glDrawElements API to allow 63rendering of primitives by indexing vertex array data. 64 65The specification of glDrawElements does not allow optimal performance 66for some OpenGL implementations, however. In particular, it has no 67restrictions on the number of indices given, the number of unique 68vertices referenced nor a direct indication of the set of unique 69vertices referenced by the given indices. This forces some OpenGL 70implementations to walk the index data given, building up a separate 71list of unique vertex references for later use in the pipeline. 72Additionally, since some OpenGL implementations have internal 73limitations on how many vertices they can deal with simultaneously the 74unbounded nature of glDrawElements requires the implementation to be 75prepared to segment the input data and do multiple passes. These 76preprocessing steps can consume a significant amount of time. 77 78Such preprocessing can be done once and stored when building display 79lists but this only works for objects whose geometry does not change. 80Applications using morphing objects or other objects that are changing 81dynamically cannot take advantage of display lists and so must pay the 82preprocessing penalty on every redraw. 83 84glDrawRangeElementsEXT is designed to avoid the preprocessing steps 85which may be necessary for glDrawElements. As such it does not have the 86flexibility of glDrawElements but it is sufficiently functional for a 87large class of applications to benefit from its use. 88glDrawRangeElementsEXT enhances glDrawElements in two ways: 891. The set of unique vertices referenced by the indices is explicitly 90indicated via the start and end parameters, removing the necessity to 91determine this through examination of the index data. The 92implementation is given a contiguous chunk of vertex data that it can 93immediately begin streaming through the vertex pipeline. 942. Recommended limits on the amount of data to be processed can be 95indicated by the implementation through GL_MAX_ELEMENTS_VERTICES_EXT and 96GL_MAX_ELEMENTS_INDICES_EXT. If an application respects these limits it 97removes the need to split the incoming data into multiple chunks since 98the maximums can be set to the optimal values for the implementation to 99handle in one pass. 100 101The first restriction isn't particularly onerous for applications since 102they can always call glDrawElements in the case where they cannot or do 103not know whether they can call glDrawRangeElementsEXT. Performance 104should be at least as good as it was calling glDrawElements alone. The 105second point isn't really a restriction as glDrawRangeElementsEXT 106doesn't fail if the data size limits are exceeded. 107 108OpenGL implementation effort is also minimal. For implementations where 109glDrawElements performance is not affected by preprocessing 110glDrawRangeElementsEXT can be implemented simply as a call to 111glDrawElements and the maximums set to the maximum integer value. For 112the case where glDrawElements is doing non-trivial preprocessing there 113is probably already an underlying routine that takes consecutive, nicely 114sectioned index and vertex chunks that glDrawRangeElementsEXT can plug 115directly in to. 116 117Design Decisions: 118The idea of providing a set of vertex indices along with a set of 119element indices was considered but dropped as it still may require some 120preprocessing, although there is some reduction in overhead from 121glDrawElements. The implementation may require internal vertex data to 122be contiguous, in which case a gather operation would have to be 123performed with the vertex index list before vertex data could be 124processed. It is expected that most apps will keep vertex data for 125particular elements packed consecutively anyway so the added flexibility 126of a vertex index list would potentially impose overhead with little 127expected benefit. In the case where a vertex index list really is 128necessary to avoid performance penalties due to sparse vertex usage 129glDrawElements should provide performance similar to what such an API 130would have. 131 132The restriction on maximum data size cannot easily be lifted without 133potential performance implications. For implementations which have an 134internal maximum vertex buffer size it would be necessary to break up 135large data sets into multiple chunks. Splitting indexed data requires 136walking the indices and gathering those that fall within particular 137chunks into sets for processing, a time-consuming operation. Splitting 138the indices themselves is easier but still requires some processing to 139handle connected primitives that cross a split. 140