Name OES_vertex_type_10_10_10_2 Name Strings GL_OES_vertex_type_10_10_10_2 Contributors Daniel Ginsburg Gary King Petri Kero Aaftab Munshi Acorn Pooley Mark Callow Ben Bowman Contact Aaftab Munshi (amunshi@apple.com) Notice Copyright (c) 2006-2013 The Khronos Group Inc. Copyright terms at http://www.khronos.org/registry/speccopyright.html Specification Update Policy Khronos-approved extension specifications are updated in response to issues and bugs prioritized by the Khronos OpenGL ES Working Group. For extensions which have been promoted to a core Specification, fixes will first appear in the latest version of that core Specification, and will eventually be backported to the extension document. This policy is described in more detail at https://www.khronos.org/registry/OpenGL/docs/update_policy.php IP Status None. Status Ratified by the Khronos BOP, March 20, 2008. Version Last Modified Date: July 17, 2007 Number OpenGL ES Extension #46 Dependencies This extension is written against the OpenGL ES 2.0 specification Overview This extension adds the following data formats: Two new vertex attribute data formats: a signed 10.10.10.2 and an unsigned 10.10.10.2 vertex data format. These vertex data formats describe a 3- or 4-tuple stream which can be used to store normals or other attributes in a quantized form. Normals, tangents, binormals and other vertex attributes can often be specified at reduced precision without introducing noticeable artifacts, reducing the amount of memory and memory bandwidth they consume. Issues 1. Should VertexAttrib{1234}[v] functions take UNSIGNED_INT_10_10_10_2_OES and INT_10_10_10_2_OES data formats? RESOLUTION: No. There is no reason to support this, as these functions are not performance or memory footprint critical. It is much more important that the vertex data specified using vertex arrays be able to support these new formats. In addition, we would need a new data type suffix (similar to "f" for float, "x" for fixed) to denote these two new data types which is not desirable. 2. Should unsigned 10.10.10.2 RGBA and unsigned 10.10.10 RGB texture formats be supported by this extension? RESOLUTION: No. This extension should focus on enabling 10.10.10{.2} vertex data formats. The 10.10.10{.2} texture formats should be a separate extension. New Procedures and Functions None New Tokens Accepted by the parameter of VertexAttribPointer UNSIGNED_INT_10_10_10_2_OES 0x8DF6 INT_10_10_10_2_OES 0x8DF7 Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL Operation) Modifications to section 2.8 (Vertex Arrays) Add INT_10_10_10_2_OES and UNSIGNED_INT_10_10_10_2_OES as a valid value in Table 2.4. Add a new section 2.8.1 - UNSIGNED_INT_10_10_10_2_OES and INT_10_10_10_2_OES vertex data formats UNSIGNED_INT_10_10_10_2_OES and INT_10_10_10_2_OES vertex data formats describe packed 3- or 4- component formats stored in a 32-bit word. These components are expanded to (x, y, z, 1.0) if = 3, or (x, y, z, w) if = 4. For UNSIGNED_INT_10_10_10_2_OES vertex data format, the x, y and z components are represented as a 10-bit unsigned integer value and the w component is represented as a 2-bit unsigned integer value. For INT_10_10_10_2_OES vertex data format, the x, y and z components are represented as a 10-bit signed two's complement integer value and the w component is represented as a 2-bit signed two's complement integer value. The value is used to indicate whether to normalize the data to [0, 1] (for unsigned type) or [-1, 1] (for signed type). The following figure describes how these components are laid out in a 32-bit word. 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ------------------------------------------------------------------------------------- | x | y | z | w | ------------------------------------------------------------------------------------- Calls to VertexAttribPointer with of INT_10_10_10_2_OES and UNSIGNED_INT_10_10_10_2_OES can only be made with = 3 or 4. values other than 3 or 4 will return an INVALID_VALUE error. Modifications to table 2.9 (Component conversions) Add the following entries: GLType Conversion of (x, y, z) Conversion of w ------- ---------------------- =============== INT_10_10_10_2_OES (2c + 1)/(2^10 - 1) (2c + 1)/(2^2 - 1) UNSIGNED_10_10_10_2_OES c / (2^10 - 1) c / (2^2 - 1) Errors The error INVALID_VALUE is generated if glVertexAttribPointer is called with = UNSIGNED_INT_10_10_10_2_OES or INT_10_10_10_2_OES and the parameter is not set to 3 or 4. New State None Revision History March 2, 2006 Aaftab Munshi First draft of extension. March 3, 2006 Aaftab Munshi Changed DEC3N, UDEC3N to INT_10_10_10_2 and UNSIGNED_INT_10_10_10_2 resp. use parameter to mark whether data is to be normalized or not. Changed extension name to GL_ATI_vertex_type_10_10_10_2 Changed error returned from INVALID_ENUM to INVALID_VALUE if != 3 March 3, 2006 Aaftab Munshi Added Contributors section. April 10,2006 Aaftab Munshi Support for *_10_10_10_2 as a texture format June 3, 2006 Aaftab Munshi Renamed to use OES suffixes. June 14, 2006 Aaftab Munshi Allow 10_10_10_2 to be (x,y,z,1) or (x,y,z,w) when used as a vertex attribute data format. Oct 20, 2006 Aaftab Munshi Fixed errors to say 3- or 4- tuples instead of just 3- tuples. Jun 13, 2007 Aaftab Munshi Removed 10.10.10{.2} texture formats. Jul 10, 2007 Aaftab Munshi Clarified that each component is a signed 2's complement integer or unsigned integer value. Shorten the extension name from OES_vertex_data_type_10_10_10_2. Jul 17, 2007 Aaftab Munshi Corrections to section 2.8