pipeline development theory 2005-06-15 - By ozu's mailbot
Back
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859 (See http://ISO-8859.ora-code.com)-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Yep absolutely. As soon as you step into long form production you need
to start to realize that:<br>
<ol>
<li>You can't possibily have one 3D scene or file in any package
hold the entire amount of information needed to produce a shot.</li>
<li>Not all the information in that scene changes at the same speed.<br>
</li>
<li>A single person can't possibly work on all aspects of the scene
at once nor can you afford to work on them sequentially.</li>
<li>No scene is exactly alike but there is often a lot of saving to
be done if you can re-use common components</li>
<li>some pieces have to be ready before you can build other bits<br>
</li>
<li>Things break. People make mistakes. People change their mind.<br>
</li>
</ol>
Even if your only tool is XSI, the rules above would apply, but you'll
often find out that in a large project, you have many different
software packages which introduce their own peculiar advantage and
peculiarities.<br>
<br>
So at the end of the day the "pipeline" is not a fixed things like the
plumbing in a house but really the same thing as what happens on a film
set. The lights plugs into the board, the camera can be bolted on top
of the luma-crane, but also some bit gets help together by bits of
sticky tape, or you run out and grab a couple of "stage hands" (which
are usually attached to bodies) and tell them to stand somewhere and
hold bits of cardboard to reflect the light.<br>
<br>
The pipeline game consists in identifying the requirements of the
productions, recognise that they will change, and control that change
(or adapt to that change) and make sure that you have a system where
you can automate the assembling / updating / dissambling process of all
the elements that you have so you can make sure that changes only
affect what's needed.<br>
<br>
I find that having multiple software packages sharing the same pipeline
is actually much better than having a single software, because it
forces you to think in a disconnected manner about your assets, rather
than just having people work on something and passing it on. Complex 3D
software and the way we use them in production means that digital dust
accumulate very quickly, and the act of exporting to a different format
and re-importing rather than save/load means that you always start in a
known clean state. <br>
<br>
oO<br>
<br>
<br>
Bradley R. Gabe wrote:<br>
<blockquote cite="mid6.1.2.0.0.20050615134855.0398f4c8@(protected)"
type="cite">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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
1- Question: as far as the XSI world goes, is anyone doing stuff like
this?
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
2- Question: Brad and Kim, is this the kind of super secret stuff you
guys do on a
<br>
daily basis? Or is this still something thats over the horizon?
<br>
<br>
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.
<br>
<br>
3- Question: In XSI land we don't really have the power of the ASCII
based file
<br>
format. And reference models are still rough around the edges. Does
anyone
<br>
think (or know for that matter) this kind of self weaving meta-data
based
<br>
pipeline technology is something that could be developed for XSI at
this point?
<br>
Or are we a few features and APIs short?
<br>
<br>
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. <br>
---
<br>
Unsubscribe? Mail <a class="moz-txt-link-abbreviated" href="mailto:Majordomo
@(protected)">Majordomo@(protected)</a> with the following text in
body:
<br>
unsubscribe xsi
<br>
</blockquote>
</body>
</html>
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
