Shading-System Download and Instructions
Please note that this system is a research system currently under development,
and as such is likely to contain bugs and other annoyances. Use at your
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.
A single zip or gzip'd tar file contains executable versions of our shading
system for Win32 (Win2K or Win98) and Linux. If unpacking under
Win32, grab the .zip file.
rtsl-2002.10.01.zip (10.6 MB)
rtsl-2002.10.01.tar.gz (10.7 MB)
Added support for NV30 compilation.
Bug fixes, especially to 'nv' fragment backend.
Changes to 'nv' fragment backend: (a) Added partial texture-shader support. (b) Signed interpolants now work automatically. (c) Bug fixes.
Added register-combiner fragment backend. [Win32-only release]
Minor language changes, updated language documentation.
Added a scene viewer plus undocumented support for bumpmaps, cubemaps, 3d
textures, and three-component vectors.
Added support for direct generation of x86 object code.
An early release of our system.
Our shading system requires:
- 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
- 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.
The tar file contains:
- 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"
- 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
- 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
- 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
- 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.
- 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
- "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.
psen at graphics stanford