antimentalray

I did some color conversion these days. Just to keep it somewhere I will post the formulas here. It was simple with sRGB - everything is on Wikipedia, but for some reason Rec.709 standard does no have the reverse formula in the doc describing the standard (http://www.itu.int/rec/R-REC-BT.709-5-200204-I/en) so I had to derive it myself.

Conversion to linear:

if f > thresh:
    f = pow((f+a) / (1+a), c)
else:
    f = f / b

From Rec.709: use the following values:
thresh = 0.0801
a = 0.099
b = 4.5
c = 2.2222

From sRGB: use the following values:
thresh = 0.04045
a = 0.055
b = 12.92
c = 2.4
       
Conversion from linear:

if f > thresh:
    f = (1+a) * pow(f, 1.0/c) - a
else:
    f = f * b

To Rec.709:
thresh = 0.018
a = 0.099
b = 4.5
c = 2.2222

To sRGB:
thresh = 0.0031308
a = 0.055
b = 12.92
c = 2.4

Just wanted to let everyone know: I had to reject a livejournal user who sent me a request to join the community. I had two reasons to think it was a bot:

1. His/her live journal is empty
2. The user name is unreadable (at least for me).

So if you are human but your account matches two of these criteria, and you want to join the community, please send me a private livejournal message or leave a comment to this entry before attempting to join.

There is officially no known way to render character reflections in mirrors. More precisely, there is no method to render subsurface scattering in reflected/refracted rays, well, unless you use your own sss shader. The misss* subsurface shader that comes with mental ray will only substitute missing SSS with lambert, but it means the reflections will not look like skin.
It would be funny, if we didn't have a feature-length project ahead with lots (I mean LOTS) of character looking into mirrors.

UPD: The issue seems to be more complicated. It looks like stock skin shaders in maya/xsi/max do render sss in reflections. I will need to do more investigation on this.

A nice new feature in mental ray version 3.8: the ability to render two images for left and right eyes during the same render session. As usual, mental images were good at little tiny things that make the entire thing useless. New "stereo" flag in camera declaration is missing a way to specify the convergence (or zero parallax plane) distance. For some strange reason the cameras are always converged at the focal length point.

It looks like they at last managed to confuse themselves by using incorrect terminology. The documentation refers to cameras converged at a "focal distance", but there is no such thing neither in real world nor digital photography. There are two things instead: "focal length" which is a lens characteristic, directly affecting its angle of view, and "focus distance" which defines the distance of objects the lens will project to film keeping them in perfect focus.

I would still mind having both the focus distance and the convergence plane to be controlled by the same parameter, but that at least would make some sense. But the focal length has nothing to do with eye convergence, that's why the entire thing is just useless.

One more wonderful discovery I made these days, this time about mental ray database.

If you think leaf instance names have their unique tags in the database, you are wrong. There could be more than one tag for the same leaf instance name in case there is more than one material attached to the object.

This is very "useful", especially for fancy things you would write yourself, like per-object user data cache. I did it using stl::map, with tags as keys. After a few reports from the lighters (it's not working!) I was able to track down the offenders: two different leaf instance tags have two different instance parents, but after mi_api_tag_lookup() they resolve into the same name.

The worst part is my cache is populated on the first time the surface shader is called, and if this happens in the displacement evaluation stage, not all of the tags are present there, so the cache ends up being incomplete.

I've already mentioned hair/fur rendering in mental ray is a huge problem in many aspects. To name a few:

- The only rendering method that can produce good results is rasterizer, which in general is slower.
- The only kind of shadows that can produce good results with hair/fur is detail shadow map. Let's talk more about the latter.( More... )

Something I've noticed a long time ago, then did a workaround in my surface shader and then forgot about it, but today one of the lighters made me recall it.

In mental ray, if an object with "Primary Visibility" off is behind another, a 100% transparent one, then the former one is still visible. Well for me it does not make any sense. Yes, I know that technically the ray that hits the object in this case is not an eye ray but a transparency ray. But hold on, isn't it just a continuation of the eye ray? In mental images they don't think so, that's why they introduced this weird concept of "transparency" visibility. It's not too easy to relate it to something from real world, but anyways, I can forgive that. Maybe they see  some value in it I'm just too dumb to notice... What I cannot forgive is the following:

- Maya does not export transparency statements, so you, as an artist, would always see these technically invisible objects behind the (semi)transparent ones.
- Even if you wanted to manually inject the "transparency 0" statements on instances by editing exported .mi files, you would not get anything from that. No matter what the documentation says, the transparency statements on geometry instances (maya transforms) are always ignored. For some reason they are only obeyed on objects (maya shapes) in .mi files.

My workaround was simple, but not quite efficient: in the shader I have to traverse all parents of the transparency ray my surface shader is hit by, to see if this ray has no parents other than transparency or eye rays. If this check returns true, I return black/transparent result to hide current object.

A very nice and useful feature in maya 2011 - ability to hide/unhide arbitrary faces of a poly mesh - is not supported in mental ray in case the object is exported as a subdivison mesh. I've submitted my feature request to implement that to Autodesk, and they seemed to accept it. I'm just wondering how will they do so. It looks like mental ray API has no access to face visibility tagging on subdivision surfaces... Meanwhile I was able to write a hacky shader to imitate this behavior. I spent a couple of days to make it work because of the ambient occlusion - it's not easy to make transparent objects cast no occlusion in mental ray. And my solution slows down renders a bit.

As a side note: do you know how much time did it take to add the inivisible faces support to my home grown RIB exporter? Less than one hour - from looking into Maya documentation to see how the faces are tagged as inisible in their API to final testing of working code. One hour. That's it.

...is not respected when raytracer mode is in effect. Quite annoying to say the least. It looks like the only work around is writing a very simple lens shader. No matter how simple it is, you (as a TD) would need to keep in mind it should never be used in non-raytracing mode. Basically there is another problem sitting right here: if a lens shader is going to modify the origin and/or the direction of eye rays, it would need to have a "scanline off" statement in its .mi file. This statement effectively switches the renderer to raytracing mode, no matter what is selected in your render globals. In case you forget to turn this lens shader off, your hairy creatures would look awful, although you were sure you rendered them with rasterizer.