Writing mental ray shaders: Simplest Diffuse!

Intro 

Back to the basics. The function for lambertian reflectance is

source: wikipedia

Basically, final result equals the dot product of light normal(L) and surface normal(N), multiply by diffuse color(C), multiply by color of light(IL). I'll write the simplest diffuse shader that doesn't get into light loops and getting light information. 

MI Source

declare shader
 color "jc_simple_diffuse" (
  color "diffuse" default 1 1 1,
  vector "light_dir" default 0 0 0)
 version 1
 apply material
end declare

C Source

#include "shader.h"

DLLEXPORT

struct jc_simple_diffuse {
 miColor diffuse;
 miVector lightdir;
 };

DLLEXPORT

int jc_simple_diffuse_version(void) {return(1);}

DLLEXPORT

miBoolean jc_simple_diffuse(
 miColor *result,
 miState *state,
 struct jc_simple_diffuse *params) {

 miScalar dot_nl;

 miColor *diff = mi_eval_color(&params->diffuse);
 miVector *dir = mi_eval_vector(&params->lightdir);
 dot_nl = -mi_vector_dot(&state->normal, dir);
 result->r = diff->r * dot_nl;
 result->g = diff->g * dot_nl;
 result->b = diff->b * dot_nl;
 result->a = 1.0;
 
 return(miTRUE);
 }

Conclusions

The only inputs are diffuse color and a light vector. Inputing -1 -1 -1 in light direction gives it a light looking like in fig 1.

Fig 1: simple diffuse

Fig 2: simple diffuse attribute editor

Since light dir is expressed as vectors, by connecting transforms of x, y, z to Light Dir we can change the light direction of this particular diffuse shader.

Fig 3: demo 01

In fig 3, I connected the translation of xyz of a cube to the light dir, as well as created a direction light and aim constraint it to the cube to better illustrate. When I move the cube.z to 1, the light points left.

Fig 4: demo 02

In fig 4, when i move the cube.z to 5, the falloff becomes really harsh. This is due to dot product of the surface normal and light dir becoming smaller and smaller as the light dir moves further away.

Fig 5: demo 03

In fig 5, basic 45 degree angle light. Harsh falloff could be fixed by normalizing light dir to unit vectors.

Writing mental ray shaders: UV Chooser

Intro
Here is a shader that loads a texture, and chooses which UV set to use. There's an equivalent node in Maya, but it requires setting the input values in hypershade, which isn't intuitive for the avg user. In 3ds max the same thing is set with UV channels. Multi texture layering is an important technique when dealing repetitive textures, by using 5 1k textures, i can create a better looking texture than a single 5k texture. Not sure why maya is making it so hard for avg users.

MI Source

declare shader
 color "uv_chooser" (
  color texture "tex",
  integer "uv_sets"
 )
apply material
end declare

C Source

#include "shader.h"

struct uv_chooser{
 miTag tex;
 miInteger uv_sets;
 };

miBoolean uv_chooser(miColor *result, miState *state, struct uv_chooser *params) {
 miTag tex = *mi_eval_tag(&params->tex);
 miInteger uv_sets = *mi_eval_integer(&params->uv_sets);
 int i = uv_sets;
 mi_lookup_color_texture(result, state, tex, &state->tex_list[i]);
 return miTRUE;
 }

 

Writing mental ray shaders: Mosaic Tiles

Introduction

Here is a little something thats detours from the book. Combining quantization and texture uv, I can create a mosaic effect. 

Methodology

1. Have an input texture

2. quantize the uv_coordinates

3. use the quantized_uv_coordinates inside mi_lookup_texture_color

From top to bottom: Original, tile = 20, tile = 10, Porn?!

Writing mental ray shaders: Texture Mapping

Introduction
Once we have UV coordinates, we can start mapping textures according to these coordinates. This section will introduce the use of miTAG, and the function mi_lookup_color_texture(). I'll create a node thats similar in function to the 2d_placement node in Maya. Key functions are, UV offsets, and  UV scaling.


Notes

Name	Arguments	Comments
mi_lookup_color_texture	*col, *state, tag, *v	Return the value in a color texture at a given coordinate.

