djx blog

In the "Introduction to Mentalray" section of the maya documentation I read this:

The Phenomenon concept provides the missing framework for the completion of the definition of a scene for the purpose of rendering in a unified manner.

It inspired me to find out more about this concept and to see if I could do something useful with it.

A phenomenon is a mentalray shader network that has been exported in a special format that allows it to appear like a custom shader as a single node with its own interface.

I conceived a simple task as a practical way of exploring how to create a phenomenon. My aim would be to take one of the mentalray Data Conversion shaders called mib_color_mix and give it a make-over so people will find it easier to use.

Click here to read the full article describing the steps I took to achieve my aim.

(more...)

A while ago I learned from one of "Zaps Mentalray Tips" that the mia_physicalsky haze parameter could be used to make clouds in the sky by connecting a file texture to it. Since then I have experimented with this technique and discovered some limitations and some solutions to those limitations.

(more...)

Depending on how you currently start your maya renders, this tip may save you some render time.

If you launch renders using the command-line (either directly or via a render manager application) then you will already know about the various cmd-line flags that can be used to control various aspects of the render.

For a while now I have been using the command "render -r file" to tell the render to use which ever renderer (usually mentalray or software) I have specified inside the scene file. This is especially convenient when, because of render layers, I'm using both these renderers in the one scene.

Today I made an interesting discovery. If I instead use "render -r mr" to tell the renderer specifically to use mentalray then my render times decreased significantly, in this case, dropping from just over 5 mins per frame to approximately 3 mins per frame.

I know these differences will probably vary depending on the content of the scenes. And I know that being specific about the renderer will require some extra thought when different render layers may use different renderers, but the time saving is sure to make it worth the effort.

This is a mini tutorial on using the visibility distance parameter of the mia_physicalsky shader.

Most people probably add mia_physicalsky to their scenes using the create button in the environment tab at the bottom of the mentalray render-settings (shown here)

This creates a shader network involving several nodes. If we look at the camera attribute editor mentalray tab we see that mia_physicalsky has been connected to the environment shader slot and mia_exposure_simple to the lens shader slot.

The default settings are a good start point for lighting out door scenes. Here is a render of a 9 objects in a line using the default sun and sky settings - except for the mia_physicalsky visibility distance, which I changed from 0 to 10.

So what is visibility distance and why am I writing about it?

The manual says "Aerial Perspective is a term used by painters to convey how distant objects are perceived as hazier and tinted towards the blue end of the spectrum. mia_physicalsky emulates this with the visibility_distance parameter." This can be a little confusing for two reasons: 1. there is also a "haze" attribute and 2. it doesnt seem to matter what value you give to visibility distance - nothing changes.

Making visibility distance work is easy once you know how. You need to connect mia_physicalsky as a lens shader. Our camera already has a mia_exposure_simple as a lens shader, but we can add another one. You might expect that you could drag-and-drop the existing mia_physicalsky shader into the empty lens shaders box, but for some reason that doesnt work. Luckily its easy to do with a simple mel command.

connectAttr mia_physicalsky1.message cameraShape.miLensShaderList[0];

(You may need to change the cameraShape name to match your camera.) Then the camera attribute editor should look like this

Update: You can also install a modified mel script to make the connection using a button in the attribute editor. Read about it here.

If we rerender the test scene we get this

These are the same settings as the first render except now mia_physicalsky is being used as a lens shader as well as an environment shader. Here are some different visibility distance settings

So what is the difference between visibility distance and haze? Haze sets the amount of haze in the air and changes the look of the sky but on its own does not obscure the view of the objects. Here is a render with haze but zero visibility distance

Here is the same haze value but visibility distance set to 100

And here is another variation

Summary: visibility distance only works if the mia_physicalsky is used as a lens shader.

You should read the previous post called "self reflection" before this one.

If you had tried my suggestions you may have discovered that the reflection pass had no alpha channel. Normally you would "add" or "screen" a reflection when compositing, so you could manage without an alpha channel, but I thought I should do an update and show how to get one.

A small change to the shader network is required. This hypershade snapshot shows the new layout.

The difference is that now the mip_rayswitch connects to the surfaceShader instead of to the shadingGroup. And so the shadingGroup attributes look like this.

Notice that the mentalray "Custom Shaders|Material Shader" slot is now free and I have turned off the "Suppress all Maya Shaders" flag. You may get some wierd looking shader ball swatch in the hypergraph when you do this, but you can safely ignore that.

Now when you render, the reflections should look the same as before, but the alpha channel will look like this.

One more thing. In my examples I am using mia_physicalsky as an environment shader. I should have mentioned that to get the black background in the reflection pass I turned on the "Use Background" flag in the mia_physicalsky attributes, and then left the "Background" slot empty. This way it is still used as a reflection environment, but not for the visible background.

Here is an updated maya scene file with the changes.

Sometimes it is desireable to render in layers or passes that will be combined in post production. This give the compositor more control especially when integrating CG with live action. You may choose to render passes like diffuse, shadow, occlusion, specular, reflection, depth - the list goes on and the choices depend on many factors.

What I want to demonstrate here is a way to tackle a reflection pass using some of the new maya 2008 shaders. Actually I am going to use a new "unsupported" shader - so... you have been warned.

First, a render of some reflective surfaces.

One way to get a "reflection pass" is to make the diffuse components of all the shaders black. That way we are left with just the reflections. Here is the result if I do that.

