Famous mental ray myths...

Rusty Teapots Unite

There is a lot of misinformation out in the world, misunderstandings that gets repeated and turn into "truths" over time.

I ran into a couple of those at EUE and frankly, I had no idea they were so widespread. So from now on, any time I run into these I'm gonna make a post about it.... here's a collection:

You should always use the mental ray shaders, not the built in max/maya/xsi/whatever...

This myth is both true and false at the same time.

The reality is, there are a ton of "mental ray" shaders, from the very old and very primitive "base" shader library (danger) to very new and very modern "architectural" and "production" shader libraries.

So - yes - if there is a brand new shader that comes directly from mental images that does X, and your embedded application may have some other shader that claims to do X as well, then most likely picking the "mental ray" one is better.

But if there is some ancient shader, from the mists of pre-cambrium, that has a "mental ray" variant, and your application has something that looks as nice, is better integrated, etc.... use that in your application

As an example: The base shader library contains a set of shaders like mib_illum_phong, mib_illum_blinn etc.... never use those! Those are the simplest, most primitive shaders. Avoid!

Much rather than anything "mib_illum_blinn" use the Maya "Blinn" or the 3ds max "Standard" material in "Blinn" mode, or whatever. But even better, use the mental ray mia_material (Arch&Design in max). This is new, mental ray optimized, and we try to integrate it as much as possible into each app.

The old rusty mib_illum_* shaders will have all sorts of issues, interface poorly with the product (no render elements/channel support, no support for diffuse/specular switches on the lights, etc.), handle indirect illumination incorrectly, and so on.

Your apps own integrated materials are mental ray translations of the applications software-renderers material to the "best possible" mental ray counterpart. Your apps own materials are the one most guaranteed to interface with the app's own "features", such as specual switches on light, render channels, whatnot.

And then the mia_material(_x) ("Arch&Design") which we try to make as a "top of the line" thing, and we really try to integrate with as many of the applications own feature as humanly possible.

If it doesn't say "mental ray" dont use it

Similar to above, people have gotten the idea that if a feature doesn't explicitly say "mental ray" or "mr" on it, it is directly unsuitable for use with mental ray.

While this may happen in some odd cases, most of the time, most application features are actually quite well integrated with mental ray.

One of the most scary thing I heard at EUE was someone who asked "You can't use the 3ds max photometric lights with mental ray, right?".

I almost fell off my chair. If you want to render anything even remotely physically correct you should always use the photometric lights. But this guy had been misled by some other lights in the non-photometric category having "mr" in the name.

The reality is that those lights (The "mr Omni" and "mr Spot") are simply lights supporting things that do not exist at all in the other 3ds max lights.

All 3ds max lights are "mental ray lights" when you render with mental ray. Those two simply expose things that only mental ray can do. This does not mean the others "don't work" with mental ray, or that others are "unsuitable" for mental ray.

(Of course, in the case of max lights, what actually is unsupported in mental ray is the 3ds max "trick" to do "area shadows" on any given light, you instead have to make it a real area light. Hence the "extra" light types, although one could argue that perhaps this distinction could have been hidden away from the user in some other way. Alas, water under the bridge....)

So: Please use the photometric lights!

Never use Shadow Maps

This "myth" is the truest of them all. Yes, most of the time you really shouldn't use shadow maps with mental ray (you should use area lights). As a matter of fact I think at least 3ds max ships with shadow maps globally disabled in the mental ray render globals.... this is simply to get around the fact that max lights actually default to shadow maps.

However, there is a couple of cases where you should use shadow maps. And not just any shadow maps - the mental ray detail shadow maps: Hair. Fur.

Yes - any time you want to render hair, that's the time you whip out the rasterizer and detail shadow maps. Not for an architectural interior, but for your fuzzy sidekick in your space drama!

mental ray is slow

Actually mental ray is very fast, if you do things correctly. If you don't do things correctly it - as well as any other renderer - can be very slow.

First of all - suboptimal defaults. If an application ships with a default final gather setting of 500 rays, a way too low spatial oversampling contrast of 0.002 (which makes very little sense), and the default number of motion blur samples set to "19" when "5" is quite enough, of course it will appear slow.

Fixing all those settings can speed it up an order of magnitude.

But yes, I always get this "PRMan displaces faster" stuff. Of course it does.... until you actually trace a ray.

You see, PRMan lives in mindset where raytracing is so slow that you avoid it like the plague. So it uses a completely different method to render things (the REYES engine) which micro-dices things and spits the micro-polygons into subpixels then into pixels. The very nature of this algorithm gives you displacement practically "for free". Coz they work one micro-poly at the time, and never have to keep a single thing in memory.

A raytracer on the other hand (I alost said "a real renderer" *grin*) would out of necessity need to keep all those poly- and micro-polys in memory to have to intersect rays against. So not only do they need to be created, stored in memory, an accelleration structure must be built to speed up the ray intersections. All taking - yes - more time and complexity than dinking away one micropoly at the time and throwing the results over your shoulder when you are done.

The thing is that in PRMan, if you try to shoot a ray, it too has to do all those things. So the minute you actually shoot a single ray in some .sl shader, *grind*, PRMan has to do what mental ray always does.... and the comparasion suddenly isn't so much in favour of PRMan any more.

Since I am of the opinion that there exists no interesting shading that doesn't involve raytracing, I find the fact that "yes, PRMan can be faster with raytracing off" a completely academic opinion of no practical value (but of course, all speed-tests are run like that, naturally.... *sigh*). I am wholly uninterested in oldschool dinky-toys rendering in a fisher-price universe of reflection maps and reflective occlusion (a trick invented solely to "avoid tracing rays". And of course they build their reflective occlusion maps with mental ray... LOL)

Alas, that's all I have time for today.... more later.



Sitting in the Shade with Maya... mia_material shadow shading.

Hello guys and gals.

Just a quick heads-up.

It's come to my attention that there is a performance issue with the "segment" shadow mode and the mia_material shadow shader. It's fine for transparent objects (i.e. it does the job it's "supposed to do").

However, for opaque objects, it is actually doing a bunch of unnecessary work, especially in "Segment" shadow mode - which is the default mode in Maya.

The workaround is very simple; don't use the shadow shader for opaque objects.

Normally, you would use the same instance of mia_material in your surface, shadow and photon slots. Well, if your material is opaque, simply don't put it in the shadow slot. This could gain you some performance.


(In Max this isn't an issue, since first of all, "segment" shadow mode isn't the default, and secondly, the UI frontend actually does the above already, i.e. it doesn't assign the shadow shader at all to opaque objects.)