The tag is assumed to be a texture as taken from a color texture parameter of a shader. This function checks whether the tag refers to a shader (procedural texture) or an image (file texture or byte stream), depending on which type of color texture statement was used in the .mi file. If tag is a shader, coord is stored in state→tex, the referenced texture shader is called, and its return value is returned. If tag is an image, coord is brought into the range (0…1, 0…1) by removing the integer part, the image is looked up at the resulting 2D coordinate, and miTRUE is returned. If the texture has been marked for filtering, like with the filter keyword in the .mi file, then multi-level pyramid filtering is performed, a procedure derived from classical mip-map textures. In both cases, the color resulting from the lookup is stored in *color.

Writing mental ray shaders: Quantization Part II

Intro

Here I will combine my two previous posts into one shader, the uv_as_colors_banding shader. I'll implement the rounding function as demonstrated in the wikipedia article. I did not understand some of the source code from the book

Methodology

1. Implement uv as colors

2. Define u_count, which is the amount of banding in the u direction

3. Define v_count, which is the amount of banding in the v direction

4. Implement the quantize function. 

Writing mental ray shaders: UV as Colors

Introduction
Here, we'll start working with UV's. We'll first look at the state variable, tex_list. I will first use tex_list in a shader that translates tex_list into the red and green component of result. In the next section I will combine the quantization function into the uv as colors shader. As I'm no expert in programming, my codes will be a little simpler, but hopefully easier to understand.

Definition

state->tex_list is a pointer to an array containing the texture coordinates of the intersection point in all texture spaces. 

Writing mental ray shaders: Transparency

Introduction
By definition, transparency is the physical property of allowing light to pass through a material. So, before I start, we need to examine this function.

miBoolean mi_trace_transparent(
 miColor  *result,
 miState  *state)

From Mental Ray online manual

This function casts a ray from state→dir to direction. It returns miFALSE if the trace depth has been exhausted or if the hit object has disabled refraction receiving. If no intersection is found, the optional environment shader is called. It also works when ray tracing is turned off, and considers visible as well as trace objects. 

From Writing mental ray® Shaders,

The API library function mi_trace_transparent sends a ray in the same direction and stores the resulting color in result. Note that this is a potentially recursive shader call—if the ray strikes another instance with a material that contains this transparency shader, then mi_trace_transparent will be called in it, and so on.

Final Image

For instance, lets examine the final test image I made. We're sending out an eye ray it hits the blue plane at point P. It calls the trace function, the function sends out a ray in the same direction as the eye ray, and hits the green plane, it calls the trace function again, and hits the red plane . It will call the function until trace depth is exhausted. It should be noted, setting trace depth in Maya is not enough, you need to set refraction depth as well.

Writing mental ray shaders: Set Range Utility

Goal

Make and/or improve on the set range utility found in maya. 

Methodology

1. Given an oldmin and oldmax, find the range by oldmax - oldmin.

2. Given an newmin and newmin, find the range by newmax - newmin.

3. For a given point P, find the range of P by P - oldmin.

4. Find the current_factor by (Step3/Step1)

5. Find the new_factor by (Step4 * Step2) + newmin

Writing mental ray shaders: Z Depth Part II

Introduction

In this part I'll create the set range and blend functions that can be found in maya. These functions will be a set of auxilliary functions that I can call upon, much like how the set range and blend nodes work in Maya. Again, I am working from, Writing mental ray® Shaders: A Perceptual Introduction (mental ray® Handbooks). Buy the book, its worth it :)

I'll further refine the zdepth shader, incorporating the set range and blend functions.

Goal

1. Develop a Set Range function and use as a library function

2. Develop a Blender function and use as a library function

3. Apply the above functions into the zdepth shader

Writing mental ray shaders: Z Depth Part I

Introduction
Unlike the shader demonstrated in Chapter 7 of Writing Mental Shaders, this is a camera z depth shader. The shader in the book is a world z depth shader.

Goal
A shader that displays a grey scale from near to far from the rendering camera.

Hypershade Equivalent

Zdepth shader tree

