One thing you want in your pipeline is a way to distribute your tools to the artists through the shelf, you can do this several ways:
Have the same shelf file on a network drive used by everyone but with restricted write permissions
Copy the preference shelf file to the user preferences each time you update it
Build the shelves automatically each time you launch the software
The first twos are the easiest to implement and maintain, but they have one major drawback: the users can’t customize their shelves. Soon enough you are going to have to fit that need, limiting basic user customisation of the software they use daily is usually not a good idea. That lets us with the third option but it can take a lot of time and is more error prone… Well here it is!
There are several ways of launching a Maya without interface to process some operations in a way more efficient way than launching the GUI. There is the Maya -batch option (mayabatch on windows) and mayapy, also called Maya standalone. Mayabatch is a complete headless Maya without GUI, while mayapy is a python console with the Maya modules imported.
same environment as Maya GUI
easy to use, exitcode are consistent
you get all stdout info of Maya starting
stderr is empty and incorporated in stdout (on windows)
can’t be used interactively (rpyc maybe?)
stderr is correctly separrated from stdout
can be connected to a debugger
can be used in an interactive way as an idle process
you don’t get any stdout info of Maya starting
can be different than a normal Maya, some plugins and scripts may not work
problems when initialising
problems when exiting, exitcode may not be a good reflection of the actual job state
I personally exclusively use mayabatch instead of mayapy because of a lot of bad experience with mayapy and because the calls are cleaner. I even changed a whole studio from mayapy to mayabatch because they had a lot of problems with renders not being done when they were marked as done, the outputs of jobs completely were different from the real execution of jobs. Using mayabatch fixed all of the problems at once.
I also encountered a lot of problems when Pymel was being used too, if you have problems you should investigate that part if you have some or better stay away from it.
Contrary to popular beliefs, it’s totally possible to do your playblasts in batch mode. It can be very helpful in a lot of workflow: - create a missing playblast without the hassle of opening Maya UI - move all playblasts calculation to a remote computer to be able to continue to work at the same time - update playblasts of all shots at once on a renderfarm to make an up to date montage of the movie All of this is made a lot easier and faster when doing playblasts in batch mode
Both mayabatch and mayapy can do this, the main difference is the background color being different and mayapy being a little finicky.
The Maya file to open is directly in the command but you can also put the opening of the Maya file into the script instead. This way it’s possible to do a batch of several scenes on a single node to save time on the initialization of Maya, but it’s not worth it. If it crashes it’s harder to know what happened and which job was processed or not. By deploying one job per scene you can send it to different computers on the renderfarm and see the general progress.
Apart from the expected Python 3 upgrade, two little things slipped through Maya 2022 are 3 new environment variables regarding Maya batch mode.
The MAYA_BATCH_STDOUT_LOGGING_LEVEL and MAYA_BATCH_STDERR_LOGGING_LEVEL set the logging level of outputs of stderr and stdout. The accepted values are all (stderr default), info, result, warning, error, and none (stdout default) It should only change the behaviour of mayabatch… but when testing it I haven’t seen any differences. Same with mayapy. If anyone has more info let me know!
When Maya is in batch mode, the MAYA_DISABLE_ADP env var disables the analytics sent to Autodesk, along the same lines as the ones described in this article. They should all be set to 1 to improve your Maya experience: MAYA_DISABLE_CLIC_IPM MAYA_DISABLE_CIP MAYA_DISABLE_CER MAYA_DISABLE_ADP
Oh, and the Maya console is hidden by default now, yay!
One thing that always mess me up when I go back to Windows is its way to move and resize windows, I am more used to some windows managers in Linux where you just have to press a key and click anywhere on the window to move or resize it. It is very handy and intuitive, you don’t have to aim for the title bar or anything and do as you please.
Thankfully I recently discovered a wonderful software that does just that: AltDrag
Sadly it has not been updated since 2015, but it does a lot of things already. I urge you to test it as it drastically changes the experience on any computer. By default the key is set to Alt, but it’s best to put it on Windows (Meta) especially if you do 3D work. You can also change the transparency of windows as well as the “Always on top” and “Borderless” settings.
A lot of countries have their own keyboard layouts for special characters and accents. France for example has the AZERTY layout… certainly one of the worst of all with an accent acting as a dead key (^¨) and some other times with hardkeyed letters with accents (éèàç and even the ù which exists in one and only ONE word in French). This is not logical and very badly thought out, as well as a complete waste of space.
In summary Azerty comes with:
the A and W switched with Q and Z
the M on the second row next to the L
the top row numbers activated with shift
a lot of special characters switched all around
some keys blocked by diacritic characters (éèàçù)
And even worse:
the numerous bugs in tons of programs because of all that
and let’s not forget all the weird shortcuts…
and let’s not talk about the accentuated capitals…
Azerty is quite bad all around, and one way to fix it… is to switch to Qwerty. Yup, Qwerty is superior. It’s way easier to do accents and your experience will be a lot better overall.1
Following my previous article regarding startup and shutdown time of Maya, I will share some tips, some are just personal preferences, but others fix some nasty old bugs, increase stability or speed and you should just plain use them. I added a script that combine all those improvement at the end of the article to put in your userSetup.py so that your preferences are set the first time you launch Maya.
Disable the Load/Save UI layout from scene
This is quite important and would urge you to do it. This functionality can be quite handy but it is a very bad idea to use it, it can lead to crashes, slow opening times, and scenes impossible to open… unless you deactivate it in the preferences. It can feel frustrating not to use it at first but I can assure you will enjoy it pretty soon!
A good habit is to actually create some custom layouts independently of scenes. Open a new Maya session, organise your layout and panels, and save it! Especially since Maya 2017 with the new workspace feature. For users using previous versions, the layout feature is bugged and it won’t save any floating window outside of the main Maya window. Another solution is to script your layouts and open floating windows with a click of a button. Probably best to use a bit of both solutions.
It is even better than the “retrieve UI from file” because you are able to work directly with the layout you are used to, instead of the one the last artist saved the scene with. It can also load the scenes WAY faster and it is more reliable.
Since Maya 2016, it launches with a set of at least 3 acwebbrowser.exe process. Besides all the fuss it creates in the task manager and resource hog it can be, it can also slow down Maya startup and shutdown times by more than 200%, up to 30 seconds each time! Those process are some chromium engines that connect to the web for different tasks, especially regarding registration. Quite a useless thing to wait for each time you start Maya if you ask me. Messing with the install files is a bad idea as it will probably prevent Maya from launching, it’s much more easy to disable that behaviour by setting these simple environment variable MAYA_DISABLE_CLIC_IPM and MAYA_DISABLE_CIP to 1.
If you have no internet connection or if you are in a huge studio with tons of artists using Maya, it will surely make a huge difference!
If you are on Windows, you could also disable the console window that appears for each Maya instance. It’s a good debug tool so keep in mind that you’d may have to reenable it in case you encounter a problem, but I feel it is way more pleasant without that window polluting the workplace. To do that just set the environment variable MAYA_NO_CONSOLE_WINDOW to 1. There is no need for that on Linux or Mac because they have a real terminal.
And dont forget about my other article regarding the performance of the VP2 viewport with MAYA_DISABLE_VP2_WHEN_POSSIBLE.
A strange one that screwed some of my simulations. In Maya 2015⁄2016 if you emit fluid from particles with the lifespan mode set to Random range or rand() in lifespanPP, the particles don’t get killed if you emit the particles and the fluids at the same time, altering then your simulation.
Keep in mind that there isn’t any max count for the particles! It’s just limiting the max count by itself in a strange way. Some particles are killed but the majority aren’t.
The basic solution is to do the simulation in two steps, cache the particle while deactivating the fluids then do the simulation of the fluid.
If you are working in a multi-tiled UV textures environment, Autodesk introduced a way to manage that kind of setup in Maya 2015 for file nodes. It is compatible with the Zbrush, Mudbox, Mari way of setting the tiles plus a custom one.
It’s great and all, you can now see all your textures in the UV editor but sadly… there are some limitations, such as you can only view the textures with the Viewport 2.0 and not the faster, less buggy Legacy one. As you may already now, the Viewport 2.0 is not really usable yet outside of playblasting, modelling and shading, so it kinda defeat the whole purpose of the implementation of the tiled UVs.
You can “display” your textures in the Legacy Viewport by setting the Textured channel to “Combined Texture” in the “Hardware Texturing” section of the shader, but the result is really really bad.