Java 3D^TM 1.4: Programmable Shaders

This is the latest draft of the proposed Java 3D^TM 1.4 API changes for programmable shaders.

We have created a thread on the Java 3D discussion forum for discussing Java 3D Programmable Shaders. Feel free to post your comments on our ideas, or post some ideas of your own.

Class Hierarchy for Shader Objects

The proposed class hierarchy for programmable shaders in Java 3D is:

• Abstract shader base classes:

public abstract class ShaderProgram extends NodeComponent
public abstract class Shader extends NodeComponent

• Concrete GLSL shader classes:

public class GLSLShaderProgram extends ShaderProgram
    method: {add/remove/get}Shader(GLSLShader) // set of shader objs
    method: {add/remove}ErrorListener(GLSLErrorListener)
    method: validate(Canvas3D) ???

public abstract class GLSLShader extends Shader
    public class GLSLVertexShader extends GLSLShader
	method: set/getShaderSource(String)
	method: validate(Canvas3D) ???
    public class GLSLFragmentShader extends GLSLShader
	method: set/getShaderSource(String)
	method: validate(Canvas3D) ???

• Concrete Cg shader classes:

public class CgShaderProgram extends ShaderProgram
    method: {set/get}VertexShader(CgVertexShader)
    method: {set/get}FragmentShader(CgFramentShader)
    method: {add/remove}ErrorListener(CgErrorListener)
    method: validate(Canvas3D) ???

public abstract class CgShader extends Shader
    public class CgVertexShader extends CgShader
	method: set/getShaderSource(String)
	method: validate(Canvas3D) ???
    public class CgFragmentShader extends CgShader
	method: set/getShaderSource(String)
	method: validate(Canvas3D) ???

• New ShaderAppearance class:

public class ShaderAppearance extends Appearance
    method: set/getShaderProgram(ShaderProgram)
    method: set/getShaderAttributeSet(ShaderAttributeSet)

• New ShaderAttributeSet class:

public class ShaderAttributeSet extends NodeComponent
    method: put/get(ShaderAttribute)
    ...

Click on the following link for a current look at the javadoc-generated API definitions for the proposed 1.4 API.

Example Usage

This is an example code excerpt showing how one might use the new programmable shader API in a Java 3D program.

String vertexShaderFile = "my-vertex-shader-file-name";
String fragmentShaderFile = "my-fragment-shader-file-name";
String vertexShaderSource;
String fragmentShaderSource;

// Read GLSL vertex and fragment shader source code from text files
vertexShaderSource = StringIO.readFully(vertexShaderFile);
fragmentShaderSource = StringIO.readFully(fragmentShaderSource);

// Create GLSL vertex and fragment shader objects using the given source code
GLSLVertexShader vertexShader = new GLSLVertexShader(vertexShaderSource);
GLSLFragmentShader fragmentShader = new GLSLFragmentShader(fragmentShaderSource);

// Create the GLSL shader program object and attach the vertex and
// fragment shader objects; add an error listener
GLSLShaderProgram shaderProgram = new GLSLShaderProgram();
shaderProgram.setVertexShader(vertexShader);
shaderProgram.setFragmentShader(fragmentShader);
shaderProgram.addErrorListener(myGLSLErrorListener);

// Use GLSL shader program object in appearance
shaderAppearance.setShaderProgram(shaderProgram);

Shader Parameters

Programmable shaders define two types of parameters: uniform and varying. As the names imply, uniform parameters are constant (within a primitive), while varying parameters can vary on per-vertex or per-fragment basis.

1. Uniform parameters (attributes) are those parameters whose value is constant during the rendering of a primitive. Their values may change from primitive to primitive, but are constant for each vertex (for vertex shaders) or fragment (for fragment shaders) of a single primitive. Examples of uniform parameters include a transformation matrix, a texture map, lights, lookup tables, etc.
   
   We have created a new ShaderAttributeSet for allowing applications to specify uniform shader attributes. There are two ways in which values can be specified for uniform attributes: explicitly, by providing a value; and implicitly, by defining a binding between a Java 3D system attribute and a uniform attribute. This functionality is provided by two subclasses of ShaderAttribute: ShaderAttributeObject, which is used to specify explicitly defined attributes; and ShaderAttributeBinding, which is used to specify implicitly defined, automatically tracked attributes. See the javadoc for the new ShaderAttributeSet and ShaderAttribute classes for more details.
   
   Issues
   
   • Should j3dAttrName be specified as a type-safe enum or object instead of a String?
     • No; we will use a String
   • How do we handle passing arrays to the shader, especially for system parameters such as lights? One possibility is:
     "var" - scalar variable "var"
     "arr[0]" - array element 0 of "arr"
     "arr[1,3]" - subarray composed of elements 1 through 3 of "arr"
     "arr[]" - entire array "arr"
     
     Alternatively, an object with a string or type-safe enum, a state (scalar, array element, subarray, or entire array), and indices (as needed).
     • TBD, but since they will be String objects, we will probably do something like the first suggestion
   
   Automatic variables
   Depending on the shading language (and profile) being used, several Java 3D state attributes are automatically made available to the shader program as pre-defined uniform attributes. The application doesn't need to do anything to pass these attributes in to the shader program. The implementation of each shader language (e.g., Cg, GLSL) defines its own mapping from Java 3D attribute to uniform variable name.
   
   A partial list of Java 3D attributes that are mapped to shader attributes follows:



Java 3D Attribute	Cg shader variable	GLSL shader variable
ModelViewProjection	glstate.matrix.mvp	gl_ModelViewProjectionMatrix
Light[n] pos	glstate.light[n].position	gl_LightSource[n].position
...	...	...



2. Varying parameters are those parameters that are specified as per-vertex attributes. They are are interpolated across a primitive similarly to colors and texture coordinates in the fixed function pipeline.
   
   We need additional API to allow applications to pass in per-vertex varying parameters...
   TODO: Finish this...
   

TODO: more info here.

Page last updated — $Date$