Path searching options?

[pbowmar]

Hi,

I'm wondering, does 3DC support path searching for things like plugins, new brushes, etc? I notice in the SDK thread it mentions installing your created plugin in the install directory, but in a large studio this isn't desirable, as you often want different versions of the same plugin on different projects.

For those not familiar with this way of working, it's fairly simple. An application will use an environment variable that lists locations on disk to search for all the "bits" that it will use.

So for example, for a plugin, it might be:

3DC_PLUGIN_PATH="/some/other/disk/MyProject/3dc/plugins:/some/common/disk/3dc/plugins:/home/pbowmar/3dc/plugins"

When 3DC starts up or initializes its plugins (not sure how it loads plugins) it would search this path, and using a "first one wins" scenario, load whatever it finds in each of the directories.

If there is a duplicate, for example:

/some/disk/3dc/plugins/myBgeoLoader.so

/some/other/disk/MyProject/3dc/plugins/myBgeoLoader.so

the one in /some/other/disk/MyProject/3dc/plugins would be the one loaded because it's first in the path.

However, working outside a project might have a path like:

3DC_PLUGIN_PATH="/some/common/disk/3dc/plugins:/home/pbowmar/3dc/plugins"

which would then use the "common" plugin, not the "MyProject" specific plugin.

This is how apps common to big studies work (XSI, Houdini, Maya, Shake, Nuke) and is generally how a studio pipeline is set up especially if it's *nix based (Linux, OSX). It's not "right" or "wrong" per se but is a very powerful and flexible way of working.

One thing that is a pretty hard rule at a bigger place is "never modify the 3rd party application installation directory" which of course can be worked around in various ways (simlinks etc) but isn't ideal.

I'm not suggesting Andrew rush out and do all this if it doesn't support it right now, since we (my company) haven't even committed to seats yet, but just wanted to see if there was anything already in place that would support something like this or not.

Cheers,

Peter B

[cakeller]

Hi,

I'm wondering, does 3DC support path searching for things like plugins, new brushes, etc? I notice in the SDK thread it mentions installing your created plugin in the install directory, but in a large studio this isn't desirable, as you often want different versions of the same plugin on different projects.

For those not familiar with this way of working, it's fairly simple. An application will use an environment variable that lists locations on disk to search for all the "bits" that it will use.

So for example, for a plugin, it might be:

3DC_PLUGIN_PATH="/some/other/disk/MyProject/3dc/plugins:/some/common/disk/3dc/plugins:/home/pbowmar/3dc/plugins"

When 3DC starts up or initializes its plugins (not sure how it loads plugins) it would search this path, and using a "first one wins" scenario, load whatever it finds in each of the directories.

If there is a duplicate, for example:

/some/disk/3dc/plugins/myBgeoLoader.so

/some/other/disk/MyProject/3dc/plugins/myBgeoLoader.so

the one in /some/other/disk/MyProject/3dc/plugins would be the one loaded because it's first in the path.

However, working outside a project might have a path like:

3DC_PLUGIN_PATH="/some/common/disk/3dc/plugins:/home/pbowmar/3dc/plugins"

which would then use the "common" plugin, not the "MyProject" specific plugin.

This is how apps common to big studies work (XSI, Houdini, Maya, Shake, Nuke) and is generally how a studio pipeline is set up especially if it's *nix based (Linux, OSX). It's not "right" or "wrong" per se but is a very powerful and flexible way of working.

One thing that is a pretty hard rule at a bigger place is "never modify the 3rd party application installation directory" which of course can be worked around in various ways (simlinks etc) but isn't ideal.

I'm not suggesting Andrew rush out and do all this if it doesn't support it right now, since we (my company) haven't even committed to seats yet, but just wanted to see if there was anything already in place that would support something like this or not.

Cheers,

Peter B

I COMPLETELY AGREE!!!

this should actually be the way it is like in maya... ALL customizations should go in the user documents folder... and anything of the same name in the "customizing folder" overides that of the same name in the app folder.

e.g. maya has scripts, called mel scripts, and any scripts you alter and place in your "scripts" folder in your <user documents>/maya/scripts/ folder, overrides even the maya factory shipped scripts in the app folder. This would be great for things like shaders, and etc. that way users don't MONKEY with the install folder. And in the event that a customization messes something in 3DC up, you just delete, the customization folders in your docs. (or move it somewhere else temporarily to make sure it's your customizations)

[pbowmar]

Yup exactly. Basically, 3DC can't be used in a professional multi-user environment without this, unless some seriously lame hacking is done.

There are ways we could set up a virtual filesystem that changed symlinks for each user based on $USERNAME but since 3DC would be the only app that required that, it would be ... unpopular with the sysadmins

Maya/Houdini/Nuke/Shake and I'm assuming XSI (any Linux based film production application) works on this paradigm. Most Windows apps put user-specific things in User Data or wherever (I'm not a Windows guy, not totally sure where it goes) but conceptually is similar.

Cheers,

Peter B