Could not agree more! (except for the Racing Cars, as Taxi Drivers also earn money by just driving cars ;) ).
Guillaume On Fri, Nov 9, 2012 at 4:52 AM, Vladimir Jankijevic < [email protected]> wrote: > I see things a little bit different: > > Cars are not tools. The majority of people is not using them solely to > earn money by just driving them. One exception are Racing Cars and their > pilots. Cars are made to transport, to move things. That's basically only > one function. And they are particularly good at it. All the Airbags, Speed > Controls and so on are just addons that make that one function safer or > easier to use. You can drive without them. Of course there are different > addons for cars in different segments. Different types of cars target > different userbases. They are made differently and are specialized to drive > in specific ways. > Now look at our software, our tools we use everyday to do our jobs, to > earn money. They are huge complex packages trying to fit everything in one > big box. To please everyone, whatever need they have or in which segment > those people work. And they are particularly good at it (pleasing, that > is). The problem here is that our tools are a relatively new emergence. > Today's business strategies forced the developers of our tools to make them > this way. Our whole business segment is a big interdisciplinary pot. We > didn't had the time to develop sophisticated segment specific platforms > which are able to communicate with each other. It was easier to just make > one platform that does everything. And they do it particularly bad (the > work they should do). The complexity of what has to be done > is exaggerating. The time to support all of this is getting shorter and > shorter. How is this supposed to work? Imagine how bad our cars would be if > they would need to please everybody to do anything with them related to > movement. They would need to be able to build streets, fly, climb, drill > tunnels and make other cars to support what they are doing. This is just > an awful vision. > > Just ranting about how bad stuff is implemented is not going to help > anybody. It's too late. Today's tools as platforms are just too crippled to > really make a difference on how people do they work in the future. The > developers, or the managers and businessmen, need to sit back and try to > find new structures and new workflows in how we should be able to work. > The algorithms and implementation of them are very specific to the various > segments and trying to support all of it out of the box won't work anymore. > We need to leave stuff behind and go on. Change for the better. And not > just add more Airbags. > > Vladimir > > > On Thu, Nov 8, 2012 at 9:05 PM, Ed Manning <[email protected]> wrote: > >> 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. >> >> >> > > > -- > --------------------------------------- > Vladimir Jankijevic > Technical Direction > > Elefant Studios AG > Lessingstrasse 15 > CH-8002 Zürich > > +41 44 500 48 20 > > www.elefantstudios.ch > --------------------------------------- >
