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 <ml...@carbinestudios.com> 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:* softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ed Manning > *Sent:* Thursday, November 08, 2012 12:06 PM > *To:* softimage@listproc.autodesk.com > > *Subject:* Re: Mental Ray Features, Integration & Autodesk's failure**** > > ** ** > > On Thu, Nov 8, 2012 at 2:05 PM, Matt Lind <ml...@carbinestudios.com> > 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. > > **** >
