PEG Naming Tool for Maya- [Core Validation Logic]
- Kayla Techmeier
- Sep 23, 2018
- 5 min read
Updated: Oct 5, 2018
PEG- meaning to put a peg in the naming convention, or pegging down the naming, is a tool that tracks the naming conventions coming out of Maya save files in specified folders. This series of blog posts will break down my approach to this tool and my thoughts on it. As this is my first published tool, I'm sure it probably has some issues but that's half the fun of development.
THE PROBLEM SPACE
It recently came to my attention that when working on larger projects than a hobby game or animation, maintaining a strict file naming convention becomes a larger part of keeping the massive amount of files organized. Not only this but having something to double check for errors in the names that people write in a hurry is helpful.
It was to this end that I designed a python program to validate file names. Ensuring that they fit a few specific rules.
RULES
Rule 1
The name must consist of four parts, separated by underscores. Example: Name_description_state_version.ma
Rule 2
The second part must be a description. One of a set list of options such as environment, prop, character, misc etc. Similarly, the third part of the name describes the state the file is in, in the production pipeline. This tag can range from modeling through to finished game/animation asset.
Rule 3
The fourth part of the name must be a version descriptor. So this includes testing versions, and final versions. If it is a final version, there can be no numbers after it.
Rule 4
The file name will only be checked if it’s in a user specified list of file folders.
BREAKDOWN
So, in effect the simple explanation of what I have the program do each time the user tries to save is as follows. First checking to see if the user is trying to save in a location that is part of the locations list. If it’s in a place that the user has specified that they want their file names to be controlled, then check the validate the name against our rules. In the event that the name does not pass all of the rule checks, then it will pop up some UI for the user that provide a list of what did not pass the test. The UI allows for a space for the user to correct the name and try again, and will not allow the save to pass through until the name passes all the tests.
On the other hand, if the name passes the test from the start then the user will not see any UI at all.
To create this I started simple. The file name validation is the core of the tool so that’s where we start.
With a testing harness file, and utilizing the MayaCharm plugin for PyCharm, I made a list of good and bad names to pass through the validation.
I have a returning value of a list or a NoneType value, and based on this return value, we can understand whether or not our name passed the tests. This will make more sense later on.
In the validation we break down the data. In this part here, you can see that I have passed in the name of the file in it’s call.
CHECK AGAINST LISTS
In this first segment we break apart the string passed in, into a list based upon the location of underscores in it. Then we can take the length of that list which we expect to be four and immediately check if the user has too many pieces or too little.
If they have either too much or too little, then we can begin our results list.
Our Results list is the list of strings that will be sent back out to the user eventually, so it's important that they are clear and descriptive.
Now in this segment we get the length of the list, and iterate through them touching on each part of the name to decide whether or not it passes the list. The first part of the name is unregulated simply because the rules needed in core naming is vast and not something I decided to tackle with this project. Hopefully though, people will use this first segment for things such as the character's name, or saying that the prop is a flask or a lamp, etc. To skip over evaluating the first part of the name, I set (i) equal to 1 right away to skip the first element in this zero indexed list.
The second element of this list is the description. And so we check if that part is contained within the list that is user defined. If it is, that's great but we don't have to do anything, so we only check if it is NOT contained within. If not, then we need to add to our list of results that tells the user what they did wrong.
The third part repeats the same process as the second part but with the list of potential states instead of descriptions. This list is also User defined.
VERSIONING ISSUES
The final portion of the naming convention requires a bit more in depth validation. Considering that each of these following things are valid answers: test, test03, final, ver12, ver05.
To account for each of these situations, we first had to determine what part of the string was made up of letter and what was made up of numbers. For this, a regular expression was helpful in splitting up the pieces into manageable chunks.
Match group one, is always the letters from the string, and Match group 2 is always the numbers from the string. Knowing this, it was much easier to check the letters against our acceptable options. Once again, our logic thrives on when there are mistakes caught as opposed to when things are correct, as those do not need any action. So we check for a few different ways that the input could be wrong and for each we add to our list of things that are not quite right about the name to show the user.
Finally we have an else statement at the end to catch any outliers that do not include any of the needed components. We add this to the list of results to remind the user that they need one of these options.
At the very end of this loop, we iterate the number up and let the while loop continue until it's completion.
WHAT TO SEND BACK
and finally we chose what to return back. The logic here being that the list we defined at the start to hold all of our results/errors would have stuff in that list if there were errors, and nothing in it, if the name passed all the rules.
So if the list isn't empty, then return the list, if it is empty, return None or what most people think of as Null or Empty.
This is why in our testing harness we had it check what was returning, if it was NoneType, then the name must have passed all the tests!
The is the core logic of validating the file name the user chooses to save as, but now we need to make sure that we can stop them from saving if it failed any of the tests.
Comments