Anybody still using mental ray?

287 views
Skip to first unread message

Matt Lind

unread,
May 27, 2016, 6:28:24 PM5/27/16
to soft...@listproc.autodesk.com
While on the subject of nostalgia and recent release of various tools for
XSI.

I have a selection of mental ray shaders I wrote long ago still perfectly
valid as they're utility nodes for accessing renderer preferences, lights,
performing math, or other basic features missing from the native shader
library. Some have unique features, but also limitations due to mental
ray's architecture. If released, would anybody actually use them other than
for tinkering? As in, does anybody still use mental ray in a serious
production context where you'd benefit from such shaders?

Don't say yes because you want free digital swag.

Matt

------
Softimage Mailing List.
To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.

Sven Constable

unread,
May 27, 2016, 7:17:04 PM5/27/16
to soft...@listproc.autodesk.com
I use mental ray almost exclusively for any project so far, even I'm
evaluated arnold, redshift and maxwell. Maxwell is so far the most accurate
renderer I've seen so far in terms of light distribution in a scene and
nothing comes close to it in my opinion. It's amazing if you do product
rendering only. But it lacks in shader variety, softimage integration and
general tweaking, as mental ray has and allows. Arnold may be a killer for
big projects, heavy scenes but its expensive. Redshift is affordable,has
good GI for animations and the best integration in Softimage besides mental
ray (I'm still wondering how they managed to get the round corners shader
into RS! I was thinking it's a mental images/NVIDIA patent)
There are only two things that stopped me switching from mr to RS:
1. I don't want to throw away a expensive CPU based renderfarm.
2. mental ray still has more shaders. It's slow sometimes but it is rather
good when you want to do non physically based things. A bit like Softimage
itself, the all-purpose, swiss knife.

So yes, I use mental ray.
sven

Mirko Jankovic

unread,
May 28, 2016, 3:25:44 AM5/28/16
to soft...@listproc.autodesk.com
1. I don't want to throw away a expensive CPU based renderfarm.
It will be obsolete soon anyway so just make good planing for next render tool, CPU or GPU road. 

2. mental ray still has more shaders. It's slow sometimes but it is rather
good when you want to do non physically based things. A bit like Softimage
itself, the all-purpose, swiss knife.

First time I heard something like this for MRay. Mostly it is in line I wanna puke or quit 3d completely due to rendering part :)
When I discovered Arnold and then even more Redshift that is when a big issue I had with SI, ie rendering was solved and 3d was fun again.
MRay was PAIN non stop! Swiss knife.. yea could say that, got ton of things but nothing good for most of things :)

Redshift saved my 3d ;)
--
Mirko Jankovic

Need to find freelancers fast?

Need some help with rendering an Redshift project?

Matt Lind

unread,
May 28, 2016, 3:56:52 PM5/28/16
to soft...@listproc.autodesk.com
The people who complain the most about mental ray tend to be the ones who
never took the time to learn to use it properly.

If you read the manuals, mental images states some modes are more taxing
than others for rendering. For example, Segmented shadow mode incurs 15%
additional rendering time vs. the default shadow computation mode, and is
less stable inside of material shaders. Segmented shadows is currently set
as the default shadow computation mode. If you do most of your rendering in
passes, then you likely do not need segmented shadows and can revert to what
is now labeled "normal" shadow mode to regain some performance and
stability. If your render pass doesn't need lighting, then turn shadows off
completely. That's just one example.

