How is everyone using filename increments? We are using v000 increments only.

Within Maya  >  When you do a Shotgun Save As, the filename is automagically assigned an increment.   In light of the fact that for our first project utilizing shotgun, we're using it as out-of-the-box as possible, I'm trying to understand what the benefit of this feature is.  I find it makes things painful when publishing (as the publish filename inherits the work-file filename with no option to rename), and creates restrictions w/ respects to using Snapshots.

In order to utilize the power of Snapshots between users, we've elected to use a common filename so that the snapshots for that filename all are visible within the Snapshot History app.  This allows all users to see the entire list of Snapshots for the Asset, instead of for each filename (Snapshots history is limited to and displays snapshots for the current workfile filename only).  We are relying on the .v000 versioning system for workfile increments only.  Is there a caveat to working like this?  (Other than perhaps running out of padding.... IS THERE ANY WAY TO CHANGE THE PADDING TO FOUR DIGITS?)


  • 0
    Manne Öhrström

    Hello Matt!

    Great questions! Let me to offer some explanations and background!

    Like you highlight in your post, there is a relationship between a work file and a publish. Each file name contains a version number, three padded by default, but this is something you can change and configure. A lot of the naming convention in toolkit is configurable through our templates system, see for example here for an example of our default configuration! 

    By default, there is a concept of a work area and a publish area. You can organize your work areas in many different ways, per shot, per task, per pipeline step (sort of like a department) or per user. You create a number of work files and each of these will start their life as version one. During the work phase, you can create snapshots as you go along. I am not sure you are familiar with this, but we sometimes think of these snapshots as something similar to what macosx does in the background when it keeps all changes to a file you are making, making it relatively straight forward to revert to an earlier increment of a file.

    When work has reached a point where it can be shared and/or should be reviewed with other people, it is published. We think of our default publish as a handoff point where work leaves one person and is passed on to someone else. Publishing means that your work files is copied into a published area, and it typically also includes secondary products. For example, alembic caches are generated for all the individual characters in your maya scene. All these items are typically versioned alongside the published file, so you end up with a little "collection" of published files. When you publish your version 1 work file, that's effectively the end of life for v1 - further work will happen in v2, and then you publish that. 

    It is possible to set things up so that users have their individual work areas and then publish into a common publish area. In this case, work often starts by toolkit copies the latest publish file into your work area - this is handled by the file manager app. 

    Hope this sheds some lights on how we are thinking about these workflows! Sounds like you are doing some interesting stuff with the snapshot app and the snapshot history! We would love to learn more about this and if there would be improvements we could do to our existing tools to help you work in a better, smoother way!





  • 0
    Matthew Tucker

    Basically we have been determined to keep the publish filenames the same for ALL publishes, with the exception of the _v000 increment   This helps to avoid confusion when loading the file in a department downstream from the publish file.

    Do to the nature of our approval process, and the preference of production staff (not MY preference ), we have elected to publish ONLY when the file is ready to be used in downstream departments (tasks).  When passing files between multiple artists (within the same task;  "Model" for example), we do so by creating a snapshot.  The other artist then loads the snapshot, and begins working on it.  

    For us specifically, the problem with the Snapshot History is that it only shows a history of the filename you are working on (current scene filename).  This is very disadvantageous in the sense that in order to get a full list of Snapshots displayed in the Snapshot History, we have to use the exact same filename to save all our workfiles.

    For Example:  

    filename.v001.ma, filename1.v001.ma, filename2.v001.ma   ~ All have DIFFERENT snapshot history.   (filename increment)

    filename.v001.ma, filename.v002.ma, filename.v003.ma ~ All have the SAME snapshot history.  (version increment)

    Due to this fact, we are forced to use (version increment)  in order to get a full list of snapshot history for multiple artists (within the same task) to load their file from (and get thumbnail / description).  

    I don't think this is an ideal way of working.  I agree with you -- i think that everytime someone is working on a file, and it will be passed off to another person, they should publish the file.   Approved assets should be published, and then marked with "Approved" status.  But unfortunately we are not working this way at the request of other people.  It would help however if we had a toggle to display snapshot history for all snapshots related to the task, instead of limiting history only to the snapshots with the same filename as the current workfile.


  • 0
    Manne Öhrström

    Thanks Matt! That makes sense!

    Some comments and ideas:

    Have you considered using user based folders? Judging from your explanation, I think this could be worth considering! Basically, each artist would have their own work area but all publish into the same location. Our file manager app makes it easy for users to pick up each others' work. You can read more about it here: 



    Check out this screencast for an example of what it could look like when each user has their own work area:


    It sounds like the main issues you are having occur when artists are sharing their work files. What sort of process is this - does it happen all the time, does it happen from time to time? Do you have a strict policy that only one person works on a file at one time? 




Please sign in to leave a comment.