Managing Assets for 3ds Max
One of the primary challenges today is the integration and control of assets in production environments. Providers do their best to develop plug-ins or streamline a system for users to collect, install, and use the assets, but the constant upgrades and patches of the software place a heavy load on their teams. They also have to combat pirating and budgeting constraints, making it difficult to address the problem quickly. Generally, this leads to a system where in-house managers become librarians—downloading, storing, and distributing the data.
The situation becomes more complicated for those in more massive operations that involve licensing/rights, remote management, tracking, archiving, updates, revisions, quality control/review/acceptance, compatibility, categorization (per scene), and more. For each of those, some procedures include controls such as file naming conventions and structures to share, review, and track. This is the base of the production environment, embedded into users' brains through years of training, testing, trials, and sometimes tribulation. Sounds costly, right? Well, it is. These are all complicated tasks, but the key to them (and pretty much anything else) is to break them down into individual smaller steps that become manageable. In this article, I’ll be discussing some of the tools available to do just that.
Mapping it Out
Mapping out the system you’ve developed to control your assets is essential. Simply put, it’s a roadmap available to anyone who aims to improve the route. Without it, we drive blind. Refer to Figure 1 where I mapped out a basic approach to managing digital assets for small operations. I’ll be discussing various tools and methods your users can implement to get more value from the work they do through each of the steps.
Figure 1: Asset Management System (basic)
Repository
The storage requirements for assets is extraordinary. Couple with that protection, backup/backup redundancy, and associated costs and it’s hard to ignore the impact they have on production. Then add to that the increasing power of the software to work with more massive data sets (meshes generated from Zbrush/Lidar, for example) and file bloating becomes a significant problem. Server costs range in the tens of thousands of dollars, so merely purchasing more is not a viable solution.
To combat volume and file size, we need to implement a few rules. The first rule is to use only the highest quality assets and archive the rest (but provide an image of the archive for reference). For example, I can’t think of a situation where having 17 cherry blossom trees would be necessary, but I’ve seen users with them. Imagine compounding that file with three LODs (level of details) that we were required to split out into separate files. That would be 51 files. A quick look online shows a cherry blossom tree file (excluding the textures) to be roughly 74 MB. The 17 files alone would be 1,258 MB (1.3 GB) excluding any of the LOD files or textures. You see how quickly this compounds. It’s easy for users to ignore this, but it’s essential for the manager to understand this cost and mitigate it as best as possible.
To determine the highest quality asset, there are several factors to consider, but I can think of a particularly good example to mimic generated by Turbosquid (www.turbosquid.com), the world’s most extensive library of 3D models in any format. Introduced not too long ago, their Stemcell models follow strict guidelines including (but not limited to) clean geometry, limited polygons (minimal density), texture requirements, and PBR workflows. While your structure doesn’t have to follow their standard (though you might research the benefits), developing controls like that will ensure you can reuse the data as much as possible.
That brings us to the second rule, which is to reuse data as much as possible. Continuing with the 17 cherry blossom tree files I mentioned earlier for an example of what not to do, each of the trees had a texture file for the bark. The problem with their files was the texture file was the exact same, simply copied 17 times for each of the versions of the tree. The key is to develop systems to store items such as textures like these so the files can reference the same one. Following rule number one, this allows you choose only the highest quality textures, allowing you to produce the best content with the minimal amount of load on your systems.
Tracking
Making it simple to use data helps to reduce duplicate files or users spending unnecessary time re-creating something that might already exist. To do this, we need to search for them. We accomplish that by implementing a way to store data and track it, which we accomplish through metadata files or plug-ins. Probably the most powerful example of a plug-in capable of this that I know of is K-Studio’s Project Manager. Using the Manager we can store data that we can use to search our asset library. For example, if we have one hundred files called “sofa-xxx,” it hardly does anyone favors. However, if there was information tied to that file such as the style, material, and color, we can search for any one of those where the manager can display the items found. See Figure 2 for example.
Figure 2: Project Manager tracking system
Structure and Versioning
We can use metadata, or tools such as Project Manager’s information and comment section, to assist with structure and versioning as well. Users can add information about revisions they completed, dates, reasons for revisions, and more—a necessary step to minimize the amount of data we are storing by reusing assets across multiple projects. As a manager, it is necessary to standardize required data while allowing the user to input their notes. Required data might include geometry type (polygonal for example), polygon/vertice count, revision dates with a reason for it, classification systems (types, colors, styles), and more.
Tip: By using information/metadata to track versioning, rather than something like a naming convention with dates, we can ensure scenes don’t lose referenced assets and that they are using the latest version.
Check In and Check Out
Just opening a file and saving it is a form of checking in and checking out a file. While vaults and programs have been developed to access files, edit them, update them, and add user notes, I’d like to focus more on the data we can use to track files users have checked in or checked out. There are different methods, but one I work with includes a script that copies the log files generated by the software with the user's name to a directory I can access. The log file generated by 3ds Max® stores a significant amount of data, and we can control the number of days the data is tracked or limit the amount of data tracked by file size. Using those files, we can determine which users have accessed and find those users to assist with troubleshooting, or perhaps merely find a file a team member might have been working on when they are out sick for a day (if we don’t feel like calling them at the ball game).
Tracking (Again)
Limiting changes to assets to specific team members who are aware of potential risks of changes is essential, but it can be just as helpful for those members to be held accountable for communicating those changes to others using tools such as Project Manager, or alternative applications like Smartsheet. I recommend doing some research to find the most appropriate application to get your teams on board.
