I was discussing my Library Management software for handling 3d assets in a blog entry I wrote on the Ivolve Studios blog. I thought that I might take a moment to expand on the technical aspects of it a bit further. Over the years asset management or library management has become an ever more challenging problem. Commercial solutions are often large all encompassing pieces of software that tends to shoe horn the way you work to fit there pipeline. As I begun to research different solutions It became obvious to me that a small light weight artist focused solution would work best, it would empower artists and have a small foot print on the pipeline.
3d Studios that operate in the Architectural Visualization and general 3d animation spaces often create library's of assets that can be used in new projects. In my experience these library's usually consist of a large number of folders to create a structure that should be easy to find things, this however is rarely the case. That workflow usually results in a couple seniors who have been there the longest that know where everything is and all the other artists have no idea. Once we had decided to go down the custom road there where a few things we had consider:
- What did we actually want our software to do?
- How did we want it to work?
- How were we going to implement it?
- Development Cost?
These 4 points where are guiding light during the development stages. We identified key features that we needed and features that we wanted to add at a later date. These features included:
- Keyword Search. Search is the modern way to navigate larges amounts of data, our library was no different. Search also has the added bonus of requiring little to no time to learn for new artists.
- Small lite weight interface. Above all we wanted an uncluttered interface. 90% if the time artist would either be saving an asset to the library or adding one to there scene, early on I decided that administration tools could tucked away.
- User accounts. Having user accounts with different privilege was a must as we wanted to limit artists ability to remove assets in certain circumstances, for instance blocking a junior from deleting assets.
- Speed. Our software had to be fast it needed to load as quickly as possible.
Knowing the features we needed to include we moved on to the implementation. Things that we knew we wanted in the implementation were:
- A human readable file structure.
- Modular design. We wanted to promote code reuse and ensure that developing either new tools around the solution or expanding it in the future would be a simple process.
- Database for the back end. This decision was made early on. We experimented with XML, flat file databases and in the end we settled on MySQL. It was readily available there are plenty of DBA's that know the software, plus we like to use Open Source software when possible.
At this stage we got coding since we where developing the first version exclusively for 3d Studio Max we chose Max Script and .Net as our weapons of choice. We started by developing a bunch of library code for simplifying interaction with the database and files. These were all unified under a common namespace SQLTools(). Moving forward we developed more library's which handled users (UserTools()) and assets (AssetTools()). SQLTools() was written primarily in .Net and then wrapped in max script. Each of these librarys is generic by design and have proved to be very versatile and have now grown in to mature library's.
All the library's were brought together under a singular namespace assetMan(). This was very important as it enabled us to replace any of the underlying library's very quickly and easily should we need to change the back end etc. After about 6 weeks we rolled the first version (Below) and released it to the artists. This first version worked well and was used for some time, we used this time to identify exactly what we needed to change.
We Identified a number of areas for improvement such as the need for rendered previews of assets. We also decided the next version should not be limited just to 3d objects. As we kept working we finally rolled out a new version with a new interface that was greatly simplified. From here we moved on to implementing the rest of our planed features including keyword search, rendered previews, support for textures (images files) and shaders. This latest version proved very successful with a significant gain in production speed.
We have now gone on to add support for Fusion composites, PSD's and Nuke files which can be accessed and managed through a standalone application written in Python. We are hoping as time permits to write native interfaces for each of these applications. That back end has undergone some changes as well the most significant is the abstraction of data to allow for arbitrary file types and applications.
Thus far we have been very happy with the progress of the software, I am hoping to make more information available as I can. I have since been working on a new solution that has includes the features mentioned above along with a host of improvement including a very nice web interface. As I get time I am sure it will become the subject of an article.
Thanks for reading, if you made it this far I am very impressed!