Dave Girard's 101 Autodesk® Maya® Tips is now available in Kindle, interactive iPad edition and DRM-free EPUB/PDF editions. Work faster, cry less. Read more about the ebook.

Follow cgbeige on Twitter

Topics by tag:

Recently published articles by Dave G:

Free downloads by Dave G:

Mac OS X-only downloads:

Mari Me 2 – a Full-featured Python Script to Send Painted Meshes between Maya and Mari

Now that Mari 2.6 and Maya 2015 are out, I think it’s time to release Mari Me 2 that is a complete rewrite of the MEL version that is now much more powerful than that old script was. Aside from being able to send stuff from Maya to Mari, the new version has a ton of little goodies that aid working between Maya and Mari without the need to look at a single dialog box. Mari Me 2 can both send and receive objects to Mari, updating metadata-tagged materials for identification across sessions. It works great as a quick way to jump back and forth for stuff like Mari 2.6’s texture transfer feature that bakes textures between different mesh topologies or UV sets:

The transfer feature is better than it looks from those results – I was just kind of lazy about my alignment of the two different meshes in Maya. Mari Me also has a smart way to update your existing materials that is renderer agnostic. It doesn’t care what type of material is used on the mesh and will simply update it based on the channel name within Mari. If your material’s emissive channel in Maya is “blinn1.incandescence”, just name the channel “incandescence” in Mari and when you send it back to Maya, it will link up to that channel in the material:

That’s why I created a AddNewChannel-VRayMtl.txt setting preset for standard V-Ray Materials that you can paste into the channel presets section your Mari.ini file – those are pre-named to link up with the slots of a V-Ray Material and it would be very easy to make one for Arnold, RenderMan, etc that you could share on the Github page. If you send a texture to Maya from Mari without having sent anything from Maya to initiate those material metadata tags, it will just import the textures and you’ll see the file nodes in the Hypershade. Mari Me’s metadata tags don’t create any sort of plug-in dependency so nothing will break and you won’t receive any warnings if you send a scene to someone without it installed.

Automatic UDIM sending and loading
Mari Me 2 has robust support for UDIM-tiled textures:

If you are running Maya 2015 or above, that supports the UDIM file name variable, Mari Me will use that instead of importing and manually tiling all the UDIM textures. It will also recognize these 2015 UDIM names when you send tiled textures to Mari. It should also work fine with multiple meshes and a mix of tiled and non-tiled UV meshes. I tried to make it smart enough not to break with these production workflow variables but it’s possible stuff slipped through so let me know if you see anything and I’ll see if I can find some time to fix it in the near future.

Alembic support
Mari 2.6v1 got support for Alembic animated meshes and the Python import syntax is the same as importing OBJs so I added support for exporting animated meshes from Maya to Mari via Alembic:

Other stuff
As you can see in the interface, there are a bunch of other little tools and tricks in Mari Me 2:

There are no file format options so everything is sent back and forth as TIFF, since that format can accommodate all bit depths and all working files are in a projectpath/MariMe/ folder so there is no risk of clobbering your existing assets.

Released under a BSD3 license
I started the Python version of Mari Me as a “Pro” version that was going to be monetized but decided not to after getting a new job that I’ll get into later. Because I’m going to be super busy with this new gig, I’m going to have to release Mari Me as unsupported but I released it as open source under the BSD3 license for studios or individuals that want to change the code and use it for their own and they can decide whether or not they want to fork it or not on the Github page for Mari Me:


The old MEL version is no longer on Creative Crash. Read the Read Me file because that explains the setup.

6 notes | Permalink

Nimble Tools Uninstancer Source Available on Github

If you work with particle animations, you probably know about Nimble Tools Uninstancer. It’s been around for years and unfortunately the developer stopped working in VFX but he posted the source scripts (the pre-built Python plug-in broke recently) but they have been updated and posted here:


It’s the best uninstancer around so look no further. Verified working in Maya 2014 and 2015 late beta.

0 notes | Permalink

A Look at the Mac Version of Unreal Editor 4 

