Getting started

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.

getting_started_1.jpg

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.

getting_started_2.jpg

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.

standalone_and_applications.jpg

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