Public/private directory all the way at the project root?

#1

Hi every one.

Had a chance to talk to some veteran FX artist and he mentioned that at a few studios he worked at, the folder structure would separate publish and private all the way at the beginning. This is their attempt to make sure the publish folder is never touched by human hands.

/work/{path_to_asset_or_shot}/<username>/the_name_v###
/publish/{path_to_asset_or_shot}/the_name

Had any one every worked on this structure? I would love to hear your opinion please. I think it’s a cool concept myself since the production folder at my studio has a lot of trash and random stuff which were put there manually by individual artists.

#2

Yes, my best experiences has been in environments like these.

I’d take it one step further.

/{path_to_asset_or_shot}/private/<username>/the_name_v###/
/{path_to_asset_or_shot}/public/the_name/v###/

Such that each asset has a single root, followed by children that are either development or published files. Both published and development then have their own independent versioning, such as user A can have his/her own versioning, never seen by anyone except him/her, and published files have a universal naming scheme.

#3

In fact, I’d go two steps further.

Make it a pattern that every level of your hierarchy can have a private and public child directory.

└── project
    ├── private
    ├── public
    ├── shots
    │   ├── public
    │   ├── private
    │   └── shot1
    │       ├── public
    │       └── private
    └── assets
        ├── public
        └── private

That way, anyone can work anywhere, and publish anywhere, in context, and with no mess. For example, they could work directly on the project, in case of animatics of project-wide concept art and story, they would work on the top-level asset for the same reasons, or as specific as within a subcomponent of an asset, like a helmet rig, all within the same architecture and your tools will work identically across any level of specificity.

#4

How do you type the folder hierarchy? Copy pasting from yours for now.

The work anywhere is sort of a thing I’m trying to limit tho. My current system got the modeling, layout, animation and lighting under control but preproduction and comp are still a mess. Not to mention we have coordinators (and most of the times our seniors) creating random folders all over the place. If only I can force every one to create /private/user folder :sweat_smile:

I imagine a separation at the root level would at least help the published files much more organized and easy to find.

/private/project/path_to_asset/asset_name/user/work_however_they_want
/publish/project/path_to_asset/asset_name/v##/the_file
#5

And this is where initialisation comes in, with something like be.

An artist should never have to know, nor care, about where files are stored. He should be given a directory, based on what he’s doing.

#6

/work/{path_to_asset_or_shot}//the_name_v###
/publish/{path_to_asset_or_shot}/the_name

We actually use something very similar.

Whenever there will be people browsing the folder structure they will work where they are not allowed to, even accidentally! The most consistent way would be to have no one ever work with the folder structure directly, which would mean you have to build an Asset Manager to replace any explorer/browser.

If there’s still the need to browse the folder structure (even if it’s only sometimes) separating between publish and work as close to the root as possible is a great solution since they rarely even enter the published directory when browsing.

#7

Ah, I see what you mean now @panupat by separating “all the way at the project root”.

└── project
    ├── private
    │   ├── shots
    │   └── assets
    └── public
        ├── shots
        └── assets

This is the opposite of what I mean when I said it had been my most rewarding experience.

A hierarchy like this leads to large amounts of duplication, even in the small example above you’ve got 2 shots locations, and is therefore incredible brittle, especially when browsing and creating directories manually. You’re given no guarantee for your tools that the hierarchies will remain mirrored and will sooner or later end up with discrepancies and tools that have to compensate for it.

At the end of the day, it comes down to what you can manage and that you remain consistent, and any hierarchy works. But out of all possible hierarchies out there, this is, imo, amongst the worst when it comes to building reliable tools.

#8

‘be’ sounds great. I know places like ILM or WETA has similar system in Linux where users start their job my typing a few commands in the shell

giant (return)
SC0070 (return)
maya (return)

And they’ll be working in

/project/giant/whatever_path/SC0070/private/user_name/maya/xxxx

I wonder if I can get similar behavior on Windows?

#9

Yes, we can! That’s just what be is for. :smile:

$ be in giant SC0070
$ maya

This is the part where directory structure is programmed, and where artists don’t need to know where to start working or where to save their files. They’ll just need to provide enough information for your tools to figure it out by themselves.

#10

To demonstrate, I just created a project configuration for your specification above.

$ be new panupat --name giant
Finding preset for "panupat"..
Pulling mottosso/be-panupat..
"giant" created
$ be in giant SC0070 --enter
No development directory found. Create? [Y/n]:
$ cd
C:\Users\marcus\giant\whatever_path\SC0070\private\marcus
$ maya

This will.

  1. Pull the configuration, from here
  2. Put you in an environment that knows about the project
  3. Create a directory, based on the template for shots
  4. Start Maya, based on the per-project alias

It’s live right now, give it a try. :slight_smile:

environment

Here is the environment given by this particular configuration

$ be dump
BE_ACTIVE=True
BE_ALIASDIR=c:\users\marcus\appdata\local\temp\tmpfoxo1k\aliases
BE_CD=
BE_CWD=C:/Users/marcus/betest
BE_DEVELOPMENTDIR=C:/Users/marcus/giant/whatever_path/SC0070/private/marcus
BE_ENTER=1
BE_PRESETSDIR=
BE_PROJECT=giant
BE_PROJECTROOT=C:/Users/marcus/giant
BE_PROJECTSROOT=C:/Users/marcus
BE_PYTHON=
BE_ROOT=
BE_SCRIPT=
BE_TEMPDIR=c:\users\marcus\appdata\local\temp\tmpfoxo1k
BE_TOPIC=giant SC0070
BE_USER=marcus