connectNodeToAttrOverride for mia_material_x

david | dj mod,mel script,mentalray | Thursday, November 12th, 2009

When building shader networks in the hypershade window it is common to drag-and-drop one node onto some attribute of another. When you do this maya attempts to guess the type of connection you are making. If you drag a texture or a material onto a color attribute then maya will automatically connect either the .outColor or the .outValue, depending on the node type. There are other default connections for other types of attributes but if maya can't figure out what to do it opens the connection editor and leaves it for you to make the connection manually.

There is one notable case that seems to confuse people - mia_material_x and mia_material_x_passes. For example say you want to layer mia_material_x over another shader using mib_color_mix or mix8layers. If you drag-and-drop the mia_material_x onto one of the color inputs instead of connecting as you might expect, up pops the connection editor. If you've done this before then you probably know that you simply need to connect mia_material_x.result, but wouldn't it be great if maya was able to do that automatically, and skip the connection editor?

If you said "yes, that would be great" then you'll like the next bit. Back around the turn of the century, the thoughtful folks at alias provided a mel script called connectNodeToAttrOverride.mel which states

//        This procedure is provided as a hook for customers to allow
//        you to redefine the behaviour of drag and drop.

Well that's what I've done. Three lines of code was all it took! Now dragging mia_material_x and mia_material_x_passes works just like the other materials.

You can download my modified connectNodeToAttrOverride.mel from my downloads page.

p_HairTK with p_shader_replacer update

david | mentalray,rendering | Tuesday, November 3rd, 2009

A few months back I wrote about using puppet's p_shader_replacer to override maya's fur shading with the p_HairTK shader. I discovered a strange anomaly that I thought would be worth a mention. But for the rest of this post to make sense you need to know how the p_shader_replacer works. If you don't, have a look here.

So here's the thing: The name of the object that holds the geometry shader and the name of the furFeedback node actually matter. Specifically, the name of the object that holds the geometry shader needs to come before the name of the furFeedback node from an alphabetical ordering point of view. And in this case capital letters come before lowercase.

So this works: pCube1 , polySurface1_FurFeedback - because "pC" comes before "po"

but this does not: pCube1 , PolySurface1_FurFeedback - because "pC" comes after "Po"

and this works: ApCube1 , PolySurface1_FurFeedback - since "A" comes before "P"

Easy once you know, but if you don't then depending on your naming some of your fur will just ignore the p_HairTK.

I'm currently using shaders_p v.3.3 beta 11 for Maya 2010 (win64) and find that p_HairTK is very stable, often quicker to render than maya fur and has better shading attributes. An especially interesting, and welcome benefit is that it fixes the NaN (black pixels) problem that seems to haunt maya fur.

maya 2010 mia_material_x bump bug fix

david | dj mod,mel script,mentalray,rendering | Thursday, October 15th, 2009

In maya 2010, if you connect a bump map to a mia_material_x shader and later change your mind and delete the bump map or break the connection, the shader will no longer render as you expect and the hypershade swatch will turn black. (more...)

p_HairTK, p_HairTK_shadow, p_shader_replacer

david | mentalray,rendering,tutorials | Tuesday, April 14th, 2009

These 3 custom mentalray shaders are part of an extensive shader collection written by Pavel Ledin (aka puppet). In this post I will show how you can use a geometry shader, p_shader_replacer, to assign the p_HairTK shader to maya fur when using mentalray with fur mode set to hair primitives. Doing this gives you much more control over the look of the fur and, depending on how you use it, may dramatically improve yoru render times.

(more...)

p_color_plus_alpha

david | mentalray,rendering,tutorials | Monday, March 30th, 2009

Most of the time its ok to mix maya base shaders with mentalray shaders in the same shader network but sometimes things don't work as you would hope. An example of this is when you layer something like a blinn and a mia_material_x using mib_color_mix. At first glance the render looks correct, but you will find the blinn is missing in the alpha channel. A quick fix is p_color_plus_alpha.

(more...)

miFinalGatherHide

david | mel script,mentalray,rendering | Wednesday, March 4th, 2009

About 6 months ago I wrote about using mib_continue and mip_rayswitch to stop a surface blocking final gather rays. I used this technique regularly yet often wished there was an easier way to do the same thing - and there is!

