Sorry. I had to comment, since a lot of misconceptions and just plain wrong information was being discussed about mental ray.
I work at ILM where we daily use both prman and mray and I personally have about 5 years of experience with each package, as both an user, and developer writing shaders... and can tell you stories of pulling my hair with both
This is sort of a list of good and bad points of each renderer.
1) mental ray is a hybrid renderer. As a matter of fact, it has been such since v2.0. A hybrid renderer is new to prman, but it is NOT new to graphics community. Besides mray... lightwave, maya, etc. are all hybrid renderers and have been so for quite some time.
This means that indeed you can use the package only on scanline mode if no tracing is required. Most good hybrid renderers like mental ray, prman and lightwave, can mix rendering scanline with raytracing within samples, even. Bad ones can't or have horrible limitations (maya comes to mind).
2) mental ray3 IS a micropolygon renderer, which is not based on a reyes architecture. The talk of not being able to do driven displacements thru the hypershade is just bogus.
mray is a micropolygon renderer that it is based on an object caching architecture (this is both good and bad). Instead of splitting objects per buckets, objects are split into subobjects (think of doing dicing in screen space vs. world space, I guess). The quality of displacement mapping has little or nothing to envy prman anymore. The object caching is also less subject to patch cracks as prman is. mray, unlike prman, tries to always maximize the memory consumption and keep as many triangles in memory as possible when raytracing (ie. the caching is less agressive). This is not bad, it makes the renderer faster during traces, but yes, when you fire a mray render without specifying memory limits, you will immediately see it try to take over as much memory. Acceleration of raytracing is done by hierarchical grids or bsp, albeit bsp is still the preferred approach.
mray3.1 was the first implementation of this and it did suffer from some bsp creation problems which would spike memory like crazy albeit was usuable already for most projects. mray3.2 beta (not yet released) has addressed most of the issues and solidified the architecture more. Currently, I can already testify that the object-cache architecture is already proving to be as successful as prman's reyes ones in many scenes, more so when raytracing is involved. Still, raytracing of micropolygons IS expensive compared to just scanline rendering or to raytracing objects with good but not micropolygon tesselation. mray still provides the best (read fastest) implementation of this I have ever tried. Over the Christmas break, I raytraced scenes of over 10,000,000 polygons with little issue and under 2.5hs. Still, as we throw more and more complex cases, we do find bugs and issues and we usually report to both vendors as problems they need to address. For example, I recently did find an obscure bug with the caching being flushed too much leading mray to technically render 150,000,000 ( yes, that's 120 million triangles) due to re-tesselation. What surprised me was that as ugly bug this was, the architecture handled it and albeit it took long (16 hrs), it worked just fine. And 16hrs for 120million triangles sounds REALLY cheap to me, actually --- specially considering the code doing most of the re-tesselation was mine and not optimized, and not as good as mray's tesselation code
3) subdivision surfaces. mental ray provides a very comprehensive subdivision surfaces package which is sold as an add-on shader library. It is a silly marketing decision. As such, indeed most translators do not support it. Also, regarding its being sold in the USA, not sure if it could expose mray to legal action by pixar, since pixar holds some rather obvious patents on subdivision surfaces.
The subdivision kit is more complete in terms of subdivision types and in terms of hierarchical subdivision than prman is, but it does not resolve subd's to bsplines as in prman implementation.
4) mental ray's architecture has proven time and again to be MORE flexible than prman's, not less. We usually try to do everything with prman when possible since our pipeline is built with it more in mind and due to having been used at ilm for so long, we also have many more artists familiar with it. But albeit SL is nice and friendly, prman's lack of openness bites us whenever you want to do anything BEYOND SL. Technically, we do have ways (technically and legally) to hack into prman code. However, we have very few people who can do so (technically and legally) and many times we don't have the time. And prman's DSO architecture is simply not mature enough. mental ray suffers from none of that (basically, anyone that can code C can be writing mray shaders in no time and the API is way more ope). As such, when prman fails or is not good at a certain thing, mray usually ends up being used as a complement ( raytracing, blobbies, atmospherics, etc).
5) mental ray's scanline rendering is actually FASTER than prman. Yes, you won't hear this very often, but it is true. Now, this does not mean the renderer is faster, thou Let me explain:
mental ray's scanline renderer is on average about 3 times faster than prman10 and ~1.5 than prman11, when equivalent shaders are used for your average ilm creature (say, our superduper plastic shaders with million of knobs). This is so for preview renders without motion blur.
What DOES make prman amazingly fast during scanline renders is this great fact:
When motion blur is on, performance hit for any prman render is (usually) less than 50% of what it was without.
NO renderer on the market is even close yet to offer this... I know, we usually try them all.
With mental ray (and most other renderers), motion blur implies about a rather constant 500% increase in render times at least. This usually offsets ANY benefits of the mray scanline renderer when motion blur is on. Many places only turn on motion blur for final renders. Not so at ilm. EVERY one of our renders is motion blurred. Usually our supervisors require it. Kind of silly, perhaps. But certainly doable for prman and it is the one feature that makes prman worth its price tag, in my opinion.
And yes, you can do tricks like 2D motion blur to compensate... they just don't look as good, that's the problem.
Now, that's for scanline rendering.
For straight raytracing... prman is 5 to 10 slower than mray. No suprise there. After all, this is Pixar's first implementation of raytracing. It is likely to get better with newer versions.
With raytracing and motion blur on ... well, no miracles here. We usually try not to since it is usually too expensive with any renderer. However, mental ray is still better. As slow as it is, prman is (and I'll be nicely optimistic here 5 to 10 times slower, without even mentioning the other issues about it.
For global illumination ( final gather / caustics ), mray is slightly ahead in most aspects while prman is ahead on at least one. However, speed and quality are relatively comparable and the differences will hardly make any difference to your average user: mray supports caustics and volume irradiance while prman has a more flexible api to work with irradiance caches in shaders.
prman is king in terms of primitives ( mray lacks CSG, built-in blobbies, sphere primitives, no point primitive, etc. and mray's hair is very new and not production proven ). mray's only strength here is support for high order curves and surfaces (as those used in CAD and engineering).
mental ray's basic shadow mapping support is now much cheaper than prman since they can be created on the fly at any resolution with little performance hit. On prman, a separate pass is always required. Prman now supports deep shadow maps which are great for volume effects and more so for hair. mental ray shadow maps are not yet deep shadow maps, meaning hair shadows are still better raytraced right now.
Prman's atmospheric shaders are slow at best and not too great. mental ray shines in this allowing you to create anything from blobbies shaders to very fast raymarchers. The latter package also has some internal handling of in/out volumes to allow intercrossing and travelling thru volumes.
Prman allows stitching of subds to handle displacement without cracks. Note however, that this is only for subd's not for generic patches. mental ray has stitching for patches, but they do not work for displacement.
RIB format is slightly more compact than mray's .mi2 format, but MUCH harder to debug and read, since it is ALL binary, unlike mi2 which is a hybrid format. RIBs are also more compact if you spit them in a hierarchical fashion, making them even harder to read and debug.
RIBs were originally a standard that did not catch on mainly due to Pixar still keeping hold on the copyright and licensing of it. However, in the past few years, other renderers have indeed started using the RIB as an input mechanism. This is both good and bad. It means the standard has already deviated but it also means that if you'd like NOT to use prman, you can switch to other competing products much more easily than before.
mental ray's format is as much a standard as prman's rib is, albeit no other renderer uses it yet as input. It supports shader networks, user data, and geometry instancing which ribs do not. More important, it supports progressive scene changes, for IPR functionality. It also does NOT work hierarchically, which is a big relief.
RIBS parameter passing and attachment of variables to geometry is VERY elegant, and although the same can be done in mray, it is not as nice. Only phenomena is elegant in mray.
PRman works with a SIMD architecture while mray does not. This is the other BIG plus for prman. This allows prman to calculate derivatives for antialiasing shaders trivially, while in mray, the shaderwriter has to do more work for that.
Now, however, that raytracing is introduced in prman11, the benefit of prman SIMD becomes less, since afaik, neither renderer does derivatives calculations beyond the first ray hit (could be wrong about prman, need to recheck the latest one). The only package on the market that was superior in this aspect was the now defunct Entropy, which did allow them.
In terms of documentation, mray's documentation is and has always been poor at best, lacking examples. Prman documentation while far from being great is full of examples and the new application notes for raytracing are simply outstanding.
For both renderers, however, it is still recommended to get the publication books sold.
mental ray integrates seamlessly with a number of products on the market with more or less successful interfaces -- usually more tighly built around the package workflow. Currently 3DMax, Houdini, Maya, Softimage and XSI support it.
Prman's main translator is the one that comes with RAT (irma/mtor/slim combo). Houdini support is native. For max, you need something like MaxMan and for Soft, softman. There's also some very ugly lightwave support. For xsi, there's no option to spit out ribs.
Prman's stability is simply legendary and is no overstatement saying than some of the best programmers in the world have contributed to it. Simply put: what other software product can you say has lasted for over 20 years with little core modifications? When Pixar releases a new feature, it has usually gone thru about a year of testing internally, and it shows. Hard to find bugs in prman.
mental ray's reputation is shaky at best in this area. Many users tried pushing mray to do things it was never meant to do in its old times and to this day, mray still lacks that internal testing that it is so important. As such, whenever mray introduces a new feature, my guideline is to stay away from it until the following revision of the software.
In summary, if you can afford both, do so. Then you should learn what they are good for and not try to use a hammer when a screwdriver is better.
If you can afford one, look at the list of good/bad features above and choose. Yes... something, somewhere will not be possible or be as good or easy to do. Just know what that something is, and avoid doing projects that require that (or find creative cheats).
Finally, if not convinced with comments, try them yourself. Both Pixar and mental images offer demo versions of their products.
I work at ILM where we daily use both prman and mray and I personally have about 5 years of experience with each package, as both an user, and developer writing shaders... and can tell you stories of pulling my hair with both
This is sort of a list of good and bad points of each renderer.
1) mental ray is a hybrid renderer. As a matter of fact, it has been such since v2.0. A hybrid renderer is new to prman, but it is NOT new to graphics community. Besides mray... lightwave, maya, etc. are all hybrid renderers and have been so for quite some time.
This means that indeed you can use the package only on scanline mode if no tracing is required. Most good hybrid renderers like mental ray, prman and lightwave, can mix rendering scanline with raytracing within samples, even. Bad ones can't or have horrible limitations (maya comes to mind).
2) mental ray3 IS a micropolygon renderer, which is not based on a reyes architecture. The talk of not being able to do driven displacements thru the hypershade is just bogus.
mray is a micropolygon renderer that it is based on an object caching architecture (this is both good and bad). Instead of splitting objects per buckets, objects are split into subobjects (think of doing dicing in screen space vs. world space, I guess). The quality of displacement mapping has little or nothing to envy prman anymore. The object caching is also less subject to patch cracks as prman is. mray, unlike prman, tries to always maximize the memory consumption and keep as many triangles in memory as possible when raytracing (ie. the caching is less agressive). This is not bad, it makes the renderer faster during traces, but yes, when you fire a mray render without specifying memory limits, you will immediately see it try to take over as much memory. Acceleration of raytracing is done by hierarchical grids or bsp, albeit bsp is still the preferred approach.
mray3.1 was the first implementation of this and it did suffer from some bsp creation problems which would spike memory like crazy albeit was usuable already for most projects. mray3.2 beta (not yet released) has addressed most of the issues and solidified the architecture more. Currently, I can already testify that the object-cache architecture is already proving to be as successful as prman's reyes ones in many scenes, more so when raytracing is involved. Still, raytracing of micropolygons IS expensive compared to just scanline rendering or to raytracing objects with good but not micropolygon tesselation. mray still provides the best (read fastest) implementation of this I have ever tried. Over the Christmas break, I raytraced scenes of over 10,000,000 polygons with little issue and under 2.5hs. Still, as we throw more and more complex cases, we do find bugs and issues and we usually report to both vendors as problems they need to address. For example, I recently did find an obscure bug with the caching being flushed too much leading mray to technically render 150,000,000 ( yes, that's 120 million triangles) due to re-tesselation. What surprised me was that as ugly bug this was, the architecture handled it and albeit it took long (16 hrs), it worked just fine. And 16hrs for 120million triangles sounds REALLY cheap to me, actually --- specially considering the code doing most of the re-tesselation was mine and not optimized, and not as good as mray's tesselation code
3) subdivision surfaces. mental ray provides a very comprehensive subdivision surfaces package which is sold as an add-on shader library. It is a silly marketing decision. As such, indeed most translators do not support it. Also, regarding its being sold in the USA, not sure if it could expose mray to legal action by pixar, since pixar holds some rather obvious patents on subdivision surfaces.
The subdivision kit is more complete in terms of subdivision types and in terms of hierarchical subdivision than prman is, but it does not resolve subd's to bsplines as in prman implementation.
4) mental ray's architecture has proven time and again to be MORE flexible than prman's, not less. We usually try to do everything with prman when possible since our pipeline is built with it more in mind and due to having been used at ilm for so long, we also have many more artists familiar with it. But albeit SL is nice and friendly, prman's lack of openness bites us whenever you want to do anything BEYOND SL. Technically, we do have ways (technically and legally) to hack into prman code. However, we have very few people who can do so (technically and legally) and many times we don't have the time. And prman's DSO architecture is simply not mature enough. mental ray suffers from none of that (basically, anyone that can code C can be writing mray shaders in no time and the API is way more ope). As such, when prman fails or is not good at a certain thing, mray usually ends up being used as a complement ( raytracing, blobbies, atmospherics, etc).
5) mental ray's scanline rendering is actually FASTER than prman. Yes, you won't hear this very often, but it is true. Now, this does not mean the renderer is faster, thou
Let me explain:mental ray's scanline renderer is on average about 3 times faster than prman10 and ~1.5 than prman11, when equivalent shaders are used for your average ilm creature (say, our superduper plastic shaders with million of knobs). This is so for preview renders without motion blur.
What DOES make prman amazingly fast during scanline renders is this great fact:
When motion blur is on, performance hit for any prman render is (usually) less than 50% of what it was without.
NO renderer on the market is even close yet to offer this... I know, we usually try them all.
With mental ray (and most other renderers), motion blur implies about a rather constant 500% increase in render times at least. This usually offsets ANY benefits of the mray scanline renderer when motion blur is on. Many places only turn on motion blur for final renders. Not so at ilm. EVERY one of our renders is motion blurred. Usually our supervisors require it. Kind of silly, perhaps. But certainly doable for prman and it is the one feature that makes prman worth its price tag, in my opinion.
And yes, you can do tricks like 2D motion blur to compensate... they just don't look as good, that's the problem.
Now, that's for scanline rendering.
For straight raytracing... prman is 5 to 10 slower than mray. No suprise there. After all, this is Pixar's first implementation of raytracing. It is likely to get better with newer versions.
With raytracing and motion blur on ... well, no miracles here. We usually try not to since it is usually too expensive with any renderer. However, mental ray is still better. As slow as it is, prman is (and I'll be nicely optimistic here
5 to 10 times slower, without even mentioning the other issues about it.For global illumination ( final gather / caustics ), mray is slightly ahead in most aspects while prman is ahead on at least one. However, speed and quality are relatively comparable and the differences will hardly make any difference to your average user: mray supports caustics and volume irradiance while prman has a more flexible api to work with irradiance caches in shaders.
prman is king in terms of primitives ( mray lacks CSG, built-in blobbies, sphere primitives, no point primitive, etc. and mray's hair is very new and not production proven ). mray's only strength here is support for high order curves and surfaces (as those used in CAD and engineering).
mental ray's basic shadow mapping support is now much cheaper than prman since they can be created on the fly at any resolution with little performance hit. On prman, a separate pass is always required. Prman now supports deep shadow maps which are great for volume effects and more so for hair. mental ray shadow maps are not yet deep shadow maps, meaning hair shadows are still better raytraced right now.
Prman's atmospheric shaders are slow at best and not too great. mental ray shines in this allowing you to create anything from blobbies shaders to very fast raymarchers. The latter package also has some internal handling of in/out volumes to allow intercrossing and travelling thru volumes.
Prman allows stitching of subds to handle displacement without cracks. Note however, that this is only for subd's not for generic patches. mental ray has stitching for patches, but they do not work for displacement.
RIB format is slightly more compact than mray's .mi2 format, but MUCH harder to debug and read, since it is ALL binary, unlike mi2 which is a hybrid format. RIBs are also more compact if you spit them in a hierarchical fashion, making them even harder to read and debug.
RIBs were originally a standard that did not catch on mainly due to Pixar still keeping hold on the copyright and licensing of it. However, in the past few years, other renderers have indeed started using the RIB as an input mechanism. This is both good and bad. It means the standard has already deviated but it also means that if you'd like NOT to use prman, you can switch to other competing products much more easily than before.
mental ray's format is as much a standard as prman's rib is, albeit no other renderer uses it yet as input. It supports shader networks, user data, and geometry instancing which ribs do not. More important, it supports progressive scene changes, for IPR functionality. It also does NOT work hierarchically, which is a big relief.
RIBS parameter passing and attachment of variables to geometry is VERY elegant, and although the same can be done in mray, it is not as nice. Only phenomena is elegant in mray.
PRman works with a SIMD architecture while mray does not. This is the other BIG plus for prman. This allows prman to calculate derivatives for antialiasing shaders trivially, while in mray, the shaderwriter has to do more work for that.
Now, however, that raytracing is introduced in prman11, the benefit of prman SIMD becomes less, since afaik, neither renderer does derivatives calculations beyond the first ray hit (could be wrong about prman, need to recheck the latest one). The only package on the market that was superior in this aspect was the now defunct Entropy, which did allow them.
In terms of documentation, mray's documentation is and has always been poor at best, lacking examples. Prman documentation while far from being great is full of examples and the new application notes for raytracing are simply outstanding.
For both renderers, however, it is still recommended to get the publication books sold.
mental ray integrates seamlessly with a number of products on the market with more or less successful interfaces -- usually more tighly built around the package workflow. Currently 3DMax, Houdini, Maya, Softimage and XSI support it.
Prman's main translator is the one that comes with RAT (irma/mtor/slim combo). Houdini support is native. For max, you need something like MaxMan and for Soft, softman. There's also some very ugly lightwave support. For xsi, there's no option to spit out ribs.
Prman's stability is simply legendary and is no overstatement saying than some of the best programmers in the world have contributed to it. Simply put: what other software product can you say has lasted for over 20 years with little core modifications? When Pixar releases a new feature, it has usually gone thru about a year of testing internally, and it shows. Hard to find bugs in prman.
mental ray's reputation is shaky at best in this area. Many users tried pushing mray to do things it was never meant to do in its old times and to this day, mray still lacks that internal testing that it is so important. As such, whenever mray introduces a new feature, my guideline is to stay away from it until the following revision of the software.
In summary, if you can afford both, do so. Then you should learn what they are good for and not try to use a hammer when a screwdriver is better.
If you can afford one, look at the list of good/bad features above and choose. Yes... something, somewhere will not be possible or be as good or easy to do. Just know what that something is, and avoid doing projects that require that (or find creative cheats).
Finally, if not convinced with comments, try them yourself. Both Pixar and mental images offer demo versions of their products.
