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. On 06/01/16 5:05, Juhani Karlsson wrote:
|
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.