pipeline development theory 2005-06-15 - By Bradley R. Gabe
Back
I propose that we stop using the "pipeline" buzzword as often as we do.
It's a bit of a misnomer when it comes to production planning. Pipelines
happen, with or without advanced planning, because it's just the story of
how your data went from start to finish, and what were all the stops along
the way.
The whole complexity of a large scale 3D production is a monster, almost
something organic. Every piece of data, from geometry, rigging, animation,
textures, etc, is linked in a multi-dimensional fashion that not only
changes from one artist revision to the next, but must also accommodate the
evolution of the software. Meanwhile, the users are also evolving in skill
and techniques. Add to this the fact that much of the work we do is as
inventive as it is artistic, and you have your basic managerial nightmare.
The misused concept of "pipeline" is the schematic snapshot of what is
really an amorphous abstraction, mostly to appease the folks who need some
concrete base from which to make budgetary decisions.
The word we should bandy about in lieu of "pipeline" is probably
"framework." That is, the set of production standards across the board that
make it possible to share data and link assets between departments. The
better your standards are followed, the easier it is to share, link, and
automate. The more accommodating your standards, the easier it is to evolve
and adapt over time and to handle the daily unexpected. A good way to
visualize this is to think of the plumbing section at your local hardware
store. Lots of different fixtures and pieces, all following the same
standards. When it's time to hook the sink into the sewer (the literal
pipeline), and the real world measurements don't match the engineering
blueprints (the schematic), you can still count on finding the right
combination of components to finish the job, quickly and easily.
1- Question: as far as the XSI world goes, is anyone doing stuff like this?
Absolutely. Of course, there's adding XSI as an arm to your existing
framework, then there's also using it as the main tool linking everything
else together. I've seen examples of both. As an extension arm, a lot of
what makes XSI powerful ends up getting washed away. The same thing happens
if XSI is forced to work as if it were another program, which also happens.
As for database and versioning repositories, that is always at the core of
a good framework, but it shouldn't be the main focus to the extent where it
becomes a limiting factor, which I've seen. As for integration of these
tools, XSI's ActiveX foundation provides a huge pathway for all kinds of
technologies. What Helge and the folks have done at Omation in a relatively
short period, for example, is pretty amazing, but it's just scratching the
surface of the possibilities.
2- Question: Brad and Kim, is this the kind of super secret stuff you guys
do on a
daily basis? Or is this still something thats over the horizon?
There's nothing super secret about it, to be honest. Developing a good
framework that works for XSI comes mostly from experience in using XSI and
knowing its strengths and limitations, and from learning from all kinds of
amazing people who have gone through and solved the same production trials
and errors over the years, but in different ways. Since every production we
work for is different, we're still adapting, which is to be expected. So
mostly what we are doing, is building up a stock of components in order to
re rout that proverbial sink.
3- Question: In XSI land we don't really have the power of the ASCII based
file
format. And reference models are still rough around the edges. Does anyone
think (or know for that matter) this kind of self weaving meta-data based
pipeline technology is something that could be developed for XSI at this point?
Or are we a few features and APIs short?
As Helge said, it's mostly there, but probably still needs a slight nudge
in a couple of areas. Not enough though where it isn't a strong and viable
solution. We're all making sure Softimage is acutely aware of this, and
they're usually really good about coming around. Also, I believe that
framework and data granularity are like the yin and yang of pipeline, so
when one is weak in an area, it can be compensated for by strengthening the
other.
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
