+1.
On 11/9/2012 1:31 PM, Greg Punchatz 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 <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:*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
<mailto: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 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:*softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>
[mailto: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
<mailto: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
<mailto: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.
