Texture Sampler Types

A comparison of sampler type objects is done for Cg, HLSL and GLSL. The sampler type “sampler2DShadow” is specified in GLSL, which similarly done in Cg and HLSL by the sampler type “sample2D”. However in Cg the sampler type

“samplerRECT” for video temporary support, has no matching sampler type. We will use sample2D to represent this two dimension multi-frames data. The texture sampler types in XML are listed in the first column of Table 3.5. Its matching types in Cg/HLSL/GLSL are listed in the remaining columns.

Table 3 - 5 X3D, XML and shading languages Sampler type mapping table

XML Cg HLSL GLSL

sampler1D sampler1D sampler1D sampler1D

sampler2D sampler2D sampler2D sampler2D

sampler3D sampler3D sampler3D sampler3D

samplerCUBE samplerCUBE samplerCUBE samplerCube samplerRECT samplerRECT samplerRECT No-support

sampler1D sampler1D sampler1D sampler1DShadow

Sampler2D Sampler2D Sampler2D sampler2DShadow

3.2.2.3 Qualifiers / Modifiers

The meaning of “uniform” in Cg is not same as it is in Renderman. In Renderman, the uniform modifier indicates those values that are constants over the surface. In Cg, a “uniform” qualifier variable obtains its initial value externally, for example from the main program. In Cg, all variables are changeable unless its qualifier is

“const”. In GLSL, “uniform” qualifier variables are changed at most once per primitive vertex and they pass user defined states from the application to both shaders. The “attribute” qualifier variable is typically changed per vertex. Because there is no attribute qualifier in Cg, both “attribute” and “uniform” are mapped as uniform. In HLSL, vertex and pixel shaders have two types of input data, “varying” and “uniform”. The varying input is the data that is unique to each execution of a shader. For a vertex shader, the varying data (i.e. position, normal, etc.) comes from the vertex streams. The uniform data (i.e. material color, world transform, etc.) is constant for multiple executions of a shader.

Another important qualifier in GLSL is “varying”. The “varying” variable passes information from the vertex shader to the fragment shader. In Cg, this task is done to some variables with the modifiers, “IN”, “OUT” or “INOUT”. We will give an example to explain how to convert the “IN/OUT” with “varying” in the later implementation section.

We choose “const”, “uniform”, “IN/OUT” as the middle XML layer qualifier. Please refer following mapping table 3.6.

Table 3 - 6 X3D, XML and shading languages basic Qualifiers mapping table

XML Cg HLSL GLSL

const Const uniform uniform

uniform Uniform varying attribute

In, out, inout In, out, inout In, out, inout varying

3.2.2.3 Transformation Matrixes Parameters in Cg/HLSL vs. Build in Matrixes in GLSL

The conventional arrangement of transformations used to position process vertex positions. The Transformation Matrices in both languages Cg and GLSL are doing the same task. Let’s look at the Figure 3.9 borrowed from Cg tutorial book as following. This graph illustrates

In GLSL, there is a set of built-in uniform transformation matrices that are responsible for vertex transformation. For example, “gl_ModelViewMatrix” takes care of the modeling and viewing transformation. If object vertices in the object space are multiplied with “gl_ModelViewMatrix”, the coordinate of the object result in Clip space. It is same situation for

Modeling Transform View Transform Projection Transform Perspective Transform ViewPoint and Depth range transformation World Space Eye space Clip space Normalized Device Space Window space Object space

Figure 3 - 9 Coordinate System and Transformation for Vertex Processing

other “gl_” built in matrix operations. Since the matrices in Cg don’t have fixed names, they can be user defined, as long as it is named the same as it is in the main program, where the matrices were sent out, it will have no compile errors. For X3D application, we

assume we are loading the loading different shader from one main program. So, we simply use the same name as the matrices in GLSL. The following Table 3.7 gives a mapping between Cg, XML and GLSL built-in uniform matrices. XML transformation matrices named the same as the ones in GLSL.

Table 3 - 7 X3D, XML and shading languages Transformation matrix mapping table

XML Cg HLSL GLSL gl_ModelViewMat rix gl_ModelViewMat rix gl_ModelViewMat rix gl_ModelViewMat rix

gl_NormalMatrix gl_NormalMatrix gl_NormalMatrix gl_NormalMatrix gl_ModelViewPro jectionMatrix gl_ModelViewPro jectionMatrix gl_ModelViewPro jectionMatrix gl_ModelViewPro jectionMatrix

For this set of transformation matrices mapping, the program works with a condition, which is the transformation matrices are named the same as it is in the mapping table. When users use this converter, they have to clean their code with the same name as the ones we specified in table 3.7 and change their name back to the ones used in main program once after the conversion. The reason we can assume they are the same in the X3D program is that we had an assumption that these converted shader will be used in one X3D program, so the Transformation Matrix from the same X3D main program should stay the same.

3.2.2.4 Semantics in Cg/HLSL vs. Built-in Attributes and Variables in GLSL