riviera

xyaUberLight: uberlight for mental ray

2008-07-27T05:55:00.003+02:00

...along with proper OpenGL manipulators in Maya -- for your convenience :)

tracetracer: a ray debugger

2008-07-27T05:23:00.004+02:00

Rays are logged during rendering. Then the log file contents can be displayed and examined in Maya (using OpenGL). Click on images for a larger view.

Fixed sampling [-5;-5].

Adaptive sampling [-5;-3].

Adaptive sampling;
upper picture shows ray endpoints only.

mental ray today: color clipping

2008-07-26T18:30:00.007+02:00

In mental ray, when the image being rendered has to be color-clipped (ie. the resulting image is not EXR or float, but 8bit or 16bit), the color clipping is not done to the final pixel color, but to each individual ray sample contributing to that pixel.

So why is this distinction is important? Because it can heavily affect antialiasing (therefore image quality) of the rendered images, if you have 'overexposed' areas in your rendering.

Note that over-exposure or 'burnout' can not only come from too bright surfaces, but some specular models (ie. Cook-Torrance [1]) can also produce extemely bright areas, especially at edges of curved objects!).

So, if you have renderings, where

geometry is heavily motion-blurred,
motion blur quality is nice -- except on speculars, which looks all pixelly-blocky and badly antialiased,
you wonder how comes that all motion blur is nice and smooth, except those specular highlights
the problem goes away when you render in 8bit/16bit, but back again in float/exr output --

Then, well, you 'hit the spot'. (See a previous post about antialiasing.)

A possible workaround is to apply color-clipping to your shader output. It doesn't have to be clipped at 1.0, so one can still do post-rendering exposure adjustments in compositing. (But I'd recommend clipping intensities above ~4.0-5.0.)

[1]: It is a known attribute of the Cook-Torrance that it can result in extreme highlight values on surfaces facing away from the camera with light coming in at a steep angle (it is mentioned in various renderman-related literature).

I'm too lazy to elaborate further, so I'll just paste a snippet from the mental ray mailing list:

On Wed, 21 Jul 2004, Jason Crosby wrote:
Somewhere along the pipeline MR seems to be clamping this value so I
can't get very bright motion blurred streaks.

That's true. Frame buffers that clip (8-bit or 16-bit RGBA) do so before
filtering. The reason is that it often happens that a curved surface gets
a very bright highlight occasionally during an animation, if it just
happens to be at the right angle or position towards a HDR light. Most
of its neigbors stay within a more sane range.

Such a superbright sample would peg the filter result to (1, 1, 1) no
matter what the other samples under the filter say. The result is a peak-
white pixel or group of pixels in the image, with hard aliasing towards
their neighbor pixels. In an animation, these pixels tend to flicker and
move. There is no way you could manipulate the filters to fix that.

This problem has been hotly debated here for a while. On one hand, mental
ray can't figure out the user intent, so it would have to become an option.
On the other hand, mental ray doesn't really need more options that have
a subtle effect on a hidden algorithm that one shouldn't need to understand.
But it can't be ignored, so we'll probably extend the colorclip mode with
two modes that turn off preclipping in mental ray 3.4. We are uncertain
whether preclipping should be on or off by default.

Until then, you'll have to use a floating-point or RGBE frame buffer (the
former uses four times as much memory!).

Thomas

--
Thomas Driemeyer
mental images, Berlin

CSI mental ray: render stats utility

2008-07-26T17:41:00.015+02:00

If your job includes shepherding and troubleshooting mental ray renderings, you might like this idea.

It occured to me that in movies and TV shows (like CSI) they always watch graphical feedbacks of everything, but in real life we mostly only read textual log files, which is boring and tedious. As my job involves such reading (mental ray statistics of rendered image sequences), I thought I might put some extra work in to make my life easier, and do a graphical stats display.

I wrote a small Lua script, which reads the mental ray output for each frame of the rendered sequence, extracts all 'statistical' data to be displayed, then uses GNUPlot to generate some nice graphs.

The following example is an actual 'production' sequence (click to show in full size -- the graphics isn't fancy CSI style, but it's alright).

