The sad truth is the rendering integration is not as independent as one would think or like. I've been writing mental ray shaders for a long time (10+ years), and even today am shocked how touchy Softimage is when loading a scene which uses custom shaders not installed on the current computer - 99% of the time it's a hang and crash. In order for me to load an old scene from, say XSI v2.0 when I was developing a particular shader, I have to have the shader from that era installed to get the scene open.
When you consider the rest of the rendering system is built like that, that's why a lot of stagnation occurs. Either AD has to be bold and say screw old content for the sake of progress, or we have a slow moving boat for the sake of compatibility. There's also the reality that when a system is iterated over the years, it requires more manpower to take it to the next level. V1.0 may take 2 people, but v2.0 might require a 3rd to help out because the system has gotten larger, more complex and with more moving pieces which must all be done in sync. There's also the fact the system must integrate with other departments such as UI, animation, modeling, and whatever else comes in contact. Over the years the trend has been to have fewer developers on staff. This creates a situation where it's not possible to roll out an iteration in a single release, but instead have to spread it out over two releases due to the constraints of resources. The only true way to get quick iteration is to keep the renderer a standalone and use cheap export scripts to dump the scene at the command line, but of course, that comes at the cost of user friendliness and iteration speed. Not too much different from the good-fast-cheap production triangle. Throw your dart. While shaders can be updated to have additional features, sometimes it's not possible to retain legacy look as some of the technology that needs to be bridged are mutually exclusive. A shader is a front end to those technologies, but to actually make it work as the user envisions is quite the beast. Mental ray does a pretty good job of being that front end, but to get the benefit requires an educated user. No amount of pretty UI is going to change that. That is what users must understand. Matt From: [email protected] [mailto:[email protected]] On Behalf Of Ed Manning Sent: Thursday, November 08, 2012 12:06 PM To: [email protected] Subject: Re: Mental Ray Features, Integration & Autodesk's failure On Thu, Nov 8, 2012 at 2:05 PM, Matt Lind <[email protected]<mailto:[email protected]>> wrote: No argument on the making existing tools work, but in terms of tool design you make the erroneous assumption everybody wants to create realistic looking renders like you. I've largely worked on non-photo real projects where those extra controls you dislike are absolutely necessary and often not enough. This industry is about making looks and scenarios. It's not always about recreating what you see in front of you. Actually, I agree completely. FWIW, I don't assume that everybody wants to create realistic looking renders. Sometimes I don't want to either -- it all depends on the needs of the job, and lately it's all been "make it look more real." My point was that it should be possible, but not necessary, to drill down into low-level functionality in order to do commonplace things. And for better or worse, plausibly realistic rendering is a very common requirement. To beat my car analogy to death -- it shouldn't be necessary for someone to know how to tune a fuel injection system in order to get their car to the supermarket. It's a great thing if someone does take the plunge and learn how to be a racecar mechanic or driver, but as you said, most people can't or won't do that. Anyway, even a racing mechanic doesn't want to break out his toolbox when he wants to go to Kwik-E-Mart. The sad fact is we have enormous variation in education and educability in our workforce, and even if we resist building for the lowest common denominator, we need to consider it when assembling our tools. It's easy to take this too far -- then you end up with C4D, which makes some hard things shockingly easy, but won't let you do some basic things at all. And as far as maintaining compatibility with legacy assets goes, I don't advocate trashing the legacy shader libraries and making them unusable. But is there any reason that, say, the default scene material couldn't be a BSDF version of Phong (or Blinn or Ward or Ashikhmin) with fresnel and energy conservation? Is there a reason the default light can't be, say, mib_photometric? Why shouldn't the default material be updated when technology advances? Wouldn't it help move people along by making the default versions of things be the latest ones rather than the oldest? You could always have a "Classic Mode" button for people who just don't want to change. Why not make improved versions of things in addition to retaining legacy versions? It's not like the legacy versions are being actively developed anyway. I'm sure the code in some of the shaders hasn't been touched in 15 years. I'd also be kind of shocked if making these additions required a compatibility-killing change to core application code -- if that were the case, it wouldn't be possible for people to make modern 3rd-party renderers like Arnold or VRay work with Softimage and Maya.
