Topics by tag:
Recently published articles by Dave G:
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.
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.
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:
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.
UPDATE: This bug was fixed in Maya 2015 SP4
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.
3 notes | Permalink
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.
I was looking for a plug-in or script to overwrite ZBrush saves without prompt (still haven’t found one) and found this pretty sweet plug-in that lets you hold a single modifier to change the hardness and the brush width for brushes, Photoshop style:
2 notes | Permalink
Aside from the texture path bug for Windows machines that’s been fixed, I’ve been steadily adding things to Mari Me (Download) that I think will be welcome additions:
From the changelog:
Also, I’ve added a Utilities menu where I’ll start to add things that you’ll want to do inside of Maya for a workflow that involves Mari. Stuff like this UV Tile GUI to move and maximize UV shell space across UDIMs:
and I have put my AutoTileMe script in the Utils menu as well:
It now graphs the File node network at the end so you can see the structure and clearly know which to connect to your shader (the top one in the hierarchy).
Lastly, the Just Save OBJs script in the Utilities menu saves out an OBJ for selected objects to a project/GoZ folder for use with Mari (or ZBrush) with nothing sent to Mari. I’ll eventually update that to work with the smoothing and displacement options.
UPDATE: Mari Me has moved to GitHub:
So, after tiring of Mari’s new project panel and its non-OS version of its open dialog, I decided to make a script (Download here) that sends the selected mesh from Maya to Mari for painting. It has some nice options that I think will be welcome:
The features are shown in the video here:
If you don’t choose to send an existing texture, it will create a 50% grey “color” channel that is set to the resolution of the slider, which snaps to Mari’s supported resolutions.
I added the ability to send a tessellated and displaced mesh even though I know that Mari does displacement previews but these don’t use your actual values from your existing Maya model so this script creates a mesh that is closer to what will render. It’s not the best solution since the geometry can be really jaggy but it’s better than nothing. Just make sure you only run this displacement script on cage-type geometry because it smooths the mesh and then tessellates so it will extremely slow if it’s a already high-ish res mesh.
As you can see from the video, I originally made this script to send Python to the clipboard since I didn’t see any documentation for the command port that is used by Nuke to talk to Mari but there was an example script that showed that it receives straight Python. So my script does all the gross code escaping and wraps the Python commands in a single line and passes it to Mari.
To get the script to speak to Mari, you need to make sure that Mari’s command port is open to the default port of 6100. This is in the Scripts portion of the Mari preferences.
The only limitations to the script right now are that it needs to have a relatively simple material applied to the selected mesh – it will simply fail if you have a V-Ray Blend Mat applied to it, for example – a fix for this will come soonish. You also have to have a mesh selected when you run it. Also, textures are currently sent only as RGB, with no scalar option. This will come later and I’d like to add an auto-detect for the applied texture res for the slider. Tiled mats are not supported – obviously that is a dealbreaker for many but hopefully I can get that working some time in the future. I haven’t tested it in Windows or Linux but it should work fine. The exported meshes are stored in a project_path/GoZ/ folder because I didn’t want to create a different folder for OBJs that I use with my ZBrush meshes.
Slowly getting my brain to function after the loss of my dad and put up new V-Ray Tuner version with some features:
5 notes | Permalink