Organizing files#

Anchorpoint has its own storage solution. You use the storage of your choice. Anchorpoint can use shared folders such as a NAS for internal file sharing or cloud sharing solutions such as Dropbox, Google Drive, One Drive Nextcloud etc. For Git-based version control, you will need a Git repository on GitHub, GitLab, Azure DevOps, Bitbucked or a self-hosted solution that supports repository cloning over https.

Depending on your use case, you will use a different solution to share your files. Here is an overview:

file organization in anchorpoint Depending on your use case and file types, you may want to use either a shared folder or a Git repository.

File categories#

Asset Libraries#

Asset libraries are shared folders where you store content that you want to reuse across multiple projects. This can be 3D models, audio, video, footage, 2D graphics, stock images, etc. that are not directly associated with a project. These files should always be kept in a shared folder that everyone on your team can access, as version control is not needed here.

Game builds#

Your builds that the game engine produces for your QA testers. These builds can get quite large and should be kept in a shared folder, organised by a proper naming convention. If you are using a cloud-based CI/CD, such as GitLab, your QA team may download them from the site. In this case, you don’t need to store them in a separate location.

Input, material, output#

Files you get from a client, 3D scans you make for your project, footage from a shoot, reference images, and anything else that doesn’t need to be versioned. These files belong in a shared repository.

Generated#

These are rendered image sequences, alembic caches, preview renderings and anything generated by source files or the game engine. These files should be stored on a shared folder as they tend to be very large. File sharing solutions such as Dropbox synchronise files as soon as they are created, and don’t wait for a publishing process to upload them. These files should also be stored in folders that match the name of the source file that created them.

For example, if your source file is called shot_0020_animation_v03.blend, then your image sequence should be saved in a folder called shot_0020_animation_v03 with a filename of shot_0020_animation_v####.exr.

Game engine files#

Game engine files belong in a Git repository without exception. Even if you are working alone, proper version control is the only way to recover from corrupted files or broken projects.

Source files#

Source files are your art assets created with tools such as Blender, Maya, 3Ds Max, Cinema 4D etc, including all the add-ons such as Photoshop, ZBrush, Substance, 3D Coat etc. If you’re not using a game engine for animation and rendering, your shot files belong there too.

Compositing files from After Effects, Nuke or Fusion are also source files because they can generate renderings.

Where to put your source files?#

Source files need to be versioned, so they could be stored in a Git repository or on a shared folder and then versioned incrementally (v001, v002, v003). In general, if you’re doing game development, AR/VR or real-time visualisation, it’s probably best to put them in a Git repository so that you have all your files in one place. Source files export data that will be imported into the game engine anyway. If you change an asset, you usually need to change the source file and the game engine file together. So it makes sense to commit all these changes in one commit. However, there are some exceptions (e.g. heavy ZBrush files) where it might make sense to store them on a shared folder. If you are working on animations, cinematics or anything that will end up as a video, you can leave the source files in a shared folder with incremental versioning. There are some advantages and disadvantages compared to a Git repository. In general, the more work you do in the game engine (e.g. you animate in Unreal instead of Blender), the more it makes sense to leave it in a Git repository.

Source files on a shared drive#

  • You get instant uploads and downloads. There is no need to submit your work, so file sharing feels faster.

  • This workflow is more familiar to most artists because they can version using incremental storage.

Source files on a Git repository#

  • Everything is in one place with the game engine content (if you are making a real-time project like a game).

  • You get solid file referencing for free. Assets can be referenced or linked to in other asset files, because with version control you do not change the filename.

  • You get a publishing process and better visibility of your work. You can see who has done what.

Use cases#

Depending on your use case, you might especially store your source files on a different location.

Real-time projects such as games, AR/VR, visualization#

If you are producing a real-time experience, it makes sense to store your source files in your Git repository.

Video production such as animation, cinematics, and non real-time visualization#

In this case, you might want to put your source files in a shared folder, because that feels familiar to your artists. You get faster file transfer, but not the version control capabilities you get in a Git repository.

Working in a team#

Shared Folder#

If you work in a team, everyone must have access to the production files in the shared folder. The rule is: What Windows Explorer can see, Anchorpoint can see. If you are working from a NAS or any other shared drive on your network, everyone needs to have access. If you are using Dropbox or Google Drive, everyone must have the Dropbox/Google Drive application installed and all files must be synchronized. Anchorpoint is not responsible for the file sharing here. This is done through the apps. If you hide certain folders from other members (e.g. via access controls), Anchorpoint will not see them either.

Git repository#

In the case of a Git repository, Anchorpoint will take care of synchronizing the files to the Git server (GitHub, Azure DevOps, etc.). Anchorpoint will store the URL to the Git server so that other members don’t have to enter it. Make sure each team member has an account on the Git server and access to the Git repository, which is essentially the virtual hard drive where all files are stored. If a member is using Anchorpoint for the first time, they will need to connect Anchorpoint to the Git server by entering their Git credentials.

More details