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 <http://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]] *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]
<mailto:[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 3^rd 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]>
[mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *Ed
Manning
*Sent:* Thursday, November 08, 2012 12:06 PM
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: Mental Ray Features, Integration & Autodesk's failure
On Thu, Nov 8, 2012 at 2:05 PM, Matt Lind <[email protected]
<mailto:[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.