This is for an entire sequence: the horizontal axis is for each frame, the vertical is the amount (time/memory/etc.)

The first image shows how much memory were used by the various rendering modules (eg. so, if lots of textures are used, the IMG section will grow).

The second image shows render times, including how much time was spent in each preprocessing/rendering phase.

(In the example one frame has an extremely long file parsing phase, which could have been a temporary network glitch -- see image #2, bottom, middle.)

The third one is memory usage again, but this time shows the consumption during FG and the actual rendering phase.

The fourth shows the amount of tessellated geometry. It also shows how much geometry got re-tessellated (ie. when mental ray ran out of memory and had to flush geometry). It could be an indicator of too much geometry in the scene, or not enough memory allowed for the geometry cache.

The actual shot contains a character that walks in then out of the camera view (hence the gradual increase then decrease in both render times and memory usage).

This proved to be a very useful tool: with just a few graphs you can see most of what happened during sequence rendering. (What's also useful is a stats of how many primary/reflection/etc. rays were traced for each frame -- unfortunately mr doesn't always display this info.)

To actually get these data printed out by mental ray, the following lines should be added at the end of each .mi file:

# post-render diagnostics

debug "mem summary"
debug "mem dump"
debug "db statistics"
debug "db summary"

Unfortunately I don't have a web site (yet), but as soon as I finish it, I'll post this utility for download.

C++ did-you-know

2008-05-28T00:50:00.004+02:00

In C++, you have to place inline functions in the header (.h) files if you want to make sure they get properly inlined.

What I did not know, however, is that it is the same with template functions (be they templated classes, templated member function[s] of an otherwise non-templated class, or templated plain old fashioned 'global' functions).

So you have to place templated functions too (along with inlines), in .h files.

If you do not, your code won't compile, unless you explicitly define the specializations. (At least, in MSVC++2005. VC++6.0 blurted an internal compiler error quickly, so I couldn't try :))

Although I understand the "why", I still hope for the day to come when such issues will never bother us anymore. (One solution would definitely include moving to a tropical island and open my own bar :))

Houdini praise

2008-05-12T00:02:00.002+02:00

...and while I'm in a praising mood, here comes another one:

Houdini is cool!
Houdini is power.
Houdini be praised!

:)

skinning notes #2

2008-05-11T23:32:00.008+02:00

Maya 8.5, smooth skinning: copy/mirror skin weights

Previously I made some quite harsh remarks about the quality of the Maya (smooth) skinning tools. As I don't want to appear a 'half empty glass' person, there's some praisin' comin' up:

In Maya 8.5 the copy/mirror skin weights functions are actually working (imagine that! they can do the job). And properly! I must say. ~~Such a rare moment happens in every decade or so, so enjoy!~~

But seriously and without sarcasm, I really like to thank the developers. I'm grateful as for these things now I can talk about 'spent minutes' instead of 'spent hours' (and that's quite a difference).

---cut---

Another goodie-goodie: the dual-quaternion skinning now supports scaling, yee-haw! (I'm too lazy to post a link, google it.)

A related hint: the good old 'rigid' skinning method is very similar to dq skinning (it does proper rotation interpolation), and it can be painted, too (I don't know how many people are aware of that). I'm sorry that it became an 'abandoned' feature, as it's still quite useful and I still use it on a more or less regular basis.

You can even do what I like to call 'hybrid skinning', if you bind the geometry with both smooth and rigid skinning, and put all skin deformer sets into a partition. The initial setup is a bit of a hassle, but then you can set for each vertex if it should be skinned 'smoothly' or 'rigidly', and paint both, or use flexors or jointClusters, etc. I might write a tutorial about it someday :)

NaN blues, a.k.a. if ( dot_nl > 0.0 )

2008-05-09T22:13:00.014+02:00

(Note: what's described below is only a half-solution, so expect an update coming soon...)

Black/white pixels in rendered images

Have you even seen annoying black/white pixels on your mental ray rendered images, alongside with similar messages in the output:

RCFG 0.4 warn 542009: finalgather ray returned NaN for the finalgather point at pixel 401.805 212.559

Well, I have and I didn't like it. I spent the last few hours tracking this bastard down. And catched it I have!

No matter what, this phenomenon might occur even when rendering with the simplest shaders (like mib_illum_lambert).

The cause of this problem seems to be that sometimes subdivs can have funky surface normals, and this allows sneaking in of NaN values in the illuminance loops of unaware shaders. (Like even the mental images base shaders.)

The solution is simple (but needs re-compilation of a shader, some artists might want to consult their fellow TDs :)). Modify your illuminance loop to look like the following:

while (mi_sample_light(&color, &dir, &dot_nl, state, *light, &samples)) {

if (dot_nl>0.0) // (1)
{
sum.r += dot_nl * diff->r * color.r;
sum.g += dot_nl * diff->g * color.g;
sum.b += dot_nl * diff->b * color.b;
// (...or your own illum stuff, whatever...)
}
}

(Sorry for the stupid non-formatting). The line marked with (1) first seems only as an obvious quick optimization, but it also filters out any incoming NaN values. (And these values do come in sometimes.)

If you add this dot_nl checking to your shader code, it will be (a bit) faster, and as a bonus it will get rid of those NaN pixels, too! :)