The problem is that the sphere is reflected in the cylinder and the ground, but it's reflection is black. What we really want is colored reflections and to do that we need the new mip_rayswitch shader.

mip_rayswitch was included in maya 2008 as an "unsupported" shader, which means it was hidden away. To expose it you need to edit a mel script called mentalrayCustomNodeClass.mel (C:\Program Files\Autodesk\Maya2008\scripts\others). Right at the end of the file is this line

return "rendernode/mentalray/internal";

and you need to change it to this

return "rendernode/mentalray/material";

When you restart maya, mip_rayswitch will be one of several new materials in the mental ray section (sadly lacking icons).

The job of mip_rayswitch is to help the renderer decide what content particular types of rays will contain. There are several ray types, but we will look at the "eye" ray and the "reflection"ray. The "eye" ray is what we see through the camera. The "reflection" ray is... I bet you can guess. So we want the fully colored shader to be seen by the reflection ray and just the reflections to be seen by the camera (the eye ray). And to get that we need the connection editor and the new mia_material_x shader.

mia_material_x is a more advanced maya2008 version of the maya8.5 mia_material. One of its new features is "multiple outputs" - meaning it has the ability to output a long list of components independantly. Here we are interested in only two of these called "result" and "refl_result".

mia_material_x.result is the "beauty" pass. Its what you usually see when you render it. On the other hand, mia_material_x.refl_result is just the reflection component of the shader. What we are going to do is create a shader network where the mia_material_x.result is used for the reflection ray in mia_rayswitch and mia_material_x.refl_result is used for the eye ray. This needs to be done for each shader.

Here is a picture of the shading network with the important connections highlighted.

The mip_rayswitch is hooked up to the shadingGroup's mentalray material

Now if we rerender that reflection pass we get this

Now we have colored reflections, but only the reflections.

Here is my maya scene file if you want to have a look.

The creators of Maya 2008 made it easier for new users to use the misss_fast_skin_maya shader by automatically making the required light map connections. But unfortunately they broke something too!

An error in AEmisss_fast_skin_mayaTemplate.mel (which lives in C:\Program Files\Autodesk\Maya2008\scripts\AETemplates ) causes the following error message when you open the attribute editor and attempt to hook up a bump map:

// Error: Cannot find procedure "AEmisssSimpleMayaBumpReplace"

It is easily fixed though. Open AEmisss_fast_skin_mayaTemplate.mel in a text editor and goto line 149. Change Simple to Skin in two places so it looks like this

editorTemplate -callCustom "AEmisssSkinMayaBumpNew" "AEmisssSkinMayaBumpReplace" "normalCamera";

Save the file and restart maya.

Maya 2008 introduces some new camera attributes. Here is a snapshot of the "Movement Options" in the  camera attribute editor.

What this means is that if you select "Use Pivot As Local Space" then the camera will pivot around the "Tumble Pivot" instead of the "Center Of Interest" when you are tumbling around in the viewport. The default "Tumble Pivot" of 0,0,0 means you are just rotating around the camera's own local pivot, and there will be no translation of the camera.

I think this is a very useful option for positioning cameras, but I dont like the idea of having to dig down into the attribute editor everytime I want to use it, so I wrote some mel script to make it easy to toggle the option on and off. Actually I wrote two scripts; one to be used as a marking menu toggle, the other to be integrated with Hamish McKenzies zooCam.mel script.

djToggleUsePivotAsLocalSpace.mel is for use in a marking menu. Just add the command "djToggleUsePivotAsLocalSpace" and give it a name like "ToggleUsePivotAsLocalSpace". You should get something that looks like this (the rest of you menu will be up to you of course).

When you invoke this menu in a camera viewport the script will work out which camera it is and toggle the state of the "Use Pivot As Local Space" attribute.

Download here.

djToggleUsePivotAsLocalSpaceMenu.mel is an alternative script that was written to be integrated into the zooCam menu (which works in conjunction with the zooShots camera switching system - see http://www.macaronikazoo.com/ for more info). The integrated menu looks like this.

If you want to use this style of menu you need to add a call to djToggleUsePivotAsLocalSpaceMenu and provide the camera name, which is very simple in zooCam.mel. If you download my script you also get a copy of zooCam.mel which I modified, but you will need to get the rest of the zoo tools if you want to use it.

Download here.

Maya 2008 introduces a new "Move Skinned Joints Tool" in the "Edit Smooth Skin" menu.

This makes it much easier to fine-tune joint positions after skinning without the need to detach and rebind the skin. However this tool forgets about the bind pose as I will show in the next few pictures.

Here is my skeleton in its original bind pose.

I then use the "Move Skinned Joints Tool" to reposition the sholder joint.

The problem is that if I use the "Skin|Go to Bind Pose" menu I get this.

The solution requires a mel command, but it needs to be executed for each joint that was moved and the name of the bind pose node must be specified. These are details you probably dont want to be thinking about so I wrote a little mel script to simplify the process.

djResetBindPose.mel allows you to just select a joint and run the script. The bind pose will be reset for every joint in the heirarchy. If you do this after the "Move Skinned Joints Tool" and before "Go to Bind Pose" then everything should work correctly.

Download here.

The other day somebody told me about this excellent video tutorial that Keith Lango posted on his blog back in May this year. It runs for almost 30 minutes and demonstrates a rigging technique that is ideal for placing controls for facial animation on the mesh that they are deforming such that they move with the surface.

The cool thing for me was to discover that he uses my djRivet.mel script