Setting Up a Unified GLSL Program

The OpenGL Shading Language (GLSL) is designed specifically for use within the OpenGL environment. It provides programmable alternatives to certain parts of the fixed functionality of OpenGL.

Softimage’s GLSLProgram shader provides a unified shader model where both the vertex and fragment shaders can be coded as one “entity”. In other words, a single GLSL Program node contains both the vertex and pixel shaders. As long as your code is valid and the vertex program calls the fragment program properly, then no further connections in the render tree are required to allow for communication between the two shader types.

In addition, you can specify draw operations such as blending, alpha testing, and point sprites directly within the GLSL Program node. There is no need to connect an OGL Draw shader in the render tree to perform any of these functions.

Connecting a GLSL Program Shader

1. Select the polygon mesh or the point cloud for which you want to create the realtime effect.

2. With the object still selected, open the render tree (press 7).

3. From the preset manager, drag and drop the RealTime > OpenGL > GLSL Program node onto the render tree workspace.

4. Connect the GLSLProgram node to the Material node’s RealTime input. For details on how to build render trees in general, see Connecting Shader Nodes.

 

5. Double-click the GLSLProgram node to open its property editor.

Program Options

6. Click the Program tab and set the Build options for your GLSL program.

7. You can see compilation results by activating the Debug messages option.

Compilation results are logged and available from the script editor’s log window. To open the script editor, click the script icon at the bottom of the Softimage interface.

 

 

8. Enter the vertex and pixel program code in the appropriately labeled text editors. You can also load one of the preset shaders available from the Presets tab. For information about using the text editor, see GLSL Vertex Program and Fragment Program.

 

Draw Options

9. Click the Draw tab where you can enable the integrated draw operations that you require for your effect. If needed, set the following options:

- Blending options.

- Alpha Testing options.

- Particle Cloud (point sprites) option.

Uniform and Sampler Setup in the Render Tree

 

Uniform variables: You must set the values for each uniform variable declared in your vertex and fragment shaders. In the render tree connect a GLSLUniform node into one of the GLSLProgram node’s previous input ports. Each uniform variable you declare in your code needs a GLSLUniform node connected in the render tree.

Samplers: If your program declares a sampler (for example, sampler2D) as a uniform variable, you need to connect an OGL13Texture node into one of the GLSLProgram node’s previous input ports. Each texture sampler you declare in your code needs an OGL13Texture node connected in the render tree in order to access each texture map. For more information about working with textures in realtime shader trees, see OpenGL Texture Setup.

Advanced Options for Hardware Attribute-to-Register Mapping

The hardware attribute mapping table on the Advanced tab of the GLSL Program shader allows you to select any 0D component, including any ICE attribute, that exists (or can be created) on a mesh or point cloud and pass it into any available hardware register.

 

Hardware registers are named according to the type of data they typically hold. For example, texture coordinates are usually mapped to a texcoord[n] hardware register. However, there are no hard and fast rules that restrict you to these standard mappings. If your shader needs an input to a register, let's say color0 or texcoord0, you are free to connect any available attribute into either register. This means that you can map a texture projection to a color register or a vertex color to a texcoord register (it’s as you wish). For more information, see Register Mapping Information [Shader Reference].

To map an attribute to a register

1. Click an entry in the Attribute column of the mapping table and select a vertex attribute from the drop-down list.

2. Click the adjacent entry in the Hardware Register column of the mapping table and select a hardware register from the drop-down list.

3. Each row in the table defines an attribute-to-register mapping. For more information about working with the mapping table, see Hardware Attribute Mapping [Shader Reference].

Attribute Mapping with tspace_id

When a material is shared by several objects, an attached shader with texture projections is said to have shader instance data. The instance data allows you to specify to the shader which texture projection to use for each object that shares the material.

You can write shader code that can reference the instance data value directly by specifying the name of the tspace_id parameter between brackets as [MyRTSNodeThatHasATexture.tspace_id]. Conveniently, the GLSLProgram node’s hardware attribute mapping table lists the tspace_id as an attribute when it is present in the current realtime shader tree.

For example, in a shader tree that looks like this...

 

And a hardware attribute mapping table that looks like this...

 

The GLSLProgram shader references the tspace_id of the OGLTexture shader and maps whatever texture projection is specified in that tspace_id to a texture coordinates hardware register named texcoord0.xyz.

Example 1

// Example of a custom realtime shader that uses hardcoded hardware mapping
extern "C" RTSHADER_API XSI_RTS_Attribute* MyNormalMapShader_GetAttributeList
(
   IRTSExecutionState  *in_pExecState,
   MyNormalMapParameters_t  *in_pParams,
   void    **io_pInstanceData
)
{
// This shader needs vertex position and normals and 1 texture projection.
// The texture projection must be an existing parameter
// attached to the shader tree. In this example, the parameter
//called ‘OGLTexture.tspace_id’
   char * l_szNormalShaderDataNeeded = "PointPosition,position.xyz,PointNormal,normal.xyz,[OGLTexture.tspace_id],texcoord0.xyz";
// The RTS 3.0 architecture expects an array of XSI_RTS_Attributes, you can use the
// GetAttributeDescriptorFromMapping API provided by the ExecutionState to create this structure for you.
   XSI_RTS_Attribute* dataNeeded = in_pExecState->GetAttributeDescriptorFromMapping ( l_szNormalShaderDataNeeded  );
   return dataNeeded;
}

Example 2

// Example of a custom realtime shader that uses ui-assisted hardware mapping
XSI_RTS_Attribute g_MyNormalMapShader_HardCoded_Attributes[] =
{
   XSI_RTS_ATTRIBUTE_POSITION,  ePOSITION,
   "PointNormal",    eNORMAL,
   "Texture_Projection",   eTEXCOORD0,
   0,     eMAX_STANDARD_VERTEX_ATTRIBUTE
};
extern "C" RTSHADER_API XSI_RTS_Attribute* MyNormalMapShader_GetAttributeList
(
   IRTSExecutionState  *in_pExecState,
   MyNormalMapParameters_t  *in_pParams,
   void    **io_pInstanceData
)
{
// A parameter on the PPG drives which attributes are needed to execute the shader
   if ( in_pParams->MyShaderTechnique == HighRes )
   {
   return in_pExecState->GetAttributeDescriptorFromMapping ( in_pParams->MyHardwareMappingWidget );
   } else{
   return g_MyNormalMapShader_HardCoded_Attributes;
   }
}


Autodesk Softimage v.7.5