mental ray 相关

安装

关于SPM的安装和破解，参考这里http://cgpersia.com/2008/08/softimage-xsi-70-400.html

 

之后，安装mental ray standalone 3.5.1，

 

然后，用破解的ray.exe替换安装目录bin下的ray.exe

但找不到可用的破解的ray.exe

 

 

资源

http://www.maxplugins.de/

CG References & Tutorials http://www.fundza.com/

http://www.impresszio.hu/szabolcs/MentalRay/MRResources.htm

 

Open Souce Projects

miparser    - A parser for Mental Ray scene files

mrClasses - A C++ wrapper and utility classes for the mental ray API.

mrLiquid     - A tool for translating Maya scenes into another renderer's scene description. Currently it provides support for mental ray and provides a very direct level of compatability with maya2mr.

 

blog

Candy Lab Official Blog

http://www.pixero.com/

http://cgkarl.blog.163.com/

http://www.lvyuedong.org/projects/tech/mentalray

 

shader collections

http://www.alan-warren.com/tag/aov/ , mr,rm

http://www.djx.com.au/blog/   zootoolbox, mr, maya, rendering

http://www.pixero.com/downloads.html   mr shaders, maya shaders, darktree shaders

http://www.pixero.com/downloads_mr.html mr shader links

shaders_p

shaders_p扩展，使用

http://blog.candylab.co.uk/tag/shadersmentalray/

http://be3d.republika.pl/

http://forum.mentalimages.com/showthread.php?t=3321

http://en.wikipedia.org/wiki/Mental_ray (external links)

 

FAQ

http://www.lamrug.org/

http://jeffpatton.net/forum/index.php/topic,4.0.html

http://www.mymentalray.com/forum/showthread.php?t=22

http://forums.cgsociety.org/showthread.php?f=183&t=104578

 

