+1 to what Greg said. If you want to go Old School, use the old tools. Dont try and make the new tools act like the old tools.
/stefan On Fri, Nov 9, 2012 at 8:31 PM, Greg Punchatz <[email protected]> wrote: > Screw legacy, software will never be clean or robust if you keep adding > new stuff while while keeping all the old krusty stuff around. > > If you need legacy tools use legacy software. > > Forward > > ------------------------------ > *Greg Punchatz* > *Sr. Creative Director* > Janimation > 214.823.7760 > www.janimation.com > On 11/9/2012 1:11 PM, Matt Lind wrote: > > 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]<[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]> > 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]] *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]> > 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. **** > > ** ** > > > -- stefan andersson - digital janitor - http://sanders3d.wordpress.com