Methodology
From the shader tree above,
1. For a point P in space, from the rendering camera, find the -Z position of point P.
2.  Define a near distance and a far distance, use the rendering camera near/far clipping planes to determine, or alternately use the measure distance tool.
3. Use a set range function to remap the distance of (near to far) to 0 and 1, and assign this to a variable factor.
4. Use factor as greyscale values of a surface shader, or use factor as an blend value of a blend function(as above) to blend two colors.

Writing mental ray shaders: Normals as Colors Part II

Goal

A shader that visualizes the world space, object space, and camera space normals.

Methodology

Same as in part I, but use a switch statement with different mi_vector_**** functions.

Writing mental ray shaders: Normals as Colors Part I

Goal

A shader that visualizes the surface normal.

Methodology

1. Find the surface normal at point p
2. Assign xyz values to rgb at point p

Writing mental ray shaders: Introduction

To clarify, I am working from Andy Kopras' book

Writing mental ray® Shaders: A Perceptual Introduction (mental ray® Handbooks)

His website is, 

www.writingshaders.com

I'm blogging the excercises as a means to remember, and to have something quick and easy to refer to. It is also for the day when I have to teach these materials. I am using linux and maya2011 64 to test the shaders. 

Writing mental ray shaders: Facing Forward

Goal

A shader that provides the visual representation of facing forward, where the surface normal is 90 degrees to the camera is black, and 0 degrees to the camera is white.

Methodology

1. create a color parameter called tint

2. create a scalar variable called scale
3. assign scale the dot value product of the surface normal and camera normal
4. assign result the value of tint multiplied by scale

Mi File

declare shader
 color "facing_ratio" (
  color "tint"  default 1 1 1
 )
 apply material
end declare

C File

#include "shader.h"

struct facing_ratio {
 miColor tint;
};

DLLEXPORT
miBoolean facing_ratio (
 miColor *result, miState *state, struct facing_ratio *params ) {
 miColor *tint = mi_eval_color(&params->tint);
 miScalar scale = -state->dot_nd;
 result->r = tint->r * scale;
 result->g = tint->g * scale;
 result->b = tint->b * scale;
 result->a = 1.0;
 return miTRUE;
}

Questions

On line 10 of the C source code, 

Q. Why can't I directly assign the color of mi_eval_color() to tint?

A. mi_eval_color() or mi_eval in general, does not return color. It returns a pointer.

Q. What is it doing? 

A.  This is dereferencing, it is storing the location of mi_eval_color() at the location of tint. And hence the final value 

Q. When did tint become a pointer? Or can I convert any type to a pointer type with a "*"?

A. Any variable has an address associated with it. The * refers to the address.

Notes

1. dot_nd is a state variable that is a dot product of the surface normal and camera vector. It is found in, in the MentalRay manual - Using and Writing Shaders - State Variables - Intersection
2. mi_eval returns a pointer to the parameter value, no matter where it comes from. If the shader accessed its parameters directly, without using mi_eval, it would get garbage (such as 0 or NaN) if the parameter is assigned. More detail in the MentalRay manual - Using and Writing Shaders -  Parameter Assignment and mi_eval.
3. A refresher for pointers in C. "Practical Programming in C"

Writing mental ray shaders: Color Balance

Goal

A simple shader that combines the gain and offset shader

Methodology

1. create a color parameter called base

2. create a color parameter called gain

3. create a color parameter called offset

4. create a shader called "color_gain"

5. create a shader called "color_offset"

6. create a function where result = base * gain

7. create a function where result = result + offset

Mi File

declare shader
 color "color_balance" (
  color "base"  default 1 1 1,
  color "gain" default 1 1 1,
  color "offset" default 0 0 0,
 )
end declare

C File

#include "shader.h"

DLLEXPORT

struct color_balance {
 miColor base;
 miColor gain;
 miColor offset;
 };

DLLEXPORT

miBoolean color_balance (miColor *result, miState *state, struct color_balance *params) {
 miColor *base = mi_eval_color(&params->base);
 miColor *gain = mi_eval_color(&params->gain);
 miColor *offset = mi_eval_color(&params->offset);
 result->r = base->r * gain->r;
 result->g = base->g * gain->g;
 result->b = base->b * gain->b;
 result->r += offset->r;
 result->g += offset->g;
 result->b += offset->b;
 return miTRUE;
 }