Skip to main content

Tech Art Bits: Basic DCC Environment Setup

When setting up a new DCC, or building basic infrastructure for your studio's artists to use, one of the most critical components to get right from the start is how they launch, use and interact with their content creation tools, otherwise referred to as DCCs (short for Digital Content Creation software).


If you export your content from, say, Maya, you want to ensure that all Maya files in your project are set up correctly, using the same unit scale, system units, up axis, frame rate, etc... 
You also don't want any of these things to be left up to the artist; there are simply too many things that can go wrong, and the cost of issues like this not being caught until a great deal of content has been produced incorrectly can potentially be crippling for a project.

So how do you ensure a DCC is setup for the artist, correctly, every time they launch it? The simple answer: give them a launcher that does it for them. "But" I hear you say, "launchers take time to build, they're complicated, unstable, and require a whole deployment infrastructure to update them!".

Yes and no.

No, an application launcher does not have to be complicated.

All you really need is a well-written .bat file. Every Windows machine in the world understands .bat, and it doesn't require any set-up for the artist to run them. Additionally, bat files can have shortcuts created to them, which makes it easy for the artist to create desktop shortcuts to the launcher in question.

Lastly, as far as updating the launcher file goes, depending on how big or how small your infrastructure needs to be (depending on studio and project scale), you can implement an update mechanism by using a technique as simple as hosting your .bat files on an intranet network, and having artists use them as a way to launch their DCCs. This means you only have to update the files on the network, and everyone will always have the latest version. This method of updating application launchers if fairly common in the VFX industry, in fact.

But what should be in this .bat file?

Glad you asked!

set PYTHONPATH=%PYTHONPATH%;%STUDIO_ROOT%/Common/Python/Internal;
set PYTHONPATH=%PYTHONPATH%;%STUDIO_ROOT%/Common/Python/External;
set PYTHONPATH=%PYTHONPATH%;%STUDIO_ROOT%/DCCs/Maya/Common/Internal;
set PYTHONPATH=%PYTHONPATH%;%STUDIO_ROOT%/DCCs/Maya/Common/External;

start "" C:/Program Files/Autodesk/Autodesk Maya/maya.exe

Let's break down what's happening here.

There are three things to pay special attention to here:
  • We're assuming there is a %STUDIO_ROOT% environment variable available. This variable is assumed to contain the local Tech Art code base.

  • We're assuming the local tech art code base in this studio is using a "Common" vs "DCCs" structure, where all commonly usable code is kept in the "Common" folder, and all code specific to a given DCC is kept in its own folder, specific to that DCC.
    • Note: in practice, it is a good idea to do this, and to go one step further; branch your "Maya" folders per maya version, e.g. "Maya/2020", "Maya/2019" etc. This should allow you to branch your entire Maya folder, and do the work required, if any, to port your code and do fixes before moving artists over.

  • We're assuming Maya is installed in the default install location.
    • In practice, it is strongly recommended to have your artist machines set up to install their DCCs in the same location, even if that is not the default one. This means that you won't have to write code to deal with any setup differences for a long time.

So what's next?

Now that you have the important bits, you can start building on top of it; add additional environment variables for your own use, and have your code respond to their values or presence. Environment variables are great and you should use them often. They are accessible and work on any Windows platform, and allow users and developers to expand upon existing infrastructure, often without any code changes. But that topic deserves its own post.

To summarize

  • You don't need to have a fancy application launcher to build a custom deployment
  • You can write a fairly advanced deployment using nothing but Windows Command Line batch files.
  • Environment variables are great, use them.
That's all for now!

Comments