I’ve been working with the Mac version of Unreal Editor 4 for a week or so now and am really loving it. I had some experience using UDK3 found the workflow and interface less than great, and it seems they agreed with me because the changes in UE4, as far as workflow go, are almost perfect. And, even though there are a few bugs with the launch version that are being actively squished, the Mac version is no half-assed port. While gaming on the Mac will never replace gaming on the PC, Epic is clearly bullish on the future of Mac and iOS as gaming development and gaming platforms respectively.

Pretty much everything you want is there. Multithreaded light map baking, Matinee, Blueprints (the stuff that replaces Kismet), those GPU-accelerated particles with vector grid and collisions:

Performance looks worse in that video than it is due to a screencap / GPU combo.

You get that sweet shader editor:

Really nice Maya-to-Unreal material support so you can import one combined mesh into Unreal but still get all those unique shader references to edit or even replace:

Post-process volume with bokeh DOF and colour grading:

IES light profile support:

Global Illumination without tricks:

It all adds up to an impressive show considering they had to do this all for OpenGL:

The only noticeable omissions from what I can tell so far are:

- Displacement tessellation for OpenGL shaders
- Oculus Rift Mac Support (this is in Unity already so I hope this comes soon)
- The auto-UV reconstruction stuff isn’t ported yet

Edit: Unreal Me stuff removed
I took down the Unreal Me script because Unreal Engine now lets you import baked animation without bones with the following workflow:

1: Group your baked key animation objects in Maya.
2: Export to animated FBX 2013 with the group selected
3: Import the FBX with the following settings:

Make sure that Import Animation and Import Rigid Mesh is set. From then you’ll get your non-joint based animation imported correctly.

Oh, the joys of scripting for a program you’re still learning :p

3 notes | Permalink

Simple Snapshot Script for Automator to Back Up Your Script Work

I’ve been trying to finish up Mari Me and like to create snapshots when I think something’s going to break when cleaning things up, so I decided to make a simple snapshot script for Automator that prompts you for input for the name – “BEFORE_BROKE”, for example and then copies the current Mari Me files from disk to the snapshot folder:

I made a generic version for you to download here if you want it. Just replace the paths to the file and be careful to keep the ${1} variable in the script text since that’s the variable name that is passed from the dialog.

0 notes | Permalink

Another Mari Me Pro Teaser: Support for Updating Any Material Type for Any Renderer

One of the trickiest things to think of when you build support for updating file nodes of shaders is how to support arbitrary materials and new information updating different shader elements. I had no experience with this before but I think I found a pretty elegant way to do this with metadata tags that would be independent of renderer or file node names. So, my latest addition to Mari Me Pro is probably its most bad-ass:

Notice that it is updating the existing shader with the new “reflectionColor” channel from Mari. All you have to do to keep this workflow working is use your shader’s connection names for your Mari channels. So this would update any V-Ray, mental ray, Arnold, PRMan shader without any explicit support for those renderers. It’s future-proof.

I want to thank Roy Nieterau for his awesome UV border detection script for Maya. This helps prevent the creation of extra empty UDIMs in Mari and it’s also useful for ZBrush, which can have problems with maps generated for meshes with UVs touching the border. If you tried to do it with non-API Python or MEL, it would take forever with large meshes and this script can detect UV shells on a border for 3-million poly meshes in less than half a second. Great stuff.

0 notes | Permalink

Awesome Architectural Shader and Procedural Nodes for Mari by Nicholas Breslow

I’ve been using this great set of shaders and procedural nodes for Mari and thought I’d share the link. The Maya mia_material_x style procedural shader with Fresnel falloff and IBL controls are a huge step up from the Mari 2.5 Cook-Torrance shader:

And anything that can add more non-destructive procedurals to Mari’s excellent layer nodes is a boon. A boon, I say. A boon.

1 note | Permalink

Mari Me Pro Teaser Video

I’ve been working on a completely redone Mari Me script for Maya that is written in Python (the original Mari Me was done in MEL) and adding new features to the Python version. The major features for the Pro version include:

  • Multiple mesh support
  • UDIM tiled texture support
  • Receiving texture and UDIM changes from Mari in Maya (round tripping)
  • Detection of existing texture resolution so you aren’t resampling when they are sent to Mari
  • Alembic support to send animated assets to Mari from Maya
