File naming in a project is a crucial aspect that helps maintain order and facilitates working with files at different stages of the project. File names should be standardized so that any artist in the team understands exactly what each file contains.
In this guide, we will explore the fundamental rules and recommendations for creating consistent file names, as well as discuss methods for organizing projects based on the practices of our studio.
Project organization
- First and foremost, create a folder named “Matchmove_machine” at the root of your drive. This will be our main working folder. It is important to place it directly in the root, not in a path like D:\Vasya\Work\matchmove or any other variations. For ease of interaction within the team and for transferring to the client, we use a standardized path for everyone.
- Next, when we start working on a new project, we create a folder with the project’s name. The name is taken from the work table where all the shots are listed, or from the Telegram group for that project; we use the full name as indicated.
- Next, within the project folder, create a folder with the name/number of the shot as listed in the table, FTP, or the topic in the Telegram group. After this, you can download the source material into this folder.
- While the download is in progress, create a folder named “_v001” within the project folder. This folder will be used to store all our exports from the first version of the project. The underscore is not mandatory, but it ensures that the export folder will always appear at the top of each shot.
Thus, the general path of a shot will be: Drive/Matchmove_machine/Project_Name/Shot_Number/ShotNumber_v001
File naming
After setting up the project structure, we begin our work.
During the work process, all files are saved in the “_v001” folder. Here are the main types of files you will encounter:
Undistort files
- shotnumber_undistort_v001/shotnumber_undistort_v001_####.jpg — For exporting the undistort sequence, create a folder where the sequence itself is saved. Do not forget to add the frame variable after the version (in most cases, this is _####, as sequences usually start from frame 1001).
- shotnumber_STMap_undistort_v001.exr — Export of the undistort as an STMap.
- shotnumber_STMap_distort_v001.exr — Export of the distort as an STMap.
Geometry naming
Geometry naming nuances:
- If, during the work process, any geometry is created and used that was not created within Nuke but loaded separately (obj or fbx) and exists in a single instance, then we use the naming: shotnumber_geo_v001.obj.
- If there are multiple files of such geometry, we use simple names, for example: shotnumber_floor_v001.obj, shotnumber_locators_v001.obj, shotnumber_door_v001.obj.
- If we have geometry provided by the client and we use it in our work, then the name remains unchanged (unless specified otherwise in the technical task).
Version numbering
Special attention should be paid to version numbering.
It is important to pay special attention to version numbering.
We never increment the version number on our own. Even if we create internal versions during our work or receive comments from the lead, the project version only changes when we receive comments from the client. Only then do we create a new version folder “_v002” within the project folder and save all the files under the second version.
There should not be a situation where the export folder with version 001 contains files with higher version numbers (shotnumber_track_v004_3_(2).3de).
To save intermediate versions, when you want to fix the result and try a different approach, you can create a “backup” folder within the version folder. This folder should be used to store various working versions. However, in such cases, it is important to be careful not to get confused, not to send this folder during the export to FTP, and not to send an incorrect version.
All of this is necessary to avoid confusion between the client’s and our versions during the work process. When we start working on a shot, the client expects the first version (v001) from us. If a situation arises where corrections or additions are needed, then the second version (v002) is expected from us, and so on. This ensures clear naming and understanding from all sides.
Uploading the result
Before uploading the result, we check how our folder with files looks. We ensure that if the working version is 001, then all files have this version. We look for typos in the names.
The export requirements are usually specified and pinned in the project’s work chat and may vary. We carefully read the chat and ensure that we have all the files and there are no extras. The export location is also specified and pinned in the project’s work chat.
Note: If a situation arises where corrections are needed and a new version is created, then we upload all files with the v002 suffix. Even if these files have not been changed. It should not be the case that, for example, the scene is the second version, but the geometry and undistort are the first. This can lead to questions about whether the correct files have been uploaded and whether the required changes have been made. Explanations like “take the scene from the third version, the geometry of the second, and the undistort from the first” look confusing to everyone.
Therefore, we eliminate these questions by uploading everything in the new version.
It is important to check yourself every time before and after uploading the result, regardless of how confident you are and how automatic the process is. Mistakes, typos, and oversights can happen to anyone, so it is not difficult to double-check the number of uploaded and required files, check the names, and check the version.
- Project file 3DE4 (.3de)
- Lens file from Nuke (.nk)
- Scene script file in Nuke (.nk)
- Scene export file in Alembic (.abc)
- Scene export file in FBX (.fbx)
- Geometry file from 3DE4 (.obj)
- Result preview file (.mov)
- Folder with undistort sequence in (.jpg)
- STMap undistort file in (.exr)
- STMap distort file in (.exr)