Alessandro Prodan posted a solution on cgtalk that uses a new attribute called miFinalGatherHide to control whether a surface should block final gather rays.

(more...)

mip_binaryproxy

david | mentalray,rendering,tutorials | Thursday, October 30th, 2008

I was looking through the "Whats New" section of the maya 2009 manual and read this about Render Proxies

Use render proxies with mental ray rendering to manage large scenes with complex geometry. Export your complex object as a mental ray assembly file, then replace it in your scene with a placeholder object that references this file. When you render, the exported object is loaded into memory and rendered with the rest of your scene. Translation time and memory usage are cut down, allowing mental ray for Maya to render large scenes.

And that prompted me to write about the mip_binaryproxy node. Those of us who are sticking with maya 2008 for the time being can use mip_binaryproxy to implement render proxies almost as easily as our friends with maya 2009. (more...)

mip_gamma_gain and mentalRaySwatchGen

david | dj mod,mentalray,rendering | Wednesday, October 22nd, 2008

Using a linear workflow always requires some gamma correction somewhere. If its within a maya shader network then you have some choices. The most obvious is maya's standard gammaCorrect node.

If you have maya2008 or 2009 then there is also mentalray's mip_gamma_gain node (which is hidden by default, but is easy to expose).

mip_gamma_gain

These two nodes perform the same basic function, with a few differences.

Maya's standard gammaCorrect enables independant gamma control of the three color channels.

While mr's mip_gamma_gain offers the simplicity of a single value gamma and throws in a gain control and a reverse switch for inverting the gamma value (saves you having to get the calculator to figure out the inverse of 2.2).

Until very recently, I had always used maya's gammaCorrect. And for one reason only - I like its colorful and meaningful hypershade swatch because it is easy to see in a busy hypershade window.

mentalRaySwatchGen

Now I'm starting to use mip_gamma_gain instead because it occured to me that I can modify mentalrayCustomNodeClass.mel ( in C:\Program Files\Autodesk\Maya2008\scripts\others) and get it to display a swatch that has one of those updating shader balls. That means I can see the actual result of the gamma change.

Although it makes the gamma nodes harder to find in the hypershade window, I'm finding the visual feedback useful.

If you want to try this, make a copy of mentalrayCustomNodeClass.mel into your local scripts folder and edit your local copy. The file has an obvious structure, so look for the "Internal MentalRay Nodes" section and add these lines after it.

if ($nodeType == "mip_gamma_gain" )
return "rendernode/mentalray/material:shader/surface:swatch/mentalRaySwatchGen";

You should also comment out the original reference to mip_gamma_gain.

linear workflow and gamma update

david | mentalray,rendering,tutorials | Monday, October 6th, 2008

Last month I wrote about how I implement a linear workflow in my work. Since then I have noticed that in at least one area I'm doing it differently to many others - and now I know why they are right and I was wrong.

It boils down to this: I've been leaving my frameBuffer gamma at 1 (the maya default) and setting my output gamma to 2.2 via an exposure node, which means I need to degamma my 8 bit fileTextures (but 32 and 16 bit floats are ok). However the other (very popular) approach is to set the frameBuffer gamma to 0.455, and the output gamma to 1, which means generally the fileTexture requires no degamma.

When making my choice I weighed up both methods and I said to myself "The frameBuffer gamma defaults to 1 and the exposure node defaults to 2.2 gamma, so I'll stick with that. After all, it looks the same in the render..." BUT ITS NOT! (more...)

linear workflow and gamma

david | mentalray,opinions,rendering | Saturday, September 13th, 2008

I'm going to start by saying that I do not consider myself and expert on this subject, but I'm going to write about how I have adapted my methods to deal with the "linear workflow" thing in my day-to-day work.

If you have never heard the term "linear workflow" then you must have been really busy doing something else for the past year, because it has been discussed over and over in forums and blogs. I've done a lot of reading and managed to confuse my thinking on numerous occasions, but lately it all seems to be falling into place and I feel like some kind of born again "linear workflow" convert. And like most new converts, I feel compelled to spread the word.

(more...)

« Previous Page | Next Page »

Powered by WordPress | Based on a theme by Roy Tanck