If you already had BMRT installed on your machine, please remove the old directory and all its contents before installing. (Or at least move it to someplace else safe.)
Right click over the "My Computer" icon and select "Properties". Go to the "Environment" tab. You'll want to add the bin directory of where you installed BMRT to your PATH variable, set the BMRTHOME variable to where you installed BMRT, and your SHADERS variable to the shaders directory of BMRT2.5.
Variable: PATH
Value:.....;C:\BMRT2.5\bin
Variable: BMRTHOME
Value: C:\BMRT2.5\
Variable: SHADERS
Value: C:\BMRT2.5\shaders
You will want to add a few items to your autoexec.bat file. You
should add BMRT2.5\bin to your
PATH, set SHADERS to
BMRT2.5\shaders, and set your BMRTHOME
to wherever you installed BMRT.
More specifically, if you installed BMRT on your C: disk at the top level, you could add the following to the bottom of your your autoexec.bat file:
set PATH=%PATH%;C:\BMRT2.5\bin
set BMRTHOME=C:\BMRT2.5\
set SHADERS=C:\BMRT2.5\shaders
In order to use the shader compiler (a.k.a. slc), you'll need to have a working version of the C PreProcessor (a.k.a. cpp) abd cygwin.dll in the directory $BMRTHOME/bin, that is, in the bin subdirectory under the place where BMRT is installed, which should be pointed to by the environment variable BMRTHOME. The cpp.exe and cygwin.dll included in BMRT2.5\bin are from the fine folks at www.cygnus.com. Be sure to also point your execution PATH to this bin directory.
One caveat: if you have a C development environment installed, such as Borland's, it might find the cpp.exe that comes with that environment. Unfortunately, the output of Borland's cpp.exe seems non-standard, so BMRT can't use it. If you run slc and you get:
slc Error: (line 1) parse error
No Code generated
That probably means slc is picking up the other cpp. You might want to zap your path right before you compile shaders to just point to bmrt's bin directory. The other problem (if you're running under Win95) is that Norton Antivirus might be interfering.
In order to use the OpenGL-based RenderMan preview renderer (a.k.a. rgl) or see framebuffer renders by rendrib, you'll need to have OpenGL installed on your system. It's obvious why rgl needs OpenGL, but rendrib needs it also because it uses OpenGL to display the output of the renderer if you choose "framebuffer" as your output type, or if you use the "-d n" flags on the command line.
Originally, we bundled Microsoft's and SGI's OpenGL DLLs with BMRT, but that seemed to cause more problems than it solved. So... we've decided that it's up to you to make sure you have OpenGL installed (which seems to be the majority of folks out there, hence our change).
If you're running WinNT 3.51 or greater, it should already be there (it's OpenGL32.DLL and GLU32.DLL in your WindowsNT\System32 directory). If you have a recent version of Win95 (OSR2 or greater) it should also be there (the DLLs will probably be in Windows\System). If you don't have it installed, Microsoft makes it available at ftp://ftp.microsoft.com/softlib/mslfiles/OPENGL95.EXE.
Finally, if you have a 3D accellerator; check your board and chip manufacturers (they're probably not the same company) for the latest OpenGL drivers - most have them these days, and they're getting pretty good. Don't worry - the MS OpenGL DLLs will pass through to the hardware if it's there.
C:\BMRT2.5 for this discussion) and making
sure the rest of your setup is correct (see above), open up a Windows
shell (a.k.a. "Command Prompt" under "Programs" in the Start Menu).
Change directories to the examples directory (you type the part in bold):
C:\> cd BMRT2.5\examples
C:\BMRT2.5\examples\>
try the OpenGL-based RIB previewer on some rib files (you type the part in bold):
C:\BMRT2.5\examples\> c:\BMRT2.5\bin\rgl teapots.rib
hit the esc key or q to close the window after it finishes rendering.
C:\BMRT2.5\examples\> c:\BMRT2.5\bin\rgl limbo.rib
try to compile some shaders (you type the part in bold):
C:\BMRT2.5\shaders\> c:\BMRT2.5\bin\slc funkyglass.sl
C:\BMRT2.5\shaders\> c:\BMRT2.5\bin\slc screen_aa.sl
C:\BMRT2.5\shaders\> c:\BMRT2.5\bin\slc screen.sl
try to render a scene using the hybrid raytracer/radiosity renderer (you type the part in bold):
C:\BMRT2.5\examples\> c:\BMRT2.5\bin\rendrib -d 16 shadtest.rib
After the renderer finishes rendering, click the title bar of the window with the image, hit the w key to write out a TIFF file of the window, and then hit the esc key or q to close the window.
If everything worked okay, you're all set!
Finally, don't forget the -d options to rendrib;
it will display the results directly to the screen. I like to use
-d 16, to see things as quickly as possible:
c:> rendrib -d 16 foo.rib
And then you can press w over the window after the renderer finishes to write out a TIFF file (esc key or q will quit and close the window).
Fully compiled shaders (i.e., using slc -dso) are currently disabled in the windows port of BMRT. I am hoping to get it working in future releases, but for now it is not available.
Currently, we're only making a VisualC++ version of the client library available. See examples/colorspheres.c for an example of a C program that uses it.
In order to preserve cross-platform compatibility of RIB files, as well as to remain compatible with PRMan, I strongly urge you to specify files and pathnames in RIB files (such as in "searchpath" options, ReadArchive calls, texture filenames, etc.) using the convenetion of forward slashes /, not the dumb windoze backslash (\) to indicate directory hierarchy, and colons : rather than semi-colons to separate items in a searchpath.
If you absolutely must use backslashes to indicate directory hierarchies, then for Pete's sake remember that just like in C source code, a single backslash modifies the next character (i.e., \t is a tab, \n is a newline, etc.), but a double backslash \\ indicates that a single backslash is really there.
Note that BMRT 2.4 did not properly handle backslashes in RIB files. In other words, a single backslash was incorrectly interpreted as a backslash, instead of the correct interpretation of being an escape sequence.
Please note that Windows (NT, at least) built-in TIFF viewer can't seem to read TIFF files that have an alpha channel, so any RIB files that have their last argument to Display as "rgba" (as opposed to "rgb") won't be able to be displayed by this lame-o piece of software. Never fear, though - BMRT is writing a valid TIFF file, and a real application (say, Adobe PhotoShop), has no problem reading it.
We've also got two reports of people having trouble compiling shaders; one was trying to compile some files remotely from a Novell mounted disk (there seems to be some weirdness with re: piping output around), and the other is more mysterious - it acts like he has another cpp in his path, but he doesn't seem to. This seems to only happen under the first version of Win95, and might be related to virus protection software - if you run into this, try turning off Norton and see if it goes away.
We're also concerned and interested in hearing people's performance experiences of this port vs. (say) the same version of BMRT on Linux on the same hardware. I've tried to do all the right things in compiling this code for Win32, but given my lack of battle-hardened Win32 experience, I would be happy to entertain well thought out suggestions about how to convince the compiler to emit better/faster code.