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 <etmth...@gmail.com> wrote: > 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. > > > -- --------------------------------------- Vladimir Jankijevic Technical Direction Elefant Studios AG Lessingstrasse 15 CH-8002 Zürich +41 44 500 48 20 www.elefantstudios.ch ---------------------------------------