For XSI v1.0 thru XSI v5.11, the default settings Softimage chose for mental
ray were fairly efficient, but users commonly complained about black spots
when doing renderings involving lots of reflection or refraction (because
they didn't increase ray depth) or anti-aliasing wasn't super smooth
(because they didn't set filter to 'lanczos' or 'mitchell' instead of
default 'box', or didn't adjust the adaptive sampling properly). In
essence, most complaints were due to user error - because users didn't take
the time to learn how to use the renderer

To alleviate support issues, Softimage redefined the default mental ray
settings in XSI v6.0 to what they are now - which effectively activates a
bunch of stuff you don't need majority of the time and does a lot of extra
work that never shows up in the final rendered image. This change can often
be blamed for inducing crashes and slower render times because many users do
not tweak the settings.

If you learn to use the renderer properly instead of using a 3DSMax
mentality of pushing a button and walking away, you'll get better
performance and stability. Much of that also involves strategy for setting
up the scene before sending it to the renderer - another area users make
gross mistakes because they don't take the time to understand the rendering
process.

Matt




Date: Sat, 28 May 2016 09:25:06 +0200
From: Mirko Jankovic <mirkoj....@gmail.com>
Subject: Re: Anybody still using mental ray?
To: "soft...@listproc.autodesk.com"

*1. I don't want to throw away a expensive CPU based renderfarm.*

It will be obsolete soon anyway so just make good planing for next render
tool, CPU or GPU road.



*2. mental ray still has more shaders. It's slow sometimes but it is
rathergood when you want to do non physically based things. A bit like
Softimageitself, the all-purpose, swiss knife.*

First time I heard something like this for MRay. Mostly it is in line I
wanna puke or quit 3d completely due to rendering part :)
When I discovered Arnold and then even more Redshift that is when a big
issue I had with SI, ie rendering was solved and 3d was fun again.
MRay was PAIN non stop! Swiss knife.. yea could say that, got ton of things
but nothing good for most of things :)

Redshift saved my 3d ;)

Mirko Jankovic

unread,
May 28, 2016, 4:01:02 PM5/28/16
to soft...@listproc.autodesk.com
there are some good points in there BUT if better results can be achieved faster and learn faster on another engine does it make sense to waste time learning inferior render engine instead?

also I do know much more experience people with MRay that even with knowing a lot more still had to spend wake nights waiting for crashes and issues on critical rendering that ofc needs to be done tomorrow morning :)

Derek Jenson

unread,
May 29, 2016, 9:36:02 AM5/29/16
to soft...@listproc.autodesk.com
I think the biggest problem with the stability of MR was with the concept of only releasing a single update once a year which was tided to the 3D program. That was unrealistic idealism. There was also pressure to give customers the lastest and least tested version of MR with each yearly DCC update. 3D is too bleeding edge for that release model to be stable. Being XSI's only renderer option for a long time, stability certainly became an issue.

If MR updates were released with the frequency (and flexibility of rollbacks) like all 3rd party engines, everyone would have fonder memories of the software.

The developers of MR also worked in complete isolation with regard to communication with their customer base. The RS guys have bent over backward to educate and update their clients, and I really appreciate the support. IMO, you can only partially point the finger at users for not using a software as intended. With information/training being so easily accessible now the "you're not smart enough to use software X" mentally of the early years is void. If a whole user base is struggling with a technology... then something with that tech is flawed; not the other way around.

The flexibility of MR and 3delight are unmatched (in  XSI), but the speed demands forced on this biz make Redshift indispensable for keeping pace.


From: mirkoj....@gmail.com
Date: Sat, 28 May 2016 22:00:28 +0200

Sven Constable

unread,
May 29, 2016, 9:40:34 AM5/29/16
to soft...@listproc.autodesk.com

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

Sven Constable

unread,
May 29, 2016, 11:08:21 AM5/29/16
to soft...@listproc.autodesk.com

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.

Matt Lind

unread,
May 29, 2016, 6:54:03 PM5/29/16
to soft...@listproc.autodesk.com
Most of your information is incorrect.

First, I never said nor implied "you're not smart enough to use software X"
mentality. I said most users do not take the time to learn the software to
use it properly. That has nothing to do with being smart or dumb. It's
about investing time to learn so you apply the principles correctly in
context. You can be the smartest person ever to walk the face of the earth,
but if you don't take the time to learn how your tools work, you should
expect many failures: http://www.dailyreckoning.com.au/images/dr20120709.jpg

Majority of artists I've dealt with in production have never once opened the
manuals to learn how to use the renderer. They rely purely on intuition
flipping switches that sound cool, then shove the scene off to be rendered.
When it fails to render, they complain and blame the renderer. Let's give
an actual example:

