Graphics Reference
In-Depth Information
This approach has worked for a long time with more or less success,
but for the reasons just discussed, it is not as good as it could be. The next
approach passes the original value with the vertex, rather than converting it
to a vertex color. This takes advantage of the GLSL atribute variables, which
can be atached to vertices and interpolated through the rasterizer:
glBegin( GL_QUADS );
glVertexAttrib1f( location, s0 );
glVertex3f( x0, y0, z0 );
. . .
glEnd( );
This ends up giving the fragment program the actual data values, which
can then be mapped into colors with the transfer function. Because there are
actually several diferent atribute-seting glVertexAttrib* routines, several
data values can be passed in for each vertex.
A variation on this approach is to be a litle sneaky. You can also pass the
scalar data value in with one call to glVertex4f( ):
glBegin( GL_QUADS );
glVertex4f( x0, y0, z0, s0 );
. . .
glEnd( );
Normally the fourth element of glVertex4f( ) is defined to be the homo-
geneous coordinate, w . In this case, though, we have used the fourth element
to hold the scalar value at this vertex. However, the graphics pipeline still
wants that element to be the homogeneous w when the coordinates are multi-
plied by the ModelView and Projection matrices, so the first thing we need to
do in the vertex shader is to re-assign it to a varying variable and replace the w
coordinate with something sensible:
out float vScalar;
void main( )
{
...
vScalar = aVertex.w;
gl_Position =uModelViewProjectionMatrix*vec4(aVertex.xyz, 1.);
}
Search WWH ::




Custom Search