Cause and effects

I have to mention that NaN pixels can also be produced by incorrectly written shaders. However you can run into NaNs even with the simplest default shaders and with topologically correct geometry.

I don't know if this is a mayatomr or a mental ray bug, but these NaNs are caused by tessellated geometry, not shaders.

Under Maya 8.5, if you have subdiv geometry, the "Quads to Triangles" option of the subdiv approx. node can sometimes generate subdiv surfaces with funny normals, resulting in NaN pixels. So be aware of it.

("Quads to Triangles" can do funny stretches to your UV-mapped textures, too.)

The effects of NaN pixels can be very annoying. First (of course) they appear as black pixels (or white, depending on what your image viewer prefers :)) Also, they start multiplying when final gather is enabled, and since it's a global effect, you don't have any real chance to backtrack where those NaN values bounced from to your current sample. Even if you could, it's no use, as it happens to models with proper topology, too.

If you have motion blur, you can have black streaks instead of pixels. Try to blur these in your compositing app, and the blackness will grow quickly instead of diminishing (NaNs quickly propagating to the neighbouring pixels). I've actually had Nuke crashing when I tried to apply a median filter to it.

annoying

2008-05-07T10:43:00.004+02:00

mental ray (3.5.6.3) still clamps all custom frame buffers if the main framebuffer depth is set to 8 bits. (Works correctly in 16bit and float main buffer modes.) I thought this was fixed decades ago.

No further comments. :)

a few notes on mr anti-aliasing

2007-10-30T15:12:00.003+01:00

During the last job, I made some observations about a few things one should be careful about when trying to get properly sampled results from mental ray.

(Actually I was quite surprised, as I didn't expect any problems, mr usually does a pretty good job of sampling and I never had any problems before.)

1. This one's a no-brainer :) Be careful about view-dependent tessellation (e.g. of subdivs) when you have reflective materials, especially if there's thin geometry. Otherwise it'll flicker like hell in animations, even on sampling settings like [1;3] *.

2. This one's important: Shaders should try not to 'overshoot' pixel color values (above 1.0), especially if the geometry is thin.

Although the second one came as a bit of a surprise, it seems mr can have problems anti-aliasing extremely thin and bright geometry. In one scene we had some thin 'metal' pieces which had a reflection intensity amount of ~200%.

While this 'can't happen in reality', this was a (so-called) production scene, where this was an acceptable (?) setting (well, at least it gave the results the compositors needed).

However in some areas it produced such extremely bright pixels mental ray seemed to have problems anti-aliasing them properly.

(Well, to be correct: mr did it right, but ... 'garbage in, garbage out', as the saying goes...)

*: Contrary to some [x]si friends of mine, I dare say I almost never had to render anything with higher sampling than [0;2] -- this could even be used as a warning to oneself: if I have to go higher than [0;2], then something's going wrong :)

say "monolithic"

2007-08-23T19:59:00.001+02:00

The image on the right is a snapshot of my general-purpose material shader (mental ray) which has only two additional capabilities: it can output shading components to separate buffers and it can 'interact' with a 'fellow' light shader.

I'm so annoyed that the code got this long (there's no 'extra fat' in there), and with every production-related request, it keeps growing bit-by-bit. I don't like it.