Many years ago I joined a feature film when it was already well beyond 50%
through production. they had a lot of problems with rendering trees. Scenes
would get pushed off to the renderer, but any scene with more than 3 trees
would crash taking the computer down. For several meetings there were
grumblings how mental ray should be ditched, so I was assigned the task of
researching the issue. Inside of Softimage the scenes looked fairly simple
and was very responsive to the mouse and timeline. A street with trees
lining the sides of the road. No more than 6 or 7 trees in view of the
camera at any one time. The tree trunks only had resolution of roughly
20K - 180K triangles depending on the tree, and each tree trunk had one or
two bitmap textures at resolution of 2048 x 2048 pixels in 16 bit color.
The scene as a whole had 30 bitmap textures, if that. I inspected the
shaders and didn't see anything other than standard phong, lambert, and
color correction nodes in the various rendertrees. No exotic features
activated either. Hmm, I thought. So I dumped to .mi2 files and rendered
using the mental ray standalone in heavy verbose mode to get more
information what mental ray was actually doing. Before it crashed, the log
indicated there were more than 20 billion triangles in the scene exhausting
available RAM. That's right, 20 billion - and the scene was still in the
process of loading. Naturally I'm scratching my head as to the source. So
I reopened the scene and took another look and that's when I discovered the
leaves of the trees were created with particle instancing. That is, the
artist created a single clump of leaves in very high detail (~15,000
triangles for a handful of leaves), and instanced them around to every
branch of every tree. When mental ray loaded the scene, it had to
dynamically allocate the memory to hold each instanced set of leaves. Since
each tree had hundreds/thousands of mounting points for the clump of
instanced leaves, the instancing inflated the triangle count to 20 billion+
exhausting available memory causing the renderer to crash.

If the artist had used a different approach to setting up the scene, such as
using a delay load geometry shader or modeling the leaves directly onto the
trees, mental ray would in turn use a different strategy in allocating
memory to render the scene and perhaps not crash. This is my point about
people needing to take the time to learn the renderer and the rendering
process, and stop blaming the renderer. 99% of artists don't do that. So
when they complain about mental ray in these contexts, what they're really
doing is shouting out their own lack of preparation. Again, it has nothing
to do with being smart or dumb, but it has everything to do with being
prepared and responsibility of learning tools of your craft.


Not sure of their present release schedule as I haven't kept up in the past
couple of years, but when I was more involved, Mental Images was in habit of
releasing patches and updates quite regularly. Often every few weeks.

What you have understand is the business relationship in how you access
mental ray rendering. Mental Images licenses their technology to other
businesses, like Autodesk. Autodesk is effectively the customer and the one
receiving the regular maintenance, patches, and support from mental images.
Autodesk in turn then integrates the rendering technology into their DCC
products and extends their own technical support to their customers. It is
Autodesk who decides to only update their integration of mental ray once or
twice per year, not mental images. So direct your complaint to Autodesk on
that front. This arrangement is also why you get integrated mental ray and
not standalone mental ray. That was likely a cost driven decision as
standalone licenses would cost more (read that as, having standalone
licenses in addition to integrated rendering would cost more). Softimage|3D
was the last application to offer both. In this scenario, Autodesk is like
your local reseller - they're intended to solve your problems, but actually
just get in the way.

If you want better support per your complaints, you can purchase directly
from mental images and get mental ray standalone and more frequent updates.
It's the same rendering technology, but unhindered by the overhead of the
DCC which translates to faster performance and more stability - especially
at load time when integrations suffer the most. Your DCC also only exposes
options to rendering features which the DCC supports, but Mental Ray has
many additional features beyond that - some of which would solve problems
many complain about. All those check boxes, sliders, and menus you access
in your DCC are command line flags you can activate with the mental ray
standalone, but mental ray has additional flags. I have used both
integrated and standalone rendering with mental ray quite a bit over the
years, and have also written a considerable number of shaders. standalone
is by far more stable, faster, easier to debug/troubleshoot, and scales very
well. No it's not perfect, but for pure rendering it beats integrated
rendering hands down. A lot of that is due to the integration, not the
renderer itself.