The trickiest part was how to handle sending assets back and forth between the two applications and it’s almost ready for full public consumption (nom nom). The latest and most crucial step was to make the mesh tracking smart enough to work across sessions and mixed projects to uniquely identify assets to update via metadata within both Maya and Mari and that is working well: Notice how I have a Mari Me menu added to Mari. That’s another component of the Pro version of Mari Me. As the name suggests, the Pro version is quite a lot more involved than the Lite version of Mari Me but, due to some exciting recent developments, I now plan to offer Mari Me Pro for free since it was initially going to be a monetized script. More on that and the release of Mari Me Pro later.

1 note | Permalink

A Note About Setting Optimal V-Ray Settings for Distributed Rendering

It’s possible if you’re a V-Ray user that you’re wasting time when doing distributed rendering with V-Ray light caches. A while ago, I added a modification to V-Ray Tuner that prompts you if you hit the Optimize button when using distributed rendering is enabled. It will ask for the max threads of the machine with the most threads. While the final render will always use the right amount of threads for your slave, the light cache passes should be set to the max thread count for all machines. So if you have three machines in your DR list with the following configs:

machine 1: 6 cores/12threads
machine 2: 16 cores/32 threads
machine 3: 8 cores/16 threads

You should set the light cache passes to 32. Or just enter 32 in the Optimize prompt in V-Ray Tuner. This won’t cause issues for your machines with fewer cores/threads. If you aren’t using DR, it will set the LC passes and render settings to use the max threads for your host machine, without a prompt. Some people may be avoiding the Optimize button because they don’t want it screwing with your setup or scene but it just does this minimal setup. I also hate scripts that do mystical magic to your stuff to make it faster, leaving you to guess what it’s modified. Any feature in V-Ray Tuner that deals with quality will always be very clear about what it is changing so there are no surprises.

Stay tuned to read about V-Ray Tuner 4 features. I have added a bunch of things like a Distributed Render slave manager that should save people plenty of time when dealing with networked nodes.

0 notes | Permalink

A mental ray Batch Render Script to Work Around Batchrender’s OS X Mavericks Issue

I haven’t used mental ray in years and I have been doing batch renders with my V-Ray command line script that I wrote for V-Ray Tuner so I feel a little bad that I didn’t catch the incompatibility with Mavericks and Maya’s batch render application. So here is a mental ray version of my command line script that writes out a batch file that opens in the OS X Terminal and uses the Maya Render binary, not Maya batch, so it works fine with Mavericks. Just enter “commandLinerMR” in the MEL command line and it will render your current scene according to the file’s properties and animation settings length:

It also sets the thread flag to your max cores so you don’t have to configure it manually. It also works with Linux’s xterm window or Windows’ command prompt, so feel free to use it if you just want a way to view render progress in a terminal while rendering. If you want to edit the script to work with Arnold or another renderer, feel free. It’s pretty simple once you look at the code.

There’s no official word from Autodesk on when a fix is coming for the batch render and Mavericks. Hopefully there will be a service pack before 2015 is released because the new Mac Pro ships with Mavericks and that could affect a lot of Maya users.

2 notes | Permalink

Actually Empty Trash – Automator Workflow for OS X to Empty Trash if Items Are Open

The OS X Mavericks upgrade has been pretty painless for me but one thing that seems to be an issue is that QuickLook likes to lock onto files so they think they are open. It’s trivially easy to get the “File in use” error when trying to empty the trash now. Until Apple fixes it, you can try the Secure Empty Trash, but that will be slower since it does multiple passes to write zeros over the space on the disk where the file data was before. This is potentially more of a problem also, if you don’t have backups since a disk data recovery tool won’t find these files. So I made an Automator version of the two-line shell script I use to empty the trash in these cases:

rm -rf /Volumes/*/.Trashes
rm -rf ~/.Trash

That actually deletes the trash folder but the OS recreates one with proper permissions anyway. The Automator workflow can be downloaded here: Actually_Empty_Trash.zip

See it in action:

Use the Shortcuts panel of the Keyboard system preferences to add a hotkey to the service and you’re set:

The script is not dangerous and there is no way it will ever delete anything not in the Trashes folder but, nevertheless, it comes with no guarantees.

0 notes | Permalink