Why not MR

    Facts only
    This posting will be updated with the latest summary of issues.

    Overall Design

    "Specification first, implementation next" motto is not about mental ray. In my opinion there was no fixed feature list or a clear marketing or technological goal in the first place. So current state of the renderer (now at version 3.7) looks like an iterative result of patches, enhancements, patches of enhancements and enhancements of patches. Its architecture in general is unclear and has lots of "ifs" and "howevers".

    Scene Database

    - Either poorly designed or some of its features, like tag/name resolution, are not used by the renderer. Hence the famous "unknown db tag" error messages followed by fatal termination with no diagnostics whatsoever. It can only be compared to a programming language compiler segfaulting on syntax errors in source files with "there is an error somewhere" message. Given the fact an average production scene consists of hundreds of millions .mi lines, this is a MAJOR issue. The "null db tag" message with no info on at least the shader which caused that, is super annoying as well. Actually a segfault in this case would be much more informative for a TD running ray under debugger.

    - There is no generic mechanism to attach named user attributes to geometry hierarchies. User data block was supposed to fill the gap but it doesn't. Data blocks cannot be propagated down the dag hierarchies which is necessary to tag groups of objects for many applications, including but not limited to custom light linking and shader control. Two types of shaders were introduced to fix it (Inheritance and traversal) but with no success at all. Basically this is because of a poorly organized datablock C structure: it is a sort of singly linked list in which the datablock has the "next" pointer inside it. So the same datablock cannot be part of more than one chain.

    Parser

    - Gzipped input not supported. This can be worked around with a wrapper ungzipping the input and feeding the renderer's stdin with uncompressed text. But it is impossible to do so for the assemblies (see the API section below, DealyedReadArchive equivalent)

    - Syntax errors in some cases are silently ignored by the parser. Later on that leads to a crash (null db tag or just segfault) with no visible/detectable reason.

    - Inconsistencies in scene description language, like for example a material instance should be terminated by the "end material" line but the shader instance shouldn't.

    Shading

    - Concept of all samples being infinitesimal points (unlike Renderman area-based samples) makes it easier to write procedural shaders, since you don't need to worry about derivatives and antialiasing. But this is excessively compensated by general ineffectiveness and texture filtering problems. The most evident thing revealing the invalid nature of point sampling coupled with adaptiveness on the eye rays is the user framebuffers. If the adaptiveness threshold is defined by the beauty image, it results in poor framebuffer antialiasing in shadows, low light, etc. If we detect contrast on all framebuffers (contrast_all_buffers), render times can increase by an order of magnitude.

    - Elliptical texture filtering is bogus: there is no way to specify boundary conditions (periodic / clamp / black): it's always periodic. So even a simple thing like bluring texture border (blured decal) is not possible. No diffuse/specular convolution kernels are available, so a simple environment illumination shader can easily grow into a separate software project involving R&D on texture filtering kernels, spherical harmonics, etc.

    API

    - miColor, their basic color class is 4-component rgba. Just plain wrong. Alpha is not a property of color. It's a property of layer, surface, or whatever else but not the color. It's really hard to think of alpha of light color for example. What do you do with alphas when two colors are multiplied or added? What is the alpha of the color representing surface transparency or shadow transparency? This is confusing for not only the regular users, but also those people working for mental images and writing mental ray books. How do you implement C++ methods to multiply or add colors? The only feasible reason I would agree to have alpha value in color for is framebuffer handling, but in many cases it's not even used there (see rasterizer section below).

    -  mi_trace_transparency() concept puts the burden of alpha compositing on shader writers, but not for the rasterizer mode. Coupled with framebuffer control sceme it makes shader code as ugly as it's error-prone.

    - One shadow map / shadow type per light limit coupled with no API facilities to write/read shadow maps. This makes many advanced effects impossible without A LOT of programming involved to implement your own shadow map format and thread-aware facilities to read and write it.

    - Purely non-OOP API. I would forgive it in 1979 but not in 2009. There are a couple of C++ patches like light iterator class, but for practical reasons (over-protective light caches which I need to reset sometimes) I avoid using them.

    - There is no viewer to display Detail Shadow Maps (equivalent of Deep Shadow Maps) in mentalray's toolset. Detail Shadow Map format is not open and there is no API to read it, so you cannot write your own viewer. Thus, to check what's happening in shadow map you have to switch to standard shadow map format and render it again.

    Specific problems/bugs

    - Motion blur (if not rendered as motion vectors only) cannot be used because of its dramatic effect on render times, no matter they claim it as "improved"  in version 3.7

    - Motion vectors (state->motion) do not consider camera motion in raytracer mode. This is claimed to be a feature, not a bug.

    - Rasterizer: colors sent to user framebuffers gets multiplied by beauty alpha before layer compositing if the renderer thinks it's necessary. This kills specular framebuffer on transparent surfaces. Also the fact the framebuffer's own alpha in the miColor's 4th component is ignored in favour of the beauty's alpha plus the fact another 4-component color transparency value could be provided via mi_transparency_set(), makes rasterizer alpha compositing quite convoluted. Although the "A over B" and alpha itself are one of the simplest concepts in CGI history.

    - Material phenomena with non-default shadow shader and at least one detail shadow light reliably crash the renderer.

    - NURBS objects with displacements on them get excessively tesselated producing many thousands of polygons more than necessary even if the displacement amplitude is zero.

    - Hair rendering/shading. The only mode to render hair with decent quality is rasterizer. The only type of shadow to render hair with decent quality in acceptable time is detail shadow map. Unfortunately these two limitations mean tons of serious problems. Rasterizer functionality is limited in terms of user framebuffers with speculars and reflections on transparencies. Shadow maps are limited in terms of lack of "light radius" functionality to produce sharper shadows from closer shadow casting obejcts and softer shadows from distant objects. This alone makes production rendering in mental ray problematic to say the least.

    - Heavy assemblies seriously slow down scanline mode with no visible reason: memory consumption stays way below the limit

    - Assemblies (equivalent of Delayed Read Archives) cannot be nested

    - Assemblies in raytracer mode cannot be used: mi_trace_transparent() always returns 0 so alpha on (semi)transparent objects renders completely broken.

    Maya integration

    - Switching Mayatomr to "Export with full dag hierarchy" which is necessary for many reasons produces buggy .mi files. Cameras and lights get incorrect transforms and/or motion transforms in case motion blur is used.

    - mayabase shaders are not available in source code. That makes customization impossible. You basically would need to start writing all shaders from scratch having a lot of fun with all kinds of hidden hooks and tricks.

    - There is no way to attach custom mental ray shader to maya hair/fur.

    - Maya light linking in heavy scenes makes Mayatomr export slower by an order of magnitude