[Bf-committers] Environment Variables for scripts and plugins

[lorenzo pierfederici]

first of all I want to say that I'm sure you're doing a great job at
building pipelines and that your ideas come from a valuable experience!
So don't take my opinions below bad: for me it's a good chance to share
ideas with a peer! :)

On Fri, Sep 25, 2009 at 2:45 PM, Jason van Gumster <
jason at handturkeystudios.com> wrote:

> Hello,
>
> Stefan Andersson <stefan.andersson at bohmation.org> wrote:
>
> > > - $HOME/blender/<...>
> > > this has been discussed a bit already, my idea is that blender should
> NOT
> > > create or use a visible directory into the user's home (like Maya
> does).
> > > Every OS has its way of dealing with app data and config, and we should
> > > follow that.
> >
> > please don't. I think the maya/softimage way is a lot better than what
> > the "normal" OS behaviours are. By default various OS behaviour is to
> > hide this from the user. And what you really want is to expose this to
> > the user. Especially on unix this is a pain that it's always saved
> > under dot folder (which by default is hidden). What most users want is
> > to have it non hidden and also something you can work with.
>
> Respectfully, I must disagree. The bulk of users would rather do
> configuration
> once and then let it keep out of the way. This is the advantage of the
> hidden
> directory system. There are conventions in place and they work well. It
> would be
> best to stick with them on there pertinent platforms. I'm speaking mostly
> to
> linux/unix here, but it goes just as well for Mac and Windows.


well, based on my experience I see two categories of users:
single professionals working on their own or in very small groups and
managing their own projects, should rather have an application that works
consistently with their environment. On linux having to add a script into an
hidden folder named ~/.blender is just the same as adding a gimp brush, a
gedit plugin, ecc
The same should be on windows and osx.
For this kind of users, If you only take a single app into consideration it
might look like a good idea to have a "different" behaviour, but in the long
run having a lot of application working differently goes against
consistency, and I don't see how this can help productivity (this of course
is just my opinion, I have no title to debate on that but experience). :)

the other category is studio users, and since each studio has it's own
conventions, structures and legacy, users will have to change habits and
often tools to adapt anyways.

Now, I agree that
> prioritized layering should be implemented with an inclusion for specific
> project-based scripts (for Linux, something
> like /usr/share/blender:~/.blender:/$PROJECT/scripts). But I think
> ~/blender is
> a bad call.
>
> The good news is that AFAICT, the tools for this kind of stuff are
> generally in
> place and mostly just need to be overloaded to allow layering. Correct me
> if
> I'm wrong, but the File Paths interface in the User Preferences would be a
> good
> starting place, right?
>
> yes, but env vars would make it easier for pipeline TDs using scripts
rather then saving preferences through the interface. Using (optional) env
vars would help Blender being a well behaved citizen in a multi-tool
pipeline (that's already possible, of course. It would just be easier).


> > > - BLENDER_PROJECT
> > > I think this is not needed and would be confusing to use (and I _HATE_
> when
> > > Maya creates project dirs all over the place) ;)
> >
> > I don't know where you get this. I have no problems at all with maya
> > creating folders all over the place.
>
> The problem isn't that Maya creates folders all over the place. It's that
> Maya
> (I'm talking vanilla install here) *creates folders* and attempts to
> dictate a
> directory structure that isn't necessarily suitable to your specific needs.
> This is a default behavior that is not desirable. The project structure
> should
> be dictated and controlled by project policy, not by Blender. Blender
> should be
> able to simply fall in line with any stipulated structure. For this,
> relative
> paths (or, if absolutely necessary, paths relative to a specified
> $PROJECT_DIR)
>
> If a user clicks on the wrong directory when doing "set project" Maya will
create the whole structure there... and with 20+ animators things can get
funky! But that's not the point, I was just kidding :)
The real point is better highlighted here:

[ shot ]
>     [3d]
>        [scenes]
>              [ anim ]
>              [ model ]
>              [ light ]
>              [ sim ]
>              [ track ]
>     [2d]
>        [scenes]
>              [ comp ]
>              [ roto ]
>              [ precomp ]
>

in this list you have put (and rightfully so) things specific to a single
shot (except "model", that doesn't really fit here... model of what?
character? prop? layout? they all belong to the library as they might be
reused on different shots).
As they are the results of different parts of the workflow, they are quite
indepentent form one another.
The project structure that you are proposing (if I'm not misunderstood) is
something like "a place to put things _used_ in the file", like textures,
audio files, images, caches.
Some of this things belong to the library, textures for example, because
they can be reused. Others are shot-specific, but better promoted to assets
themselves, so they can be organized through a common interface (the asset
manager) for all the tools needing it. For example an audio file should be
available to both an audio app that modifies it and Blender that uses it...
if you put it in a Blender-specific per-shot-project-structure how clumsy
would be to open it from the audio app? Imagine a sound designer going to
"3d/scenes/audio/" to open or save his .wav file... why "3d"? why "scenes"?
And the same goes for caches.

So if you have files (and not all of them "3d scenes") quite independent
from one another, why would you need a "scenes" subdir? The one thing it is
useful for is to have a place to start browsing from when clicking on
"open", but that's better served with hooks reading from the assets db, so
that different actions can go to different starting places.

And since we are at that... the distinction between 2d and 3d can get a bit
blurry in complex projects, and they are just two of many possible
categories (audio, images, etc), so better save another level of structure
and go straight to the assets:

[<project name>]
    [library]
        [characters]
            [<char name>]
                [model]
                [textures]
                [rig]
        [locations]
            [<loc_name>]
                [model]
                [texture]
    [scenes]
        [01]
            [001]
                [animatic]
                [audio]
                [layout]
                [animation]
                [cache]
                [fx]
                [lighting]
                [render]
                [comp]
                [plates]
                [mattepaint]
                [<etc>]

here you have just one dir with reusable assets (or "project" dir):
"library", this dir can be accessed through the nework or replicated on the
renderfarm if needed. So we don't need Blender (or any other tool) to create
a per-shot project dir.

in a structure like that you publish your files through the asset manager,
that takes your file, puts it in the right place, names it according to your
conventions, and versions it, all in a app-agnostic way. If an app tries to
dictate its own structure it gets in the way, like Jason said.


> > And asset managment is more of a record of what you have, the
> > application should still be aware of where it has it's files. Or your
> > will have a application that traverses around the network trying to
> > find files.
>
> Maybe I'm misunderstanding. How does a .blend file which links to external
> resources *not* know where its files are?
>
>  I'm not sure I understood this, either. What do you mean by "traverses
around the network trying to find files"?