Raf basically said what I was trying to say in a shooting from the hip quick response that probably failed miserably. Either way I'm in agreement with Raf (look at that, you agree with an American, Raf!). The future seems to be platforms and frameworks to build out your pipeline tools as needed and in the way you want. You also have flexibility to change a deep level of structures your apps are running on.

As Raf pointed out it's clear to me especially after Siggraph that there is not going to be a one app to rule them all. It's going to be a mixed bag of apps with standard formats supported across them to pass the data back and forth and use the app best for particular parts of the pipeline.

So many companies branching out and incorporating open source solutions (again as Raf mentioned) and not being shy about it either. So many Siggraph talks this year talking about how they implemented an open source format and used it in their projects.

Do I want an Uber Autodesk app? No. I've lost trust at this point in AD and it doesn't make sense.

Eric Thivierge
===============
Character TD / RnD
Hybride Technologies


On August-06-13 1:10:47 AM, Matt Lind wrote:
I think the ‘age of the platform’ assessment will be restricted to
film/video as I see a fork in the road developing between games and
film/video pipelines.  Actually, it’s already been happening for many
years.

Traditionally games have borrowed film/video tools for 3D work because
needs were simple and the film/video tools could be bent to service.
But now as graphics hardware improves, games requirements are much
more demanding and divergent from that which film/video caters.

Film/video has always moved towards larger and larger datasets
requiring subdivision of labor to the N’th degree.  Quality was the
overriding factor.  If it takes N hours to render that one awe
inspiring frame, you do it. That growth requires asset management to
manage all the facilities and assets.  The assets last only as long as
the production, unless there is a sequel.  Each production typically
involves reworking and re-inventing the wheel unless you work at one
of the older mainstays that have significant R+D investment into their
pipelines.  Basically assets are generated, a picture is taken of
them, then they are dumped into a box where they sit on a virtual
shelf until needed again.  Kind of like the old gag on Popeye cartoons
where they chop down the redwoods, send them to the saw mill, then
whittle it down to a single toothpick where it’s shipped off in a box.

In games, it’s a bit different.  In the case of the MMO I’m working on
the assets must have a very long shelf life – measured in decades.
The assets contribute to live software environments, must be very
optimal, and are under constant iteration.  While growth is also
occurring in the games pipeline, it’s moving in a different direction
than film/video.  Games is moving fast towards ‘in context’ editing of
assets, as in, creating/editing the assets in the live game
environment.  To accomplish the feat requires being very tightly bound
to the runtime environment of the game engine.  Therefore a DCC
application which serves as a ‘platform’ will not serve any role where
the work is done in the game environment.  I would venture to say that
many games developers are actively pursuing the route of removing DCC
applications from their pipelines completely.  It will be many years
before it is actually accomplished, however.

I remember a discussion with former Softimage PM Gareth Morgan back in
the late 1990s where he said they were actively working to make
‘sumatra’ a game engine with DCC tools.  That vision is not far off
from reality. The only part he got wrong is the DCC application isn’t
the host, it’s the guest.

What you’ll see emerge in the games development arena for content
creation are application(s) which can attach live agents to the
content being created so it can be merged into the game environment.
In other words, something a game engine can host.  The difficulty
comes in the area of viewing the work.  Something like Fabric Engine
has its own language for compiling and preparing the assets for
display.  This is the exact same responsibility of the game engine.
While the DCC application clearly isn’t a solution here, the Fabric
Engine model isn’t a hands-down winner either (but much closer to the
correct solution).  It’ll be interesting to see how that problem is
addressed.

Matt

*From:*[email protected]
[mailto:[email protected]] *On Behalf Of
*Raffaele Fragapane
*Sent:* Monday, August 05, 2013 9:23 PM
*To:* [email protected]
*Subject:* Re: OT: Yost Group - related to the Naiad/SIGGRAPH discussion

Why Fanboi, and why conspiracy?

I consider Paul and Co. to be smart enough to know that that is
EXACTLY what they should be shooting for.

AD knows it themselves IMO, as does SideFX, and the Foundry, and many
others.

The writing couldn't be plainer on all walls that the industry is
shifting again.

From blackboxed, fragmented specialistic apps in the end80s to mid
nineties, to the rise of the artist friendly monolith in the end 90s,
to the monolithic but moderately open app from end-90s until now,
we're now moving fast towards a common stream of OSS standards which
will be injected into by various small footprint, very specialized and
tailored apps (ZB, Mari, Katana etc.), and have a layer floating on
top to interface pipe and content/operation management on top of that
will be platform centric.

You have pointed out bits of that youreself.

Maya and Soft are more and more used as mere scene assembly and
animation platforms. That type of approach is becoming more widely
available by the minute to smaller and smaller entities, even to
individuals. It's only the middle end caught into hard software locks
at this point.

The age of the platform is coming.
Everybody already manages shots with shotgun, assets with tank (or
perforce, or propietary, or what else you have it), models with ZB,
retopos with 3DC or Topogun, textures with mudbox or mari, does
effects in Houdini, or Realflow, hair is left to plugins (shave,
yeti), lights with katana, renders with PRMan, composites with Nuke,
finals with DaVinci...

Who caches with something other Alembic (or propietary formats) or
writes images other than EXR?

All UIs are Qt, threading is beind coalesced in fewer solutions by the
day, libraries emerge to abstract and generalise many things (OCL,
Thrust etc.).

What little is left out has initiatives that might be caught up on
(OSL, partIO, openVDB), or will one day see an alternative that will
become the standard.

What's left for Maya or Soft to do but assemblying assets and
rig/animation? Which are ultimately just scene Management tasks, a
specialized type of graph which, of the lot, is the most backwards and
dated of all sections of the pipe.

There will be churn, as always for a few years one sub-field using CGI
is left better or worse serviced than others, one size more or less
competitive, but I don't think there will be a next-gen big app, not
one as big (proportionally) as Soft was, or Maya is.

Fabric did the right thing, all they have to do is garner the
attention and sustenance to punch through the industry catching up to
the obvious through lean years.

On Tue, Aug 6, 2013 at 12:57 PM, Matt Lind <[email protected]
<mailto:[email protected]>> wrote:

And to throw some fanboi conspiracy theory gas into the flames:

If you integrate with all the DCC apps, you’ve essentially built up
the trust with all the user bases and have the ability to suck them
into your DCC of the future to reduce any and all risk of switching a
production pipeline to another base application.

At least give us a ray of hope, Paul. ;-)

Matt


Reply via email to