Dual Quaternion-Based Skinning

2007-05-17T14:42:00.001+02:00

I recently stumbled upon dual-quaternion skinning (here to here).

It's very cool, and works much better than regular linear-blended skinning (aka. Smooth Skinning). I'm so tired of working around geometry flattened out by joint rotations (which I usually do using a PoseDeformer-like method).

One serious disadvantage is that DQ skinning doesn't support scaling of joints, and that's bad (I often use that, even for non-cartoony characters). I with there was a workaround for that.

ps.: An updated opinion of smooth skin painting: I realized that the Smooth Skin Paint Weights Tool doesn't (have the chance to) mess up weights, if you "hold" the weights on all joints except the one you paint, and its "relatives". Based on that idea I wrote some support scripts that sped up my painting workflow quite a bit. (Meaning, I don't feel the urge to kill ~~who wrote the paint tool~~ someone while painting weights anymore.)

However I still stick to my opinion that a proper paint tool could be written that wouldn't force the user to resort to "manual" tricks. (I am actually willing to do that if I get the time.)

still linux

2005-12-28T21:21:00.001+01:00

This is not directly work related (as for the last few weeks I managed to take only a "light workload"). Since the last post I keep on using Linux, and I quite like it. It has a different feeling (but nowadays people aren't used to multiple OSs, only the most dominant).

It took me about a week to get comfortable with it, but after that, it's very familiar and useable (my solid opinion is that there are at least 3-4 *x window managers beat windows UI-wise any time :)).

Actually I like it's look so much that I even posted a screenshot; take a look. :) Everything is antialiased, nice and smooth, yum-yum. ;) I figured out that I actually like the OSX window borders... (But never the other UI buttons'n-stuff -- from that much candy I could almost puke.)

I know that WinXP also has antialiased fonts and shit, but still, for some reason this still looks much better to me. But perhaps it's not just the look, but the richer functionality that gives that. :)

linux

2005-12-22T01:17:00.001+01:00

I'm switching to linux (again), this time it's Kubuntu. Now I installed it both at home and at the office, as I'm planning to use it for work and ... everything else :)

I'd like to have an own web space again and a proper home page plus wordpress installed. The current situation is a bit depressing.

a surprising mental ray overhead

2005-11-25T22:57:00.002+01:00

Today I had a kind of "shocking" mental ray-related discovery.

A few years ago during an exchange of e-mails with Thomas Driemeyer (a "mental head", I took the liberty of asking questions from the most reliable source :)) we talked about adaptive sampling, and he hinted that the noise pattern of area lights can also be reduced by using very low contrast thresholds, and setting the area light sampling to even as low as 1x1 (as the rigorous overall sampling would take care of it anyway). [*]

For the past few days I'm gotten back to shader writing, and wrote a "soft illumination" material shader, which basically softens lambertian surface illumination by taking multiple samples, each with a slightly modified surface normal, then averages the result.

Technically, it's a small and fast loop within the main illum loop, so I didn't expect any major slowdowns (except that with this softening the shading can go beyond the "terminator", so backface-culling should be disabled for light testing).

As this is a multi-sampled effect, there's chance for noise, so for the first try I thought of using a low sampling rate in the shader, and trying to get rid of noise using mental ray's adaptive sampling, and the speed results were shocking: the non-smoothed lambert got rendered in ~14 secs, the smoothed one took more than 1 minute!

Now that's bad, I thought, and set increased the number of softillum-samples within the shader and the rendering time dropped to ~30 secs! Then I picked up my jaw from the floor :) This means that there was a pretty nice administrative overhead of mental ray between the calls of my shader!

