
On Tue, 19 Oct 2004, Charles Moad wrote:
The release notes include: initial OpenGL Shading Language API support.
Do you have any documentation on how you expose this functionality, or could you offer a brief explanation on how you see it being integrated?
So everyone understands the power of the OpenGL Shading Language, OGLSL, the idea of using shaders is to provide interactive stylized images. Especially black and white images for publication, but possibly for other effects too. The attached image has a molecular surface covered with bricks using OGLSL, which has dubious scientific value, but as a proof of concept shows the power of shaders. The initial OGLSL support is exposed via chimera python scripts. Enclosed below is testshader.py which as used to produce the brick surface. Shaders fit in to the existing chimera internal dichotomy of ColorGroups amd Colors. Color groups are textures, materials, or shaders and colors are per vertex attributes for a particular color group. So for textures those attributes are texture coordinates, for materials the attributes are RGBA (the diffuse component), and for shaders the attributes are the OGLSL varying data. A shader is expected to be packaged as a directory with an XML file, shader.xml, giving meta-information about the shader and links to individual vertex and fragment shader files. Enclosed below is an example of the current version of the XML format. It may change as I learn more about OGLSL and XML. The current "shader color" is a place holder and does not set any per-vertex attributes so the shader program needs to figure out what to do from standard OpenGL pipeline data. Luckily, many of the book examples fall into this category, like the brick shader used in the attached image. Since shader programs are tightly integrated into applications, I will have to document what OpenGL state a shader may expect and should use. For example, the brick shader, that I tested with, takes a LightPosition parameter rather than use the current set of OpenGL lights. That makes for a simplier example, but effectively disables chimera's lighting interface. I would welcome alpha testers, so please speak up if you wish to participate in developing this feature. The more programming skill and OGLSL knowledge, the better initially as the work will be to write appropriate shaders and possibly modify chimera to provide computed data to shaders. And the user interface will need work too. :-) Hope this helps, Greg Couch UCSF Computer Graphics Lab gregc@cgl.ucsf.edu ------------- testshader.py ------------- import chimera import Midas Midas.open('1gcn') m = chimera.openModels.list()[0] Midas.surface('#', 'main') s = chimera.Shader_lookup('brick') sc = chimera.ShaderColor(s) m.surfaceColor = sc ----------------------------------- ~/.chimera/shaders/brick/shader.xml ----------------------------------- <?xml version="1.0" ?> <vertex_shader filename="brick.vert"/> <fragment_shader filename="brick.frag"/> <uniform name="BrickColor" type="vec3" metatype="color"> 1.0 0.3 0.2 </uniform> <uniform name="MortarColor" type="vec3" metatype="color"> 0.85 0.86 0.84 </uniform> <uniform name="BrickSize" type="vec2"> 0.30 0.15 <min> 0.0 0.0 </min> <max> 1.0 1.0 </max> </uniform> <uniform name="BrickPct" type="vec2"> 0.90 0.85 <min> 0.0 0.0 </min> <max> 1.0 1.0 </max> </uniform> <uniform name="LightPosition" type="vec3"> 0.0 0.0 4.0 <min> -10.0 -10.0 -10.0 </min> <max> 10.0 10.0 10.0 </max> </uniform>