I have to admit, since MR is a old renderer it has its flaws. I work with it since 1999 and I would say I know it quite well, even I never programmed shaders for it. One issue is DTR/ distributed tile rendering, it simply doesn't work reliable. Mental images/nvidia solved the memory overflow problem some versions ago (slave machines ran out of memory and crashed), but there still seems to be a problem when using satellite rendering together with BSP2. In some cases, the rendering hangs at 100%, not written to disk and you have to kill the process. It seems to not happen with BSP1 but since it's much slower especially when using displacement, it's not an option to use BSP1 just because of having satellite rendering to work. This happens with the render region as well as with batch rendering. I cannot say if this is entirely a MR bug or a softimage-MR thing or maybe a windows network issue.
However, it works with batch rendering when not using more than one satellite machine. The render farm here is set up this way (I'm probably one of ten ppl in the world who uses mental ray satellite rendering on a farm).
It would be nice though to have rock solid distributed rendering when dealing with large print resolution for example. I don’t think there is an internal limit in MR regarding the amount of machines. Of course its not unlimited, at some point Amdahl's law will kick in. The limitation of using five machines was simply a business/licensing decision, I guess. Imagine, beeing at a company with a larger render farm that artists can use interactivly. Would cause a bit of network traffic, yes but the workflow would be improved. It's even practical if the farm is rendering regular render jobs simultaniously. I once did some tests and the raysat.exe will use a higher priority than the batch.exe by default. There would be only peaks of CPU utilization on the farm when an artist draws a render region, so the delay for normal renderjobs would be negligible. A potential problem would be, that artists, having vast amount of render power, they'll put shitload of stuff in the scenes thats simply not renderable in the final animation. But I disgress.
Another issue probably is GI for animations, as it was discussed many times over the years. Even you can have flicker free GI in animations, it depends heavily on the scenario. The classroom scene, for example. Seems an easy scene,no? Well it's not. Add a skylight system and animate the sun from sunrise to sundown. I did many, many tests with FG and even with irradiance particles. At sundown you will have only a few, very bright spots that have to lit the entire room. Therefore you need an insane high amount of FG rays to capture the light an even then it will produce splotches in the last few frames. IP adresses this problem by analyzing the screen space, firing more IP rays towards bright spots. Similar to portal lights. It is great in terms of general light distribution and does not produce light leaks. But since it's also screenspace dependent, it will create problems where a lit surface is not directly seen by the camera. In this case, at certain areas at the window frames at sunrise.
Btw. while testing Redshift with the classroom scene I noticed a bug when using caustics. Nothings perfect. (However, the GI solution was blazingly fast and super clean).
All in all, I use MR in production successfully and I like it, but I would not say I love it :)
sven
What you say about update cycles is absolutly valid. In fact mental images did updates quite frequently. Not as often as chaos group with vray but at least several per year. I had a better and newer link including dates of bugfixes but I can't find right now. Heres an older list by AD:
http://docs.autodesk.com/MENTALRAY/2012/ENU/mental%20ray%203.9%20Help/files/relnotes/relnotes.html
A lot of fixes quite frequently as it seems. But since most of the costumers didn't use the standalone but the integrated version by its DCC developer the bugfixes were incorporated only once per year. Leaving costumers a year with a bug, that got adressed by mental images possibly just a week later.
@Sven's got some really deep honest points regarding mr.
@Matt Lind, any MR shaders you develop help a lot of people, who read this but can't participate either because they're not part of the list or this (will be) a cached google page. In representation of them: I vote YES, we do use MentalRay.
To this day I'm still contacted by peopñe who says: MR toon shader is the best out there. Softimage toon shader is the best. And that'd my personal use of MR: toon shading, normals, world normals... you know stuff that requires more of a compositor's cheme to arm a scene for cartoon renders.
I'm interested on advanced shaders because less parameters deal with the same amount of settings regarding out of the box MR shaders. Plus we all have seen your page over thr years, Matt, who are we kidding, really great tutos and SI help from you all these years. :)
Release the kra...(wait)... release the MR shaders...
Cheers.
On 3 Jun 2016, at 18:21, Jason S <jason...@gmail.com> wrote:IMO, what mainly hindered MR was reliable light transport (in animation) which is essential for realistic renders, and where FG can be difficult.
Something which also hinders Redshift to an extent, but the tricks used to circumvent flickering (similar to VRay such as pre-rendering 1 frame with super long motion blur running the entire length of the sequence while writing light cache points in one lightcache file )
... can be less of big thing to manage, but which is still is a thing to manage especially with deforming geometry... but which is also offset by the fact that Redshift is just so fast.
And I think the main advantage of Arnold is that it's just as flexible as MR (which is otherwise also very flexible) but with much better chances of fully lit renders being right the first time, which despite render-times themselves being longer (especially for interiors), would still eventually finish, being still somewhat faster than other pure raytracers
(Though vray pathtracing supposedly got faster, but don't know by how much)
Also for Redshift , while it's not as 'flexible' as Arnold or MR, it's still quite flexible while continuing to improve there, particularly for Store in Channel nodes which is great! :)