6

I need a good way to organize my blender project files in the project folder. I've tried a universal texture folder (any movement and things get lost), I've tried to include a texture folder in the project folder (lots of duplicates with other projects)

What is a good methodology to set this up and easily transferred to another person or team or GIT.

yodamon
  • 895
  • 1
  • 11
  • 19

3 Answers3

4

In industry it works like this: If you are not the boss, you follow whatever structure boss dictates. If you are the boss, you (should) have enough experience to setup such structure.

There is no single best structure, but such answer won't help you. I hope this helps instead:

  • use version control for your project files (subversion is good for this, mercurial with large files plugin, etc..)
  • keep all the project files inside the project structure with relative paths. Categorize these files in folders such Textures, References, Rendered, etc. Try to keep the folder structure wide and not deep - like max. depth 2. Don't pack the files into the .blend, because then you need to unpack them to edit. If you need to share project outside the versioned workgroup pack the whole structure into .zip or pack files into .blend.
  • to the above point there are two exceptions:
    • large simulation files (caches of several GB in size). These days your work files should live on an SSD, but these caches sometimes need to have a separate archive on HDD because of their size. In this archive have a folder for each project and very large files inside. Version it. Ensure this archive has the same path (drive letter) on every machine and link the files to projects with absolute paths.
    • things all projects share that should be updated for all projects across - like some addons or scripts. Keep local scripts inside project folder.
  • also have some library location outside the projects for your materials, textures, light setups, node setups, HDRIs, etc.. Never link anything from this library to the project, always make duplicates inside projects. There could be several libraries and they can be shared. Versioning is not critical, though backing it up once a while is.
Jaroslav Jerryno Novotny
  • 51,077
  • 7
  • 129
  • 218
3

After many tries I guess there simply isn't a universal method that just works out of the box with every Blender project (or with any project that involves cooperation) imaginable.

It all comes down to the nature of the project itself. Rendering still images or movies might have different requirements than creating game assets.

The universal texture folder might be a good idea at first glance, but once you start altering those textures (painting seams, baking dirt/worn edges) those textures become project- and even object-specific. So once you make changes to the base textures, you might them store in a project-specific area of your file system anyway.

Subfolders within the project folder keep things organized well enough within the Blender project, but they don't necessarily work for export to game engine formats.

Then there's always a difference between working on projects locally on your Computer, in a local network or over the Internet. If you work locally on your Computer but still want to share the work with other people, you would at least have to share a method how to set up the project folder (that's nothing special to Blender). The same goes for office-like LAN setups, both should be well-organized.

Collaboration over the Internet is a whole different story. The first thing that comes to mind is "hey, let's set up a git/cvs/mercurial repo". It's a good idea in general although there are virtually no distributed version control systems that deal well enough with binary files out of the box (the only one I know of is Perforce but it's not free and requires good hardware to run well).

IMHO the best method to share your work Blender has to offer without any additional work is to pack external data into the .blend file itself. Once you've done that you won't have to think about what to pack into the repo or where and how to store data in a manner that it would work over all setups. The only thing you have to remember is to clean up your file every now and then.

Community
  • 1
metaphor_set
  • 6,625
  • 2
  • 22
  • 35
  • Great point of view – yodamon Oct 20 '16 at 03:44
  • Mercurial does come with a bigfiles module these days; https://www.mercurial-scm.org/wiki/LargefilesExtension ; they mention a couple non-included options thero too – Weaver Oct 20 '16 at 04:20
  • @StarWeaver - I know. git also has several possibilities, but handling binary data is still not number one priority for all the major distributed versioning systems out there, so one should be prepared that they might not work in some cases. – metaphor_set Oct 20 '16 at 06:25
  • 1
    git works great for text files but for large binary files I stick with svn. With git each user gets a copy of the entire repo, so they have every version of every file which leads to many GB per project, but with svn each user only has two copies of each file, one original to compare with and one possibly modified copy. Only the svn server keeps a copy of every version. And an svn server can be located in another folder on the same machine. – sambler Oct 20 '16 at 11:23
1

(Speaking as an asset creator in the games industry.)

Short answer: There isn't one right way.

The long answer: Of the most useless meetings I have attended in my professional life, folder structure and file naming meetings are at the top. Everyone has their preferred way, and people rarely agree.

In the games industry there is a significant difference between "game assets" and "workfiles". And it is important that the game assets use naming conventions dictated by someone like a "technical director", or whoever is in charge of the repository.

The workfiles are less important because they won't make it into the compiled build and no two artists will ever agree on a structure anyway.

FredLierman
  • 497
  • 1
  • 5
  • 17