1Name 2 3 NV_texture_expand_normal 4 5Name Strings 6 7 GL_NV_texture_expand_normal 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Notice 14 15 Copyright NVIDIA Corporation, 2002. 16 17IP Status 18 19 NVIDIA Proprietary. 20 21Status 22 23 Implemented, November 2002 24 Shipping in Release 40 NVIDIA driver for CineFX hardware, January 2003. 25 26Version 27 28 Last Modified: 2005/06/16 29 NVIDIA Revision: 4 30 31Number 32 33 286 34 35Support 36 37 NVIDIA plans to discontinue this extension for future GPU 38 architectures. Support for NV3x (GeForce FX), NV4x (GeForce 6 39 Series), and G7x (GeForce 7x00) architectures will continue. 40 41 As an alternative to the EXT_texture_expand_normal functionality, 42 developers can either use the signed fixed-point texture formats 43 provided by NV_texture_shader (such as GL_SIGNED_RGBA8_NV) or perform 44 the "expand normal" operation with shader instructions (typically 45 just a MAD).. 46 47Dependencies 48 49 OpenGL 1.1 is required. 50 51Overview 52 53 This extension provides a remapping mode where unsigned texture 54 components (in the range [0,1]) can be treated as though they 55 contained signed data (in the range [-1,+1]). This allows 56 applications to easily encode signed data into unsigned texture 57 formats. 58 59 The functionality of this extension is nearly identical to the 60 EXPAND_NORMAL_NV remapping mode provided in the NV_register_combiners 61 extension, although it applies even if register combiners are used. 62 63Issues 64 65 (1) When is the remapping applied? 66 67 RESOLVED: It would be possible to remap after loading each texel, 68 remap after all filtering is done, or something in between. 69 Ignoring implementation-dependent rounding errors, it really 70 doesn't matter. 71 72 The spec language says that the remapping is applied after filtering 73 texel values within each level. For LINEAR_MIPMAP_LINEAR, this 74 means that the remapping is "done" twice. This approach was chosen 75 solely to simplify the spec language, and does not necessarily 76 reflect NVIDIA's implementation. 77 78 (2) Should the remapping mode apply to textures with signed 79 components? 80 81 RESOLVED: No -- the EXPAND_NORMAL_NV mapping is ignored for 82 such textures. 83 84 (3) NV_texture_shader provides several internal formats with a mix 85 of signed and unsigned components. For example, the base formats 86 DSDT_MAG_NV, and DSDT_MAG_INTENSITY_NV have this property, and 87 there is a variant of RGBA where the RGB components are signed, 88 but the A component is unsigned. What should happen in this case? 89 90 RESOLVED: The unsigned components are remapped; the signed 91 components are unmodified. 92 93 (4) What should be said about signed fixed-point precision and range 94 of actual implementations? 95 96 RESOLVED: The fundamental problem is that it is not possible 97 to derive a linear mapping taking unsigned values that exactly 98 represents -1.0, 0.0, and +1.0. 99 100 The mapping chosen for current NVIDIA implementations does not 101 exactly represent +1.0. For an n-bit fixed-point component, 102 0 maps to -1.0, 2^(n-1) maps to 0.0, and 2^n-1 (maximum value) 103 maps to 1.0 - 1/(2^(n-1)). This same conversion is applied to 104 stored textures using the signed texture types in NV_texture_shader. 105 106 This specification is written using the conventional OpenGL mapping 107 where -1.0 and +1.0 can be represented exactly, but 0.0 can not. 108 The specification is simpler and avoids precision-dependent language 109 describing the mapping. We expect some leeway in how the remapping 110 is applied. 111 112 This issue is discussed in more detail in the issues section 113 of the NV_texture_shader specification (the question is phrased 114 identically). 115 116 (5) Are texture border color components remapped? 117 118 RESOLVED: Yes -- if the border values are used for filtering, 119 border color components are remapped identically to normal texel 120 components. 121 122New Procedures and Functions 123 124 None. 125 126New Tokens 127 128 Accepted by the <pname> parameters of TexParameteri, 129 TexParameteriv, TexParameterf, TexParameterfv, GetTexParameteri, 130 and GetTexParameteriv: 131 132 TEXTURE_UNSIGNED_REMAP_MODE_NV 0x888F 133 134 135Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation) 136 137 None. 138 139 140Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) 141 142 Modify Section 3.8.4, Texture Parameters, p.135 143 144 (modify Table 3.19, p. 137) 145 146 Name Type Legal Values 147 ----------------- ---- ---------------------- 148 TEXTURE_UNSIGNED_ enum EXPAND_NORMAL_NV, NONE 149 REMAP_MODE_NV 150 151 152 Modify Section 3.8.8, Texture Minification, p.140 153 154 (add after the last paragraph before the "Mipmapping" subsection, 155 p. 144) 156 157 After the texture filter is applied, the filtered texture values are 158 optionally rescaled, converting unsigned texture components encoded 159 in the range [0,1] to signed values in the range [-1,+1]. If the 160 texture parameter TEXTURE_UNSIGNED_REMAP_MODE_NV is EXPAND_NORMAL_NV, 161 the filtered values for each unsigned component of the texture is 162 transformed by 163 164 tau = 2 * tau - 1. 165 166 For components 167 168Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment 169Operations and the Frame Buffer) 170 171 None. 172 173 174Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions) 175 176 None. 177 178 179Additions to Chapter 6 of the OpenGL 1.4 Specification (State and 180State Requests) 181 182 None. 183 184 185Additions to Appendix A of the OpenGL 1.4 Specification (Invariance) 186 187 None. 188 189 190Additions to the AGL/GLX/WGL Specifications 191 192 None. 193 194GLX Protocol 195 196 None. 197 198 199Errors 200 201 None. 202 203 204New State 205 206(add to table 6.15, p. 230) 207 Initial 208Get Value Type Get Command Value Description Sec. Attribute 209------------------------------ ---- ----------------- ------- ------------------ ----- --------- 210TEXTURE_UNSIGNED_REMAP_MODE_NV nxZ2 GetTexParameteriv NONE unsigned component 3.8.8 texture 211 remapping 212 213 214Revision History 215 216Rev. Date Author Changes 217---- -------- -------- -------------------------------------------- 218 4 06/14/05 mjk Add to-be-discontinued "Status" message and 219 discussion of alternatives. 220 221 3 10/07/02 pbrown Minor wording changes on precision issues -- this 222 remapping should produce roughly the same results 223 as storing the texture in signed form. 224 225 2 10/07/02 pbrown Added issue about where the remapping is applied, 226 and what happens to border colors. 227 228 1 10/07/02 pbrown Initial revision. 229