Shading-System Download and Instructions

It is likely that we will eventually publically release the source code to our shading system, but we are not yet prepared to do so.

Download

Download:

rtsl-2002.10.01.zip (10.6 MB)
rtsl-2002.10.01.tar.gz (10.7 MB)

Version History:

2002.10.01	Added support for NV30 compilation.
2001.05.25	Bug fixes, especially to 'nv' fragment backend.
2001.05.02	Changes to 'nv' fragment backend: (a) Added partial texture-shader support. (b) Signed interpolants now work automatically. (c) Bug fixes.
2001.03.22	Added register-combiner fragment backend. [Win32-only release]
2000.11.07	Minor language changes, updated language documentation.
2000.10.23	Added a scene viewer plus undocumented support for bumpmaps, cubemaps, 3d textures, and three-component vectors.
2000.07.06	Minor changes.
2000.06.29	Added support for direct generation of x86 object code.
2000.03.29	An early release of our system.

System Requirements

• OpenGL 1.1 or 1.2
  • For our register-combiner ('nv') fragment backend, recent NVIDIA drivers are required.
  • Don't forget to set color depth to 32 bits after installing a new NVIDIA driver.
• GLUT libraries (we use v3.7) -- (Download them from here).
• High-quality OpenGL hardware or software emulation.
  • Win32 PC's: On PC's, we have tested our system at various times with ATI Radeon, NVIDIA GeForce1-3, and 3dfx Voodoo5 cards. We haven't extensively tested other cards, although if they support OpenGL 1.1 well, they should work.
  • Linux PC's: Mesa or XFree86 4.0 with appropriate drivers.
  • IRIX: Our system works on most mid-range and high-end SGI systems (with IRIX 6.5)
• GNU make (plus cygwin on win32), but only if you want to build new applications that use the shading system.

Tar-File Summary

• A "viewer" program, which allows objects to be displayed using user-written shaders. Right-click to get a menu. (On Win98, older versions of GLUT have a bug that causes the menu to be nearly empty; hit the "m" key to fix this, or upgrade your GLUT DLL).
• A "scviewer" program, which allows scenes to be displayed using user-written shaders. Its use is otherwise similar to the "viewer" program.
• A file of example shaders ("shaders.in").
• Several textures which are used by the example shaders.
• Several NURBS objects which can be used by the viewer program.
• Source code and makefiles for a simple application that uses our shading system.
• A "ppmview" program for viewing the texture images. You might find this useful for viewing the .pgma and .ppma texture files, which use an extended pnm format. You have to run this program from a command shell.
• Some documentation.

Tar-File Directory Structure

• linux/ -- "viewer" and "scviewer" programs and shading-system library for Linux.
• win32/ -- "viewer" and "scviewer" programs and shading-system library for Win32. Double-click on scviewer.exe to run it.
• docs/ -- lang5.txt in this directory describes the shading language, keys.txt describes how to use the viewer, scene.txt describes our scene description language.
• scenes/ -- scenes used by the scene viewer.
• textures/ -- texture files used by the shaders in "shaders.in".
• models/ -- NURBS objects used by the viewer program.

Various notes

• Our system can use a variety of different code generators. Normally it chooses appropriate code generators automatically, but you may want to override the automatic choices. To do so, add a line "codgen XX YY ZZ" to "scviewer.in" or "viewer.in". XX is the primitive-group codegen, either "cc" or "x86". YY is the vertex codegen, either "cc", "x86", or "nv20" (NV_vertex_program). ZZ is the fragment codegen, either "lb" or "nv".
  • The "nv" codegen targets NV_register_combiners. It is never used by default, because it will fail if a shader is too complex to compile to a single rendering pass. But, it produces more efficient code and provides more capabilities than the "lb" codegen. Give it a try if you have a GeForce3. Most of the shaders in "shaders2.in" require the capabilities of the "nv" codegen.
  • If the "cc" codegen is used, our system will expect run-time access to a C compiler ("cc" under IRIX or Linux, MS Visual C++ under Win32). You might be interested in trying this to see the generated C code for primitive-group and vertex operations.
• If you set the environment variable DEBUG_VERBOSE to 2, you will see the code generated by the "nv20" vertex codegen and "nv" fragment codegen, if they are active.
• If you are trying to determine why a shader is too large to fit into a single rendering pass with the "nv" fragment codegen, try setting the fragment codegen to "nvinf" (this fakes infinitely-capable hardware) and looking at the configuration that is dumped with DEBUG_VERBOSE=2.
• "nv" fragment backend data-type issues:
  • Fragment 'clampf' types aren't actually clamped to [0,1], except when values are cast to clampf. That is, 'clampf' is treated like 'float' except during casts. We will eventually fix this, so don't rely on the current behavior.
• When using our immediate-mode API, limit the number of distinct polygon groups (sglBegin/sglEnd) as much as possible. In our current implementation, some shaders will consume considerable time for each sglBegin(); we will eventually fix this problem.
• When using our immediate-mode API, don't forget to specify normal and tangent vectors for vertices if they are required by your shader. Forgetting to specify these is a common mistake.
• Due to fundamental restrictions of current hardware, multipass shaders that produce translucent surfaces may not generate correct results.