So about your whole 'user base is struggling' comment.... that's back to my
earlier point of not taking the time to learn. when I started using mental
ray back in the 1990s, I was just an artist/animator. I didn't know how to
code. I was working in games and had to make cinematic sequences for a game
called "SnowCrash" that never made it to market. I had to do a lot of
futuristic stuff on a budget and thought mental ray would be a good medium
for generating special effects with the OZ shaders and rendermap.
Unfortunately, I didn't know how to use mental ray and the Softimage|3D
documentation was less than useful as Softimage's concept of materials,
lighting, and other techniques were often backwards. That's when I cracked
open the mental images written documentation for mental ray and began
reading. While some of the documentation was terse or organized in a way I
didn't exactly consider user friendly, the programming documentation was
very logical, straightforward and to the point which actually made it all
make sense. The coded examples were very well written for the purpose of
being informative how the renderer actually works. that in turn gave me
insight how to use mental ray inside of Softimage|3D, and inspired me to
learn to code so I could write shaders to enhance my artistic experiences.
that effort to learn how the renderer worked paid dividends later in my
career and prompted me to pursue a computer science degree.

RedShift is in a different league of renderer, being hardware based, and is
justifiable in the context of this discussion as it offers a very
significant benefit over mental ray. My main argument is refuting the idea
of using a competing renderer n the same class at additional cost when it
has negligible advantages in the holistic context such as Arnold or
3Delight. Sure each renderer has it's pros and cons, but to spend money on
them and claim they're easier to learn when you haven't taken the time to
learn the renderer you already have and paid for - that's not a solid
argument. I'm not saying there aren't situations where a move to another
renderer is warranted.

Matt




Date: Sun, 29 May 2016 06:35:48 -0700
From: Derek Jenson <derek...@hotmail.com>
Subject: RE: Anybody still using mental ray?

I think the biggest problem with the stability of MR was with the concept of
only releasing a single update once a year which was tided to the 3D
program. That was unrealistic idealism. There was also pressure to give
customers the lastest and least tested version of MR with each yearly DCC
update. 3D is too bleeding edge for that release model to be stable. Being
XSI's only renderer option for a long time, stability certainly became an
issue.

If MR updates were released with the frequency (and flexibility of
rollbacks) like all 3rd party engines, everyone would have fonder memories
of the software.

The developers of MR also worked in complete isolation with regard to
communication with their customer base. The RS guys have bent over backward
to educate and update their clients, and I really appreciate the support.
IMO, you can only partially point the finger at users for not using a
software as intended. With information/training being so easily accessible
now the "you're not smart enough to use software X" mentally of the early
years is void. If a whole user base is struggling with a technology... then
something with that tech is flawed; not the other way around.

The flexibility of MR and 3delight are unmatched (in XSI), but the speed
demands forced on this biz make Redshift indispensable for keeping pace.

Pierre Schiller

unread,
May 29, 2016, 7:06:18 PM5/29/16
to soft...@listproc.autodesk.com

@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.

Chris Marshall

unread,
May 31, 2016, 10:48:22 AM5/31/16
to soft...@listproc.autodesk.com
I haven't read much of the above, but I'm still happy using MR. Should I have switched!?

Chris Marshall
Mint Motion Limited
029 20 37 27 57
07730 533 115

Matt Lind

unread,
May 31, 2016, 7:16:30 PM5/31/16
to soft...@listproc.autodesk.com
Thanks for the endorsement, Pierre.

However, don't get too excited. Majority of the shaders were written
between 2001-2004 with the idea of creating a utility node library to expose
features softimage was not exposing in their own shaders. Basically, I
wanted to expose what shader writers commonly use in their code so they
wouldn't have to write code anymore to prototype shaders. I also wanted to
homogenize workflow in the render tree to be more consistent with functions
you find outside the render tree. For example, applying a texture to a
light and be able to control projection method, tiling, repeats, flip/swap
uv, etc.. just like you do with textures applied to geometry, and have it
work on any type of light (point, spot, infinite, ..)

Most of my more ambitious efforts are owned by my former employers.


Matt





Date: Sun, 29 May 2016 17:18:51 -0500
From: Pierre Schiller <activemoti...@gmail.com>
Subject: RE: Anybody still using mental ray?
To: soft...@listproc.autodesk.com

@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.

Sven Constable

