easy to say if your average project lifetime is weeks or months tops, and if
going back into old projects is rarely, if ever, done.
This has nothing to do with being Old School, or “new tools having to act like
old tools”, you’re quite missing the point.
Film and Games projects can span years. (I hadn’t imagined the amount of years
Matt referred to – ouch)
Studios can maintain a library over the years and projects.
Being able to save data to a specific version, being able to load (within
reason) files from other versions, saving ascii data, more atomic data formats,
preserving and encapsulating data for non-installed plugins and shaders, data
licensing support for old versions... there are lots of aspects to this and
Softimage is not very accommodating in any of them – substantially less so than
the competition I might add.
Legacy support is the most viable option failing better solutions out of the
box - if this hinders forwards progress, its about time some better data
strategies were provided.
From: Stefan Andersson
Sent: Saturday, November 10, 2012 9:52 AM
To: softimage@listproc.autodesk.com
Subject: Re: Mental Ray Features, Integration & Autodesk's failure
+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 <g...@janimation.com> 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: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Meng-Yang Lu
Sent: Friday, November 09, 2012 11:02 AM
To: softimage@listproc.autodesk.com
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 <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.
--
stefan andersson - digital janitor - http://sanders3d.wordpress.com
