pipeline development theory 2005-06-15 - By Anthony Rossano
Back
I agree with all the prior august XSI heads.
I want to chime in with the human element, touched on a bit here and
there in prior messages.
A functional (evolved) company includes in the 'pipeline'
0) COMMUNICATION between people and departments and tasks
1) Standards for quality of work
2) Artist Process, and approvals
3) Linear movement of tasks through departments, with tracking
4) Accountability matched with Responsibility
5) Training. Not just of software tools, but also
show conventions
characters
story
company culture
network and filesystems
proper ettiquette
6) Enforcement of standards, conventions, best practises
with incentives
with penalties
7) A tech support system
and more, more, more.
think that the pipe is more the people, how they think and how they
COMMUNICATE rather than what format assets are stored in or tracked.
Also how they PERCIEVE the tools presented to them.
Peace out, yo.
ATR
ozu's mailbot wrote:
> Yep absolutely. As soon as you step into long form production you need
> to start to realize that:
>
> 1. You can't possibily have one 3D scene or file in any package hold
> the entire amount of information needed to produce a shot.
> 2. Not all the information in that scene changes at the same speed.
> 3. A single person can't possibly work on all aspects of the scene at
> once nor can you afford to work on them sequentially.
> 4. No scene is exactly alike but there is often a lot of saving to be
> done if you can re-use common components
> 5. some pieces have to be ready before you can build other bits
> 6. Things break. People make mistakes. People change their mind.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> oO
>
>
> Bradley R. Gabe wrote:
>
>> 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
>
> --- Unsubscribe? Mail Majordomo@(protected) with the following text in
> body: unsubscribe xsi
--
/* Anthony Rossano
Technical Director
arossano@(protected)
anthor@(protected)
jobs at omation!
www.byrecruit.com
*/
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
