[Bf-committers] Environment Variables for scripts and plugins
Stefan Andersson
stefan.andersson at bohmation.org
Fri Sep 25 12:45:32 CEST 2009
comments below
>>
>> 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
>
> I don't know if this is allowed in XDG.
>
probably not as XDG only is designed while installing an application
and where to put the preferences. This is more of how blender should
work and "work with" environments. So you have to think of this more
in the context of 'when we use blender' and not 'installing blenders
preferences'. XDG is (as far as I have read about it) designed so that
you do that setup once, and then it's set. or you change it. That
means that it's a singular operation, so you can only have one.
> This looks useful also to _share_ common data across multiple blends,
> for instance, are you aiming to this too? I couldn't find the words
> 'share' and 'common'; sorry, I tend to think in keywords...
Not really sure what you mean here. But I guess we mean the same thing
:) Basicly since you can set several paths you can share data over the
studio. So you can have a 'drop folder' with a lot of scripts that
everyone can use. Same goes internally with models and textures.
I can explain a little how our folder structure is built, here is a
snippet of it (not covering all)
#--------------------------------------------------
[ project ]
[sequence]
[ shot ]
[ 3d ]
[scenes]
[textures]
[etc..]
[ shot ]
[ 3d ]
[scenes]
[textures]
[etc..]
[lib]
[3d]
[hdr]
[models]
[textures]
[tools]
[scripts]
[icons]
[plugins]
#--------------------------------------------------
So here we have a 'lib' in the root of the project. Our env points
towards this and also to the studios 'common' tools, and also the
users local tools. What we also do is that we symlinc the 'models' and
the 'texture' folders into the shot, so the texture folder is also
located in the shots texture folder but called 'tex_lib' there (it's
where you save textures for 'global use' in the project').
In a way this is what the blender file does for us, but we don't have
any control over it or can have external tools that modify it. Perhaps
I'm wrong here though, not really familiar with the blender format to
that extent.
I hope this also helps.
regards
stefan
On Fri, Sep 25, 2009 at 12:54 AM, Antonio Ospite
<ospite at studenti.unina.it> wrote:
> On Thu, 24 Sep 2009 22:19:17 +0200
> 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.
>>
>
> Hi Stefan,
> just some random comments from a random user, below.
>
>> ___ 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
>
> If you replace {scripts,plugins,rigs,models,tool} with the word 'data'
> you see that the problem is quite blender-independent, so maybe someone
> else already found a solution for this.
>
> I can only speak for unix-like systems, tho, I know I am missing your
> item 5, sorry, but it is still worth mentioning: there is already a
> specification about where user data for programs could go, see
> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> I am not really proposing this solution, as it may not fit blender
> needs, I am just suggesting to 'discard' it instead of 'ignoring' it ;)
>
>>
>> ___ 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
>
> If overriding those when launching the program is your final target,
> this is obviously doable with XDG.
>
>>
>> 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
>
> I don't know if this is allowed in XDG.
>
>>
>> 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.
>>
>
> This looks useful also to _share_ common data across multiple blends,
> for instance, are you aiming to this too? I couldn't find the words
> 'share' and 'common'; sorry, I tend to think in keywords...
>
>> 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
>
>
> Regards,
> Antonio
>
> --
> Antonio Ospite
> http://ao2.it
>
> PGP public key ID: 0x4553B001
>
> A: Because it messes up the order in which people normally read text.
> See http://en.wikipedia.org/wiki/Posting_style
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
--
[ protector of penguins - abuser of pixels ]
More information about the Bf-committers
mailing list