[vtk-developers] GLSL shader/shaderprogram etc

[Gary J. Templet]

Hi John,

As Ken pointed out, vtkShaderProgram and vtkShader were designed to be 
agnostic as to the shader implementation. However, currently, 
vtkShaderProgram::LoadExtension() does try to load GL extensions. Your 
changes are a logical extension of the code as found in the repository.

Having said that, I think vtkShaderProgram::LoadExtension() should not 
try to load GL extensions or any api-specific settings or extensions. 
Instead, vtkShaderProgram::LoadExtensions would become a virtual or pure 
virtual function to be implemented by descendants of vtkShaderProgram.

I'd prefer to see:
- GL-specific code in vtkShaderProgram::LoadExtensions()  moved to 
vtkGLSLShaderProgram::LoadExtensions (vtkGLSLShaderProgram seem to be 
the only class to call this anyway)
- your GL 1.4/1.5 code implemented as a descendant of 
vtkGLSLShaderProgram, or in vtkGLSLShaderProgram directly.

Basically, vtkShaderProgram::LoadExtensions() is in the wrong class, IMHO.

Thoughts?

Cheers,
Gary

John Biddiscombe wrote:
> Ken
>
> Sending you files off list. If anyone else is interested, then I'll go 
> back on list.
>
> NB. ShaderProgram was modified because it has the central 
> LoadExtensions call. Other than that it is untouched.
>
> JB
>
>> John,
>>
>> I would like to see your changes before you check them in.  Your email
>> was not exactly clear, but I am assuming you mean you added code to use
>> the GL_ARB_vertex_program and GL_ARB_fragment_program extensions.  From
>> what you described, I think I would like to see some changes before that
>> code gets back into VTK.  Your description gives me two main
>> reservations.
>>
>> First, the vtkShaderProgram was meant to be agnostic to the
>> implementation of the shader.  It should not matter if the
>> implementation is Cg, GLSL, or GL_ARB_*_program.  Thus, you shouldn't
>> need to make any changes to it.  That said, we may have forgotten some
>> generic functionality that you require, for example a method to check to
>> see if the current shader is supported by hardware.  Either way, I would
>> like to see the code before it's checked in.
>>
>> Second, the intention of the vtkShaderProgram hierarchy is to have a
>> different vtkShaderProgram subclass for each shader API and method for
>> specifying shader programs.  Thus, I think a better implementation is to
>> leave vtkGLSLShaderProgram untouched and instead make a new class
>> (vtkOpenGLShaderProgram?) that implements a shader using OpenGL 1.1
>> extensions.  The VTK shader code was designed this way specifically to
>> prevent "messy" (your word, not mine) code that has to handle multiple
>> implementations with lots of conditionals.
>>
>> -Ken
>>
>>    ****      Kenneth Moreland
>>     ***      Sandia National Laboratories
>> ***********  *** *** ***  email: kmorel at sandia.gov
>> **  ***  **  phone: (505) 844-8919
>>     ***      fax:   (505) 845-0833
>>
>>
>>> -----Original Message-----
>>> From: vtk-developers-bounces+kmorel=sandia.gov at vtk.org 
>>> [mailto:vtk-developers-bounces+kmorel=sandia.gov at vtk.org] On Behalf 
>>> Of John Biddiscombe
>>> Sent: Wednesday, May 03, 2006 5:59 AM
>>> To: vtk-developers at vtk.org
>>> Subject: [vtk-developers] GLSL shader/shaderprogram etc
>>>
>>> A while back, I made some changes to my copies of 
>>> vtkShaderProgram.cxx ,vtkShaderProgram.h ,vtkGLSLShader.cxx 
>>> ,vtkGLSLShader.h ,vtkGLSLShaderProgram.cxx
>>>
>>> so that they will function without OpenGL2 but instead use Gl 
>>> Extensions (vertex program, shader program etc etc). I've been 
>>> sitting on these changes for some time in the hope I'd get time to 
>>> clean them and create some "proxy" or other delegate type object to 
>>> make them a bit less messy
>>> - they are full of if (opengl2supported) then {...} otherwise {...} 
>>> but the functionality is essentially the same for either case.
>>>
>>> I'm going to check these changes in, because I don't think I'm ever 
>>> going to find time to do a better job of it.
>>>
>>> It primarily lets on do GLSL stuff on some laptops and desktops that 
>>> don't have gl2 drivers.
>>>
>>> any objections or comments, please send...
>>>
>>> JB
>>>
>>>
>>>
>>> -- 
>>> John Biddiscombe,                            email:biddisco @ cscs.ch
>>> http://www.cscs.ch/about/BJohn.php
>>> CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
>>> Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82
>>>
>>> _______________________________________________
>>> vtk-developers mailing list
>>> vtk-developers at vtk.org
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>
>>
>
>