pipeline development theory 2005-06-15 - By Matt Lind
Back
Pipeline development is several components working together to form a larger
cohesive framework which work gets done. Obviously each project and
pipeline is different, but they often share common steps along the way such
as pre-production, production, post-production, etc...
A good pipeline is built from information gained in the following areas:
- planning / analysis
- experience
- common sense
Analysis is about investigating your needs, your ability to provide, and
finding out what you know vs. what you don't know. It's the easiest part,
but takes a long time to complete as it involves a lot of legwork and elbow
grease to ask questions, talk to others, then compare notes to reach a
decision.
Experience allows you to project with a relative degree of accuracy what can
go wrong and how much time/energy it will take to either fix the potential
problems or come up with a preventative measure before they occur. This is
where apply what you've learned from past mistakes made by yourself or
others to curtail future problems. What NOT to do is often just as
important, or more so, than what TO do. I could give several courses on
what NOT to do based on my past experience in many studios, and it's always
served me better each time I take on a new job.
The 3rd one most frequently slips through the cracks, but is probably the
most important piece of all - common sense. There are a lot of companies
that spend god awful amounts of money on the best software, best hardware,
posh office space to make artists 'creative', etc... but they continue to
screw up because they don't use common sense to address simple issues before
they balloon into big problems. This includes not just the setup of the
company, but also how to keep it running after production has started. How
do new hires get trained? Who trains them? Does everybody use any tool
available or do they stick to a tight regimen of 'approved' tools in an
isolated arsenal? How do people communicate what they have done or what
they need to do when tasks transfer between departments? How reliable is
the system? Is it a system anybody can adapt to, or does it require
additional training and intellectual capacity for it to function properly?
The list goes on. Generally speaking, the best solutions are simple
solutions that can accomodate the lowest common denominator. You could have
a $2 million dollar cloth simulator to automatically spit out physically
accurate cloth simulations, but if nobody knows how to use it, it's useless
and no better than not having a cloth simulator at all.
I guess what I'm trying to say in all this blather is that pipeline
development isn't purely about booksmarts or XSI smarts - it's a small
portion of the big picture. Common sense and other basic planning will get
you further. The magic comes from understanding how people will actually
perform within your pipeline rather than how you desire them to perform in
your pipeline, then adjusting all the factors accordingly.
Matt
-- ---- ---- ---- ---- ---- --
Matt Lind
Animator / Technical Director
SOFTIMAGE certified instructor:
SOFTIMAGE|3D
SOFTIMAGE|XSI
Mantom, Chicago
Matt(at)Mantom.net
pipeline development theory
Date : Wed, 15 Jun 2005 16:18:55 -0400
To : xsi(at)Softimage.COM
>From : xsibrad(at)fie.us
Subject : pipeline development theory
OK, so, I'm sure we're all buzz-word savy here. We're all multi-media
aware.
We're integrated. We've all talked to our solutions providers. Our meta
data is in order and dynamic in nature. And we're all open architecture in
our
design choices.
Likewise, we're all using self healing computer systems. And since we're
super
cutting edge, we're moving from object oriented programming to aspect
oriented
programming. All using Rapid Application Development (RAD) tools. Awesome
:)
I've run out of buzz words.
So whats with this pipeline development thing?
Ok, joking asside, I've heard the term thrown about quite a bit when it
comes to
3d software as of late and while I was on holiday for the past few weeks it
crept into my mind a few times.
Pipeline development.
I guess the question is: what do you folks in general consider to be under
the
realm of pipeline development?
For example, I've read through the CG Soup articles on pipeline. And it all
makes good sense. People organized in a system and a progression for assets
to
step through. Good solid milstones, locks, review points and opportunities
for
iteration. Thats how you design a good pipeline with existing software and
tools.
But every once and a while I hear some comments which make me think some
studios
are doing a lot more than simple work force organization and data repository
restructuring, and moving from "having a pipeline" into the realm of
"developing a pipeline, and pipeline tools". And its this area that I'm
currious about.
For example, for my own projects, I am currently using subversion and
tortoise.
http://subversion.tigris.org/
http://tortoisesvn.tigris.org/
to version everything from XSI projects, to sourcecode for my plugins, to
the
psd files I use to generate my synoptic graphics.
The binary DIFFing allows me to save drive space but still feel secure that
the
past has not been lost. And having the central repository lets me take my
work
with me from machine to machine very easily. I can even merge changes on
two
machines that have lost sync.
I've also read in some postings a few weeks ago regarding Omation's
pipeline,
that there's a good ammount of SQL styled database work going on with their
pipeline.
And of course, my mind immediately started spinning visions of reference
models
being stored as BLOB objects in a huge database with versioning information.
Then I came back down to reality and realized its probably not quite as
grand an
integration as that. But who knows?
I also thought about work that was started at R Greenburg and Associates
back in
the day, that I believe has a life over at RhinoFX today. The basic theory
being that Maya ASCII files are stored in a big CVS-like repository and
spliced
together on the fly. So one could theoritically commit just the lights from
a
scene to the repository. Then one could have the repository generate a
scene
that has the most recent characters, the animation from last week, and the
lighting from yesterday morning. One could tweak the animation and then
commit
just the animation back to the regpository. Meanwhile, the riggers are
fixing
minor skinning issues. The next day, you update and pull the latest version
of
everything to your machine and do test renders. Its like a Maya aware CVS
that
has concepts of lights and characters and such, and can weave .ma files
appropriately to make it work. In theory anyhow, I have not used it and I'm
not sure if I'm making it out to be more than it actually is.
I realize this is starting to sound like a jumble on random pipeline info...
probably because it is.
Question: as far as the XSI world goes, is anyone doing stuff like this?
Once
a people pipeline has been established, are complex tools being written
around
the
pipeline to the point that the production is centered more on a versioning
reposiory and a database than on a "people maintained directory structure?"
Are
these tools integrated directly into XSI?
Question: Has anyone been using the alienbrain integration in XSI that
could
comment on how it works for them in a production pipeline?
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?
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?
All this stuff has been bouncing around in my head and I'm currious as to
the
actual state of affairs in the high end production world in XSI.
Thanks for any insight.
-brad
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