(On second thought, it's really not that surprising, especially if there are other shaders to slow the sampling down, like expensive light or lens shaders.)

So, the conclusion is even if all artifacts can get rid of by increasing overall sampling, it's faster to use oversampling options within the shaders.

* : Another 'myth' is that by using high image sampling, one can get rid of flickering artifacts of procedural texture shaders. Although I'd be the happiest person on the planet if this was the case, but it is not.

So, the bad new is, if you write your own procedural texture shader, you have to implement texture antialiasing yourself, or it'll flicker like hell in animations.

The good news is that if you're lazy and go for the usual 'brute-force' in-shader oversampling, mi_sample() will be a good and reliable friend. I experimented with shaders, where the procedural 3d texture was evaluated n times, and I used mi_sample() to generate 'random' offsets for the xyz coordinate input of each eval, and with very nice results.

A tight inner sampling loop within a shader is the fastest you can get, so use it! (The general rule applies here, too: move out as much code as you can from the loop itself, especially non-inlined function calls and mi_* calls!)

texture deformer; some deformer notes

2005-11-08T23:09:00.002+01:00

I just finished an implementation of a "texture deformer" -- basically a displacer, which uses a procedural 3d or projected texture to apply displacement on objects' control vertices.

Initially, I wanted to follow Maya's DG node "behavioural" guidelines as exactly as possible (ie. that a DG node should produce it's result based only it's input attributes -- like a "black box" --, without getting data from the scene any other way).

Now, for a displacement deformer such as above, the texture node should be evaluated for each vertex. I wanted to achieve this by having an input attribute on my node where the texture is connected. Then I could've found out which output attribute of the texture is connected to my deformer. Then, in the deformer loop, for each vertex I set the texture's output attr "dirty", forcing it's re-evaluation (and feeding it the proper spatial coordinates, of course).

I was intrigued from a theoretical point of view -- this is basically evaluating a sub-graph multiple times from a node, and I wondered if the architecture allows it. (Actually I hadn't got much doubt on my mind, as regardless of my many Maya-related rants, the foundation is a solid one; that's Alias's luck, that those were some exceptional people who laid out the basics :))

But my experiment ended a bit unexpectedly sudden when I couldn't find a method for setting an attribute dirty (there seems to be no counterpart for ::setClean()). So at the end I ended up using MRenderUtil::sampleShadingNetwork(), which is a 100% valid solution. (The other reason why I wanted to use the general DG-evaluation way is to allow not just shaders but any nodes -- like expressions -- to be used as input. But any such node can be used in shader networks as well, so it remained flexible enough.)

However the occasion of writing this deformer brought me in a situation that is very common for anyone who writes more complex deformers. It's not the deformer class itself, but rather the MItGeometry class (which the deformer uses for iterating through the geometry control points.)

To put it short, with MItGeometry you can only access vertex coordinate data but nothing else (such as vertex normals, UVs, and the like) -- and if you want any of this, you have to go upstream the graph yourself to find the original geometry, write different code sections for each major geometry type, etc. This quickly defeats the intended elegance and simplicity of the code.

So I'd really like to have an MItGeometry class extended with methods for querying such common surface attributes (well, at least normals and a few other common topological properties, like tangents, etc). It would be very useful.

a different blendShape implementation

2005-10-21T21:07:00.001+02:00

A few days ago I read about how blendShapes were implemented in Mirai (the basic idea was that all targets were stored in the same mesh -- for each vertex the position differences from the base mesh, and that's for each target shape), and suddenly I got the idea how to implement this in Maya. One fundamental advantage of this method is that the mesh can be re-modeled even after the blendShape targets are created; the target shapes are preserved properly even after topology-changing operations.

The actual implementation turned out to be so easy I already got a final working version of this. It took me about only one day and now I have an excellent power tool that turns regular blendShapes to dust, big time! :)

It feels so good when you create something simple that however will change (improve!) a part of your life. That might sound (over-)dramatic, but I'm also a rigging TD, so "with one hand I build it, with the other I use it" :)

The next step is to implement a pose-based skin deformation tool based on the above. Actually I already have a working prototype of this, I just need to do a bit of testing, and round the edges in terms of UI and the like. A very good thing (that I'm looking forward for) is if a skin is set up with blendShapes helping the skin in critical areas (knee, elbow, shoulder, groin), then I could even switch back to rigid skinning (it's much faster in every term, and I'm sick with the quality of the smooth skin editing tools).

Finally, the third thing I'm planning (and this is the only that is just a plan for now and doesn't exists yet) is to store skin weights on the mesh in the same way the target shapes are stored. That would provide complete topology-independence for all skinning and blending! (I could even extend this to any weight map, in general.) Wouldn't that be cool! I'm gonna do it, no doubt. No doubt on my mind... :)

[Actually, it would be cool is Alias somehow extended the deformer class in general that weightmaps would be preserved after topology modifications.]

I wonder why Alias doesn't implement such features. If I can write this kind of stuff in a few days, they could do this stuff much more properly (without the workarounds I constrained to). My favorite company from this point of view is Side Effects; with every release of Houdini they pump in an awesome amount of useful features (especially if you compare them to Alias). That's a good opportunity to remind myself to install that Apprentice edition I grabbed yesterday! (I've also written a Houdini exporter back in the good ol' days... ;))

