|
|
|
For binding vertex attributes to the shader, the vertex attribute names as defined in the ARB_vertex_program specification must be used. It is (currently) not possible to use names for these attribute bindings defined by the ATTRIB statement in the shader itself. The same applies to names defined for program parameter registers using the PARAM statement. So when setting program parameters, you must use the syntax "vertex.position" and similar for vertex attributes, "program.local[]" for program local parameters, and "program.env[]" for program environment parameters. Note that the multiple item notation defined in the ARB_vertex_program specification is not allowed, so trying to call ShaderProgram::SetParameter with something like "program.env[0..3]" will fail. To set a 4x4 matrix to program parameter registers 0 to 3, use "program.env[0]" and call the overload of SetParameter that accepts a Matrix4x4 parameter. Note that when using ARB_vertex_program shaders with vertex shaders in other shading languages/execution environments in a single application, it cannot be guaranteed that the program environment parameters actually remain unmodified in between vertex shader calls.
ARB_vertex_program offers a state tracking mechanism that is built into the shading language itself. It is advisable to prefer this mechanism to the TrackParameter mechanism of XEngine, as the former is done directly in the driver whereas TrackParameter will simply copy XEngine state to program parameter registers.
When using ARB_vertex_program shaders with any XEngine renderer, it does not make sense to use the following state variables, because XEngine does not modify and/or use the corresponding OpenGL state:
If an ARB_vertex_program shader nevertheless tracks states for back faces, front facing states will be tracked instead in the DirectX renderer. If an ARB_vertex_program shader tracks one of the not supported matrix states, such as state.matrix.program[n], an identity matrix will be tracked instead. The state.texgen[n].* states will be tracked using the OpenGL default values, which are (1, 0, 0, 0) for s, (0, 1, 0, 0) for t, and (0, 0, 0, 0) for r and q. The state.point.size state will be tracked as (1, 0, implementation-dependent maximum point size, 1). The state.point.attenuation state will be tracked as (1, 0, 0, 1).
It is also important to note that tracking state.light[n].position and state.light[n].half behaves slightly differently in the OpenGL and the Direct3D renderers. In the OpenGL renderers both states are tracked as described in the ARB_vertex_program specification. In the Direct3D renerers, however, the position P_pli (the light position as specified via glLight(GL_POSITION, ...)) used to compute the values of both tracked states is always the eye-space light position and not the pseudo-eye-space position computed at the time when glLight was called as in OpenGL.
Furthermore the vertex.weight, vertex.weight[n], and vertex.matrixindex[n] vertex attributes are not supported and must not be used. If vertex.weight or vertex.weight[0] are used nevertheless, they will be mapped to the generic vertex attribute 1, as described in the ARB_vertex_program specification. The other vertex attributes mentioned above will yield an exception.
Also writing the result.color.back, result.color.back.primary, and result.color.back.secondary result registers doesn't make sense when not using a programmable fragment shader in conjunction with the vertex shader, as the fixed-function pipeline in XEngine does not support back-facing polygons. If a shader uses the above mentioned result registers nevertheless, an exception is thrown.
When using the DirectX renderers, some restrictions are imposed on the shaders:
|
Copyright © by Martin Ecker |