Proposed Shader Improvements

Overview

This document is a place to collect all proposals for shader changes/improvements/issues.

Issues

• When material is unloaded, the state of the Property may not get restored --- vtkProperty should keep an internal state of the property before the material was loaded and restore to that state when the material is unloaded.
• The XML attribute names could be a little clearer, some suggestions:

   -'ivar' refers to instance variables on vtk objects
   -'value' refers to numeric values or defined constants in the case of Cg transformation matrix settings.
   -'shader_var' refers to the name of particular hardware shader variables

   For the tags PropertyUniform, CameraUniform, LightUniform the current construction:
       <PropertyUniform value="Ambient" name="property.Ambient"> </PropertyUniform>
     would become:
       <PropertyUniform ivar="Ambient" shader_var="property.Ambient"> </PropertyUniform>

   For tages that describe values for ivars for vtkProperty:
      <Member name="DiffuseColor" value="0.85 0.05 0.15"> </Member>
    would become
      <Member ivar="DiffuseColor" value="0.85 0.05 0.15"> </Member>

• When a shader is applied to an object/actor in ParaView that object's actor controls no longer affect the object's position, opacity, etc.
• ParaView Bug: 2838The XML settings for a vtkProperty specified in a material file should be reflected in the ParaView gui elements. For example, if the material file defines a color for the object, that color should be the color seen in the ParaView 'display' tab.
• To facilitate code re-use it would be great if a subroutine could be stored as XML and added to a pre-compiled shader's text definition. A particular subroutine could be specified in shader's XML definition in the material file. The subroutine would be appended/prepended to the shader's source before it's compiled. The subroutines could be added to the library or repository similarly to the way shaders and materials re handled. This would facilitate shader development and reduce code bloat. GLSL does a similar thing by linking multiple programs, but this solution is extensible to Cg and other languages.
• Before loading a shader there should be a check to see if all it's uniform variables have been set. If not, don't load the shader, but report an error.
• Adding surface roughness to renderings requires a measure of the scale of the object. Simply having units specified in the vtkPointArrays that describe geometry should be enough for the purposes of shading, but a more general approach would be useful in other filters/algorithms in VTK and ParaView. Clearly units are important in analysis and should be carried through the post-processing and visualization:

http://www.space.com/missionlaunches/launches/orbiter_errorupd_093099.htm

• ParaView should apply texture coordinates as easily as it applies normals to surfaces. A texture coordinates filter based on vtkImplicitTextureCoords.h might work.
• Here are some intial results of using materials in ParaView with the light kit: Image:PvShaders3.jpg
• It's tempting to write everything into fragment shaders but computationally-expensive fragment shaders can severely impact performance. As a compromise a material could be implemented with multiples versions of the same techniques with the computation distributed between the fragment and vertex shaders in varying degrees (and as appropriate). Applications then selected among these shaders for speed or image quality, based on a user parameter, frame rate, phase of the moon, etc. As example use case might be to use the fastest shader (or standard GL even) when a user is rotating an object, and a more compute-intensive shader when the interaction is complete. A possible naming convention is to add to the shader tag an attribute that denotes the speed of the shader and/or quality of the image produced. Though speed is tricky here because it is strongly data dependent. Size of the executable might be a better option.

---

VTK: [Welcome | Site Map]