poly modeling, average normals

2005-10-19T22:15:00.001+02:00

I stared to look for fellow Maya users' presence and found a small article (post) by Eric Hill here. It is about merging a head and a body geometry at the neck.

One of my comments on that would be that it is always better to merge edges than vertices (ie. with the Merge Multiple Edges), because it has a smaller chance of ending up with improper topology (although not much smaller).

In this regard, the poly modeling toolset of Maya 1.0 was simply perfect: all necessary tools existed, but in a way that you simply couldn't build a topologically incorrect polymesh. The downside was that you couldn't fix bad meshes (for instance, imported ones). But I remember I was very impressed by the thoughtful selection of proper functions.

(It is more or less true for the entire 1.0 version of Maya: it was one of the most important milestone in the entire history of computer graphics. My opinion is that it is the best 1.0 release ever.)

Anyway, back to the original point: the other modeling function I wanted to mention is the Normals->Average Normals, which allows you to set
smooth normals nearby vertices. It can be used to get rid of the hard edges of a neck/body seam without actually merging the vertices.

mayaknife

2005-10-19T16:42:00.001+02:00

It's always interesting to find other people with similar professions and/or interests.

http://www.livejournal.com/users/mayaknife/

This guy was a Maya developer (or at least, worked at Alias when Maya had the slogan "Tools for 3D Minds" -- which was a pretty cool one, I think), then changed to freelance plug-in/shader writing. It's interesting to read about his work (although he spends a bit more time on issues like shadow matte shaders than it deserves :)). I'll try to find other Maya related blogs (with the Google Reader it might be easier, but I'll see).

Smooth skinning headaches

2005-10-19T03:11:00.001+02:00

Maya smooth skinning caused me a lot of headaches in the past, but with the "enhancements" included in Maya 7, it got even worse. There was a point when I could actually kill someone.

Issues:

In Maya 7, smooth-skinned geometry displays joint colors on geometry components (ie. vertices) when in component mode (even if you turn joint coloring off). This is useless, except that now I cannot see which vertices I select, because of that stupid coloring.
In the Paint Weights tool, all reflection painting options are now simply disabled, and the manual explicitly tells you that if you want mirrored weights, you should do it using the appropriate function (Mirror Weights). Now that is simply outrageous.
The above mentioned Mirror Weights and Copy Weights functions are still crap. Although they seem to be working better than previously, they are still very unreliable.
In the Paint Weights tool, smoothing the weighted paints usually messes up everything so much that some vertices try to escape from the known universe. This effect could be found in previous versions, but now it's several times stronger. (This can be reduced by setting the max influences to 5 or more, but you can never get rid of it. Also see below.)
In practice you have to use at least 5 influences per vertex, otherwise the paint tools doesn't work properly (especially smoothing). I think we all know the usual smooth skinning phenomenon, when you move a character's joint on one side and it moves vertices on the other... The paint weight tools were always imprecise, and I tried to address this by reducing influences to the minimum (usually 2). Now I can forget about that, too.

In general, the quality of Maya's smooth skinning toolset (I'm talking about the editing tools, not the deformer itself) is worse than any beta (or alpha) software, and they didn't address this very serious problem for versions. And it's still not better in 7.0 -- they seem to be doing something to it, but it's still crap, the only difference that it's now crap in a slightly different way. :(

For Maya 6, I had to completely rewrite the "Prune Small Weights" function, as it didn't seem to be working at all. Now, after my first ride with the "new" skinning tools in Maya 7, I'm considering of writing my own version of the Paint Weights tool.

What I understand least about all this is that skinning is one of the f*cking most important things in a 3d software, and Maya is one of the most popular ones. These are the moments when you try not to think about that you actually paid for this. :)