unread,
May 31, 2016, 9:11:35 PM5/31/16
to soft...@listproc.autodesk.com
Infinite lights with texture control? That's flipping amazing. With the
words of Morris Day: Release it!!!
sven

Morten Bartholdy

unread,
Jun 1, 2016, 4:48:42 AM6/1/16
to soft...@listproc.autodesk.com
I understand what you are saying Matt about learnign how to properly use tools beore complaining, but I am one of those who have used MR extensively in production for animation all the way back from when it was released for Softimage 3D and onwards, ie. many, many years. I had to learn how to use it in depth to get what I wanted, and the last years I used it I really hated it for wasting so much of my time with technical issues.

It was a blessing for Softimage 3D (having used the old built-in raytracer since 1992) and it continued for quite a while to be a strong player in the field until Mental Images somehow managed to drop the ball.

I would say it is (still) a very good renderer for still frames - great integration with XSI and lots of good shaders and utilities. They never manged to make Final Gathering really good for animation though, and GI was just plainly a pain to use. FG combined with motionblur and DOF is pretty much not possible for production in MR. I can't even begin to count the hours I have spent trying to fix stuff that would not render properly, crash, render with ugly artifacts, or find some sort of workaround for issues caused by MR, and then all the layers I have had to create to make useful motion vector passes for scene with a lot of depth and stuff in them.

I hated MR for years, found some relief in 3Delight along the way and found Arnold absolutely liberating, making it fun again to shade, light and render stuff, not looking back once.

Nowadays with offerings like Arnold, Redshift and several others (Vray I consider a bastard halfway between the bliss of Arnold and the dragging mess of Mental Ray) I would never consider using Mental Ray except perhaps for baking textures, because those tools really work well and Solid Angle never really gave it much attention.

All this said, I think a lot of users out there still use Mental Ray effectively and I consider anything that can strengthen the XSI community valuable, so by all means release your stuff.

My two cents - peace
Morten

Juhani Karlsson

unread,
Jun 1, 2016, 5:05:52 AM6/1/16
to soft...@listproc.autodesk.com
The quality of Softimage productions stood out with Arnold and it was for me clear moment when Softimage actually became great for rendering. For many years MR was the bottleneck imo.
Other products had plenty of more capable third party renderers at the time. Now everyone is doing more or less similar stuff so it dosen`t matter that much.

- J
--
-- 
Juhani Karlsson
3D Artist/TD

Talvi Digital Oy
Tehtaankatu 27a
00150 Helsinki
+358 443443088
juhani....@talvi.fi
www.vimeo.com/talvi

Derek Jenson

unread,
Jun 1, 2016, 1:09:22 PM6/1/16
to soft...@listproc.autodesk.com
Hey Matt,

Sorry for my late response, just getting around to reading this thread.

Matt, I can tell by your reply to my post, my words were received in a way I didn't intend.

I certainly didn't mean you were saying "you're not smart enough to use software X". Didn't mean that at all. But I've been at this for some time, and in the past many tech providers really played off the "high-end" mystic. Not interested in getting into a conversation about who those providers were, but will say I've always felt it was an excuse to not invest time & resources toward training, documentation, and support.

I don't know if that can be denied, as it has always been present in this industry.

Anyway... I should have used better wording. Sorry about that. Cheers!

Jason S

unread,
Jun 3, 2016, 12:34:51 PM6/3/16
to soft...@listproc.autodesk.com
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! :)

Otherwise, any of these renderers mostly made their way, and are arguably still best handled in the RenderTree, traditionally because of it's interface (now more or less everywhere), but still because of on the fly compounding and other things (like reliability) that greately ease authoring of more elaborate shader networks.

Jordi Bares

unread,
Jun 3, 2016, 1:29:25 PM6/3/16
to soft...@listproc.autodesk.com
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.

very true

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! :)

IMHO Mental ray still was a contender unless you started using motion blur, depth of field and displacement and that is where Arnold really cracked and the transition obviously started quickly.

Now we are moving towards GPU based renderers like redshift because the times are simply acceptable again.

I love Mantra but render times, when compared with Redshift, are something to consider but hey, RS coming to Houdini so problem solved
jb
Reply all
Reply to author
Forward
0 new messages