That's great for productions with short timelines as they don't have to worry about the legacy support. The project I'm on now has been going for nearly 8 years and is expected to go for another 5-10 years. In such an environment it's not unusual for an asset to be created and then not touched again for years at a time. When it is touched again, it's usually to fix a bug reported by QA or a customer playing our game. We absolutely cannot afford to have entire systems such as the particle system pulled out from under our feet like that because if such an asset has to be exhumed for a bug fix, we cannot open the scene file anymore and essentially lose the asset. Fortunately we weren't using the particle system at the time so we weren't affected, but the point remains. If we had been using the old particle system and that switch were made today...that would effectively lock us into whatever version of the software we were using at the time for rest of the project. I'm not too keen about spending the next 10 years in Softimage 7.5. Not only for the lack of modern features, but the support issues that go with trying to maintain and keep an old product alive that nobody will support. Just the other day our 7.5 licenses expired. That's right, 'expired'. It shut our production down for a day unexpectedly. I'm sure Autodesk would like to continue receiving subscription payments from us. So there has to be a better path mapped out than what Softimage did with migrating to ICE cold turkey. And that involves better planning of features from the get-go instead of frankensteining them on later. If a cold turkey switch must be made, then the legacy support needs to remain now matter how painful it is to maintain as there are customers with a lot at stake.
Matt From: [email protected] [mailto:[email protected]] On Behalf Of Meng-Yang Lu Sent: Friday, November 09, 2012 11:02 AM To: [email protected] Subject: Re: Mental Ray Features, Integration & Autodesk's failure Well, they did do this with ICE deprecating the old particles system. I still remember reading "You know this day was coming." in the XSI docs. Now look at the huge forward leap that ICE has provided to FX in Softimage. I think when you have a huge number of artists willing to dump one system for a completely new system, the value of retaining legacy pretty much goes out the window does it not? I would've taken that as a wake up call. MR and Autodesk need to understand this, not just on rendering, but multiple aspects of cg production. -Lu On Fri, Nov 9, 2012 at 10:52 AM, Matt Lind <[email protected]<mailto:[email protected]>> wrote: 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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ed Manning Sent: Thursday, November 08, 2012 12:06 PM To: [email protected]<mailto:[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.
