[Bf-committers] Environment Variables for scripts and plugins

[lorenzo pierfederici]

umh... +1/2, -1/2 from me
I work in pipeline too and had to face the same problems, and I've found
Maya's solution very unsatisfactory ;)

here are a few ideas on your points:

- $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.

- BLENDER_SCRIPTS, BLENDER_PLUGINS, BLENDER_ICONS
I agree on this, it would be very nice in a larger pipeline if we could
define a list of path (and precedence) to layer resources. Defining only
"system" and "user" at compile time is a bit limiting, as you stated we
should be able to define
BLENDER_SCRIPTS=/path/to/user/scripts:/path/to/project/scripts:/path/to/studio/scripts:/path/to/system/scripts

- 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) ;)
In a small project Blender already works very well with scenes, relative
paths, packing resources, etc.
In a bigger project you don't really want resources in the shots
directories... you want (for the 3d part) just an animation .blend file
referencing characters, props and layout from a project-wide library, plus
local caches.
This kind of references should not be managed by Blender (or any other
single tool), but by a stand-alone asset manager that can deal with assets
from multiple tools and manage versioning, comments and approval history,
especially because in bigger projects you will always need multiple tools!
Having to deal in the same shot with Blender projects dir, Maya project dir,
<compositing tool> project dir, <paint tool> project dir, <audio tool>
project dir... and all without versioning... is pipeline hell! :)

Then in each tool there will be hooks to retrive things like "current shot",
"characters directory", "textures directory" from the assets db to improve
productivity in action like CTRL-O or SHIFT-F1.

- on env variables in general
a few months ago I wrote a micro patch to allow env variables in library
paths:
https://projects.blender.org/tracker/?func=detail&aid=18581&group_id=9&atid=127
if there is any interest I can try and see how to make it work for 2.5

...I'd be more than happy to discuss these things, see you on
#blendercoders? my nick is lento

cheers,
lorenzo



On Thu, Sep 24, 2009 at 10:19 PM, Stefan Andersson <
stefan.andersson at bohmation.org> wrote:

> Hello Everyone
> You can all blame Campbell for this mail, I sent a similar one to him
> and he thought I should post it here :) He also mentioned that there
> was some sort of patch for this once.
>
> ___ Environment Variables ___
> I would like to talk about Environment Variables in  Blender. I've
> been lurking and reading the list for a while, but when the thread
> "Setting a default system scripts directory" came up I felt I had to
> speak up. One of the things that I do is constructing pipelines, and
> also making tools (in python) for these things. And I've always wanted
> to fit blender into the pipe, but it hasn't been possible and a few
> things are missing (from a pipeline p.o.v).
>
> I'll try and keep it brief and see what others think.
>
> ___ Problems ___
> 1.) You need to have a way to redirect or modify where the scripts are
> located
> 2.) Scenes can't find plugins or scripts(tools) that has been written
> for a project
> 3.) Lead TD can't find the rigs or models you have done (don't show up
> in the project)
> 4.) You wrote a nice tool that you would like others at the studio to
> use right away
> 5.) You work in a cross platform environment
>
> ___ Solutions ___
> Using a few (it has to be few) environment variables will solve about
> 80% of the problems. The first is to define where the local user
> should have their preferences. And the big "3" (Maya, XSI, Houdini)
> has a similar solution to this.
>
> $HOME/ (application) / (version) / ( preferences files )
>
> This is the base home for the user preferences and also for scripts
> and plugins. This will suite most single users. The structure could be
> $HOME/blender/2.5/scripts
> $HOME/blender/2.5/plugins
> $HOME/blender/2.5/prefs
> $HOME/blender/2.5/icons
> $HOME/blender/2.5/default_project
>
> We still haven't dealt with any environment variables though. But if
> we have these building blocks first, we can also give them environment
> variables ( which is required for larger studios ). Blender could have
> an internal set of variables that always will be present
>
> BLENDER_SCRIPTS = $HOME/blender/2.5/scripts
> BLENDER_PLUGINS = $HOME/blender/2.5/plugins
> BLENDER_ICONS = $HOME/blender/2.5/icons
> BLENDER_PROJECT = $HOME/blender/2.5/default_project
>
> Once we have set these we can also add more paths if needed. If you
> use (as we do at our studio) and application launcher, the script
> could easily add more paths to an existing environment. As an example
> (using 'durian' as a project name here)
>
> BLENDER_SCRIPTS = $HOME/blender/2.5/scripts:/bsdone/durian/lib/scripts
> BLENDER_PLUGINS = $HOME/blender/2.5/plugins:/bsdone/durian/lib/plugins
> BLENDER_ICONS = $HOME/blender/2.5/icons:/bsdone/durian/lib/icons
> BLENDER_PROJECT =
>
> $HOME/blender/2.5/default_project:/bsdone/durian/000_dev/000_010_mountainShaders/3d
>
> The big benefit of this is that you can now define the hole
> infrastructure with variables that you can change when ever you want.
> New paths can be dynamicly added or removed. It can be as simple as a
> ascii file under $HOME/blender/2.5 that holds those paths that I've
> written above, or you can just append them in a python script when you
> start the program.
>
> This way you can 'layer' your tools/scripts
>
> Local -> The User
> Global -> The Studio tools
> Project -> The Current Project you are working on
>
> Since you do create tools for projects, you also want to make sure
> that you backup the tools that were used. So in our case the project
> specific tools are located under:
> [project] /lib/ [application] /scripts
>
> ___ Why a "BLENDER_PROJECT" env? __
> It's imporant that the application can be aware of which 'shot' it's
> working on. If the variable for the project is:
> "/bdsone/durian/000_dev/000_010_shaders/3d"
> It will look under the '3d' folder for 'scenes' 'textures' 'models'
> etc. So you can have relative paths in your scene. This way you can
> move the hole '3d' folder and the project will still be valid.
> If you use a application launcher, when the project environment is set
> the user will always come to the right place at once when they try and
> open a file. If they press CTRL-O the will be redirected to
> '3d/scenes' directly.
> This is something that saves a lot of time when you have a bigger
> studio and lots or projects going on. Trying to find scenes is a time
> killer.
>
> The Blender file format could be a bit of a problem for this one, but
> I think that one has a lot of good things in it and I think these
> things could work in conjunction with each other. But at the same time
> (as a TD) I don't like at all when things are baked into one big file.
>
> I can speak for hours about this, but this is quite a lot of text and
> I think we can take it from here. What do you guys think? Should I
> expand it more about how the folder structure for a big pipeline is?
>
>
> --
> [ protector of penguins - abuser of pixels ]
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>