[vtk-developers] Fwd: OpenGL shading language implementation in VTK

Will Schroeder will.schroeder at kitware.com
Mon Nov 15 20:34:34 EST 2004


Hi Mike-

There has some discussion here along similar lines partially driven by some 
VTK friends in the US National labs. What you outline is generally 
consistent with what I have heard. I think it's a great idea and a 
necessary addition. Let me follow up on this and see if we can't get the 
ball rolling.

I cc:d the vtk-developers list so others can see what the ideas are.

Will

PS - I'll be at the Brigham tomorrow (11/16) for the day.



>From: Michael Halle <mhalle at bwh.harvard.edu>
>Subject: OpenGL shading language implementation in VTK
>Date: Thu, 11 Nov 2004 19:56:03 -0500
>X-Mailer: Apple Mail (2.619)
>
>Hey gang,
>
>I've been looking at the OpenGL Shading Language (part of OpenGL 2.0)
>and supporting it as part of VTK.  I think it could be quite cool,
>very powerful, and the implementation would be very straightforward.
>
>First, for background:
>
>OpenGL 2.0, approved back in August, includes the OpenGL shading
>language (GLSL) as a component.  GLSL is a C-like language, very
>similar to NVIDIA's Cg.  ATI, 3DLabs, NVIDIA, and the rest of
>the OpenGL consortium are behind it and have implementations in
>the pipe.
>
>Here's how things work.  You have two types of programs: vertex
>shaders and fragment shaders.  You write them in GLSL, and specify
>them as a C string in your program.  You load them into OpenGL at
>your program's runtime.  You link together as many fragments as you
>need (different fragments mightcontain different functions that
>your shader uses) and create a shader program. Through OpenGL,
>you can then activate a shader program.
>
>The vertex shader program has access to three basic kinds of variables:
>const (constants), uniform (single value over all vertices),
>and varying (different per vertex).  You can declare and
>calculate these values inside your shader programs.  You can
>also load their values from inside your OpenGL program:  for
>uniform variables, you can set values by name;  for varying
>variables, you use a call similar to "glVertex()" and "glTexCoord()"
>called glVertexAttrib() to set all values for a vertex.  You
>can also get and set GL state inside the vertex shader.
>
>The fragment shader program gets variables passed in from the
>vertex processing, with each variable interpolated across the
>surface of the polygon.  The fragment shader can access texture
>memory as well as color state and position.
>
>VTK implementation
>
>A VTK shading language implementation is very natural.  PointData
>and CellData attributes can be made available to vertex programs,
>so we can use Scalar and Vector data during rendering.  This
>capability will allow all the power of VTK's processing pipeline
>with the latest rendering techniques.
>
>Implementation happens in the vtkOpenGLPolyDataMapper.  We have to
>add a couple things:  a way to set the shader programs, a way to
>get uniform and varying variables set, and the guts to do the
>implementation efficiently.
>
>1. Program:
>Vertex and fragment shader programs are stored in a
>vtkOpenGLShaderProgram  object.  Different fragments are loaded into
>the object, which is then compiled.  This object can be attached to
>one or more PolyDataMappers.
>
>2. Variables:
>Another object, vtkOpenGLShaderVariables, contains the constant
>values for the uniform variables as well as the mapping of PointData
>and CellData attribute data to varying variable names. This object can
>also be attached to one or more PolyDataMappers.
>
>examples:
>   // Set global uniform variable in shader
>   shaderVars->SetUniformVariable("NumberOfIterations", 3);
>
>   // map the "scalars" PointData field to the varying variable "temperature"
>   shaderVars->SetFieldMapping("temperature, "scalars", POINT_DATA);
>
>   // unmap a previously mapped variable
>   shaderVars->UnmapVariable("temperature")
>
>3. Implementation:
>The above two objects are straightforward.  The biggest change must
>happen inside PolyDataMapper itself.  Right now, the code is OpenGL 1.0
>compliant.  It's got a bunch of nasty special cases for handling
>multiple combinations of color, texture, normals for both point and
>cell data.
>
>OpenGL 1.1 (released around 1997) offers a great way to get around
>this mess: vertex arrays.  You specify a pointer to the beginning
>of your vertex, color, normal, vertex attribute, etc. arrays,
>along with a size and stride.  You activate the ones you want on
>for a primitive.  You use glArrayElement(i) to specify an index to
>activate (rendering one vertex + color + normal + etc. at once),
>or you use glDrawElements() to draw a whole primitive at once with
>indexing, or glDrawArrays to draw a while sequence without indexing.
>
>Vertex arrays effectively remove most of the special casing used
>in PolyDataMapper, and allow us to add vertex attributes for the
>shader programs without exploding the number of special cases in
>the file.  (A later extension, vertex buffer objects, use the
>same syntax but allow storage of data sets directly on the
>framebuffer -- later on, we might use this technique to tremendously
>increase frame rates.)  I think we'll get better performance
>out of vertex arrays anyway, and OpenGL 1.1 is pretty old now.
>
>That's about it -- not too hard, but it will take plenty of
>surgery on PolyDataMapper.  For backward compatibility, we'd
>need to either completely special case PolyDataMapper, or have
>the factory method hand back a compatible one based on an OpenGL
>inquiry.  From an implementation point of view, though, it's
>a little tricky but in general straightforward.
>
>I'm wondering what you guys think.  Anyone else working on it that
>you know of? I don't have an OpenGL2.0 compliant machine right now,
>and I wouldn't start before I did, but I think it's a pretty powerful
>idea that meshes with VTK rather well.
>
>
>--Mike





More information about the vtk-developers mailing list