The good news is that mental ray shaders are written in the C or C++
programming languages. Unfortunately, the bad news is that …
mental ray shaders are written in C or C++. But let’s focus on the
good part: Since the shaders are in C or C++, everything you know
about programming in those languages, and all the libraries that
you’ve written or have acquired, can potentially be useful in mental
ray shader programming. However, the way that you compile C/C++ code
varies in its details across different operating systems, and getting
this right can be a frustrating hurdle right at the beginning. The
installation of mental ray and your custom shaders are also dependent
upon the structure of the file system. I’ve included a lot of
information in this website to deal with these issues. I hope this
page will help clarify the big picture so that you don’t get lost in
the details right off the bat.
Compiling shaders
The page “Shader compilation on various
platforms”
describes the various pieces required to compile the
shaders in the book.
The book organizes the shader code in a simple way: each shader is
almost always defined in its own file. (I say “almost always” because
contour shading is divided into four processes, each represented by a
separate shader. I’ve organized one set of related contours shaders
in a single file in Chapter
10
of the c_tessellate
shader.)
Many shaders also use utility functions from the
“miaux” library, written for the book and designed as an auxiliary set
to complement the “mi” library supplied with mental ray.
I also defined a few simple shapes as geometry shaders in file
“newblocks.cpp”. The “newblocks” shaders depend up a library of C++
classes called “mrpoly”. These classes are an initial sketch of how
you can approach geometry shaders at a higher level through class
design. The low-level C code in Chapter 19
will show you how
objects are created through the geometry API as declared in file
“geoshader.h” in the mental ray distribution.
Rendering with custom shaders
The page “Accessing custom shaders during rendering”
describes the way that you tell mental ray to look for your shaders.
The files you created when you compiled your shader source code have
an an extension of .so (Unix and OS X) or .dll (Windows) and provide
the shader’s executable code. The declaration of the shader in .mi
files describe the parameters and type of value created by the shader.
In the diagram above, there’s a dotted line from the shaders to the
scene file because the scene file tells mental ray the names of the
executable and declaration files, but mental ray actually includes the
executable shader code when it is rendering.
Customizing applications with your shaders
The rayrc file can tell mental ray where to look for your custom
shaders. Applications, like XSI, 3ds max, Houdini or Maya, provide similar
mechanism to load shaders, both the standard shaders they provide as
well as your custom ones.
Note that the diagram suggests that the same mental ray is being used
in standalone mode and through an application. You can think of
mental ray as a rendering engine that can be included in a software
framework. The software framework for mental ray standalone is a
language-based parser that reads the scene file and constructs the
database to be rendered. The applications perform the same kind of
process, but instead it is the application scene as represented
through the graphical interface that is translated into the mental ray
database.
You’ll also see that an application can typically export a file in the
.mi syntax that can be rendered with mental ray standalone. Using
standalone in this way, the normal rules still apply; mental ray needs
to find the applications shaders if you use them, so the rayrc file
will need to be augmented to include those application’s shader
directories.
19 April 2008 22:49:35