Update, 2005. oct. 30.:

In the meantime I found a way of re-enabling the reflection option in the Paint Weights Tool, but in response Jill Ramsay from the highend3d list explained why this function got disabled. (So I have to look into this, perhaps I was too harsh about this particular issue.) The rest of my opinion still stands :)

mrfm shaders #2

2005-10-19T02:17:00.001+02:00

While I'm at it, another rant about mental ray for Maya shaders:

The refraction calculations of all mrfm shaders are simply crap. (I've found this out spending about 1 1/2 hours, trying to shade a proper C***-Cola bottle, and when I couldn't get the glass part right, at the end I built it from base shaders -- "material" and "sample compositing".)

This is very annoying, and one of the most outrageous bugs. It is also so easy to notice, I don't understand why is it not fixed? (Still broken in 7.0)

[Btw: for the proper IOR effect, the material shader should check if the ray is incoming or outgoing (based on surface normal direction); for an incoming ray the IOR value should be used, for outgoing the reciprocial of the IOR.]

And I not yet mentioned the other issue of Maya not carrying alpha component with colors within shader networks (although mental ray does), resulting in things like black alpha for areas shaded with base shaders, etc. (I know these things can be fixed, but I want such things to simply work without explicitly addressed.) The absence of alpha sometimes can be a problem with native Maya shading networks as well, not just mental ray (the alpha for a shader's defaultColor, for instance).

Yet again the need for an own material shader. (I'm just too lazy to get into it... :))

Note on mental ray shaders

2005-10-19T01:45:00.001+02:00

Our most recent job was a 30sec full-CG commercial with animated characters (I'll post images later). I had to do character rigging and lighting/shading (at the end I did comping as well). We used mental ray (for Maya) for rendering.

When I was lighting one of the backgrounds (a bathroom set), I thought of optimizing shading a bit, and changed the shader of the walls and floor -- both were Maya lambert shaders with textured color channel, and I simply changed this shader to mib_lambert (the mental ray base shader).

Now consider this: render time dropped from ~5:30 to ~2:30 which is almost 50% speed increase! (The walls and floor covered much of the image.) I did expect some speedup, but that was definitely beyond my expectations. It is good to know how optimized the Maya shaders are. :)

Anyway, the conclusion is this: always use the simplest shaders that are suitable for the actual task -- it's worth it. (Other issues might be faced however, for instance the mental ray base shaders doesn't support Maya-style light linking.)

A side thought: it is not just the quality of the mental ray for Maya shaders -- I never saw a single CG application that had properly written mental ray shaders (including Softimage|XSI, where I could also mention procedural textures' quality). I mean quality of the actual shader code (such as skipping unnecessary calculations, doing texture antialiasing for procedurals, etc).

One item of my very long "global todo list" is to write a proper shader library (or at least a proper material shader). By the way, what should be mentioned here is Gonzalo Garramuno's excellent mental ray stuff which can be found here (called mrClasses, placed at Sourceforge).

begin

2005-10-19T01:26:00.000+02:00

After some (not-so-much) thinking, I've decided to create a "blog" for writing about my everyday experiences in 3d computer graphics work.

I'm Imre Tüske, and I'm a CG artist and technical director, living/working in Budapest, Hungary.

I use Alias Maya for 3d and Shake for compositing tasks. For the time being I mostly work on commercials, where one often have to do everything by himself (modeling, animation/rendering and compositing). With about 7 years of experience, I do entire CG commercials just by myself smoothly (and that includes dealing with crazy requests from clients ;)). I have movie/film experience as well.

When working in a team, I usually do technical direction, that includes: designing and realizing CG workflow pipelines, character rigging (and other areas requiring technical assistance); also lighting/shading and compositing.

I also have "average" programming skills, and I often do Maya MEL scripting and API plug-in programming.