Universal converter for platform independent procedural shaders in X3D

Each of the three currently available real time shading languages has limitations. The Microsoft HLSL (high level shading language) is Microsoft Windows specific. The NVIDIA Cg shading language is claimed to be platform independent, however our experimental testing results indicated that none of the ATI 9000 level cards could fully support the programs in the Cg toolkit browser [nVidia 2002]. That means we can't say that Cg is really a platform independent shading language. It is still unclear whether OpenGL Shading Language (GLSL) [Rost 2004] can achieve platform independence since it is only supported by a few graphics cards at this point. Until all shading languages achieve platform independence, there is a need to convert shaders in one language to another. Even after this point, the owners of older versions of GPUs will still need a bridge to connect to the newer shader format, especially when they try to publish their shaders on the Internet or load the other version shaders on their graphics card.In this talk, we propose a XML based Universal Converter (UC) for shaders. X3D is defined in XML and the X3D shader group [Carvalho et al. 2003] is working on a shader standard. Thus, we chose to use an XML shader format as the middle layer for the conversion between different shader languages (Figure 1.), so that it will be compatible with any new X3D standard. The UC design, shading languages mapping, difficulties we faced during the implementation and partial implementation results will be discussed.An example of converting a simple vertex shader in GLSL to XML to Cg vertex shader format and vice versa will be presented. The first step is to look at the two corresponding shading languages data-type mapping, structure mapping, qualifier mapping, attribute/semantics mapping, built-in functions mapping, and texture lookup functions mapping. In the presentation we will present mapping tables illustrating these.From looking at the mapping table, it will be apparent that it is not hard to implement the data type conversions. For example, vect2/ vect3/ vect4 and matrix2/ matrix3/ matrix4 in GLSL correspond to the float2/ float3/ float4 and float2x2/ float3x3/ float 4x4 in Cg respectively. We convert ivect/bvect in GLSL to vect type in Cg. That means the middle layer XML will employ the more general data type during parsing.Another issue is mapping attributes in GLSL corresponding to the semantics in Cg. For example, when we parse a structure like: "float4 position: POSITION" in Cg, we need to convert it to a corresponding GLSL built-in attribute "gl_vertex" which is already predefined in GLSL.Some standard library functions in the source language do not have counterparts in the target language. We solve this problem by implementing the "missing" functions using existing functions in the target language. For example,float4 lighting = lit(diffuse, specular, 32); II in Cg would be converted to the following code in GLSL:vec4 lighting; II in OpenGL shading languagelighting.x = 1.0;lighting.y = max(diffuse, 0.0);lighting.z = min(diffuse, speclar);if (lighting. z < 0)lighting.z = 0.0;elselighting.z = pow (speclar, 32);lighting.w = 1.0;There are two difficulties during implementation. One is the predefined uniform issue. Some uniform variables in GLSL are built-in variables. However in Cg, this uniform variable wouldn't be defined until the API commands call the shaders and send the variable. This will cause some problems with unknown variables. Another issue is that branching statements, like for loop, are used with different scope by GLSL and Cg.Please refer to the mapping tables for the GLSL-Cg languages mapping in APPENDIX A. APPENDIX B shows an example of converting of Cg -- xml -- GLSL and GLSL -- xml -- Cg as well as the middle layer XML format for the same shader.