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

[Jeff Lee]

Hi Michael,
One advantage to using vertex-arrays, besides a reduction in function 
calls, is possibly a better way to point opengl directly at arrays 
already stored in vtk's data structures.  Is it correct to say that 
vtkDataArrays are already compatible with vertex array storage?  My 
guess is that all arrays stored at points would work, and only data 
stored at cells would need to be massaged to fit the vertex-array 
concept.  Once vertex-arrays are implemented, it is probably not a huge 
leap to vertex-buffer-objects.  A very welcome addition.
-Jeff

Will Schroeder wrote:

> 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
>
>
>
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>