Topics by tag:
Recently published articles by Dave G:
I got tired of opening the Create Render Node dialog from menus, since I use it so much, so I made another hotkey script. This will bind a material if you have an object selected (like the right-click Create Material selection) or it will just create a new node if nothing is selected, which is good for shader building in the Node Editor or Hypergraph:
global proc createNoderr()
if (size(`ls -sl`) > 0)
So, a while ago I posted a handy hotkey script to bring up the Attribute Editor for the selected object’s material but it didn’t work properly with face-level component selections, if there were multiple materials on the mesh (this is also a problem for showShadingGroupAttrEditor). You can see the difference between the old script and the new one here (with my Venetian Snares playing in iTunes – oops):
Here’s an updated script that works well – put it in your Maya hotkeys and assign it to a key combo. The openAEWindow at the start ensures that you don’t get that weird hiccup fallback to the shape node if the AE window isn’t already open. Here’s a download link (updated to work with object and face selections):
Put it in your scripts folder and call it from a hotkey with materialEditorHotkey; in the User hotkey text field:
Update 2: now does a select toggle for component mode, so you don’t lose your face selections when it does it’s thing.
3 notes | Permalink
I am pretty happy with the latest V-Ray Tuner 3.3 update. It adds a number of features that I now use constantly and I think they’ll be pretty popular. Here’s a break down of what’s new in 3.3:
It’s not shown in that video but the release script now has a palette with an option to keep the original swapped-out mats after conversion.
As always, let me know if there’s anything you want added or tweaked in V-Ray Tuner.
0 notes | Permalink
I got a PM on CGSociety about mental ray performance on Windows and I thought I’d post it here since it’s obviously of interest to Maya users. Here it is:I found this thread of yours [talking about mental ray in Windows performance vs. Mac OS X and Linux]: http://forums.cgsociety.org/archive/index.php/t-1058847.html I’m wondering if you were able to do anything to bring Win 7 mr rendering performance up to par with osx/linux? Basically, my studio has just built some new 24 core xeon e5 machines to replace our mac pros. By all other benchmarks these machines should be and are faster than our old mac pros, except mr rendering performance, which is actually worse. Our farm currently uses maya 2012 sp1. any ideas would be appreciated, thanks.
Here’s my response:Unfortunately, there’s nothing you can do except switch those machines to Linux. It’s not an OS or application-level problem – it’s with the compiler used to build mental ray on Windows (MSVC) vs. the one used on OS X and Linux (gcc). I know that Autodesk is looking into it but I don’t think you’ll see this change any time soon, unfortunately.
To elaborate on this a bit, performance differences between platforms are rarely the fault of the underlying OS. It’s usually the compiler that affects speeds and, in my recent review of the HP Z820, I saw a lot of these differences due to compilers. Photoshop seems to fall into the same camp as mental ray, favouring OS X by a large margin, whereas Photozoom Pro 4 is the exact opposite:
I’ve been doing hardware testing and benchmarking for years, and I know what I’m doing. All the test machines were similarly configured, same scratch disks, yadda yadda.
But notice the mental ray benchmark – once you run it in Linux, the speed problems go away. V-Ray for Maya users will be happy to know that Chaos Group addressed this a while ago and switched to the Intel C++ compiler for Windows, and that performs slightly better than Linux (and presumably OS X) with their GCC-compiled V-Ray binaries. The Intel C++ compiler exists for OS X and Linux so I’m not sure what performance is like when they are all on equal footing. I’d be more interested to see how OS X performs with the clang llvm compiler, since gcc has been deprecated in OS X for a while now.
After reading a post on CGTalk, I just realized that a lot of people think that the version compatibility listed with scripts on Creative Crash – where 95% of our Maya scripts are probably downloaded from – are accurate. They aren’t. A person will check for Maya 2013 compatibility, see it’s not enabled, so they don’t download the script because they think it’s broken by the 2013 update. This is correct to assume for non-Python plug-ins (.so, .dll, .bundle files) that are always broken by API changes in Maya, but scripts are almost never broken by Maya updates.
The problem with Creative Crash’s compatibility listing is that, as new Maya versions are released, they add newer versions to the compatibility listing but, by default, a script is listed as incompatible. I’m sure that half of my scripts on the site are listed as not compatible with 2013 because I forgot to manually enable compatibility for newer versions. I’ll do this now but then I’ll have to remember to do the same thing for 2014 and beyond. I just sent them a message to add an option for script writers to enable compatibility with new versions by default but I just thought that readers should understand that script compatibility should be taken with a grain of salt. It’s safe to assume older versions won’t work but newer ones will.
Similarly, some scripts are listed as Windows-only because the author has not tested them on Linux or OS X, but it’s very hard to write a script that doesn’t work on all platforms, so you can be 99% sure it will work on another OS.
2 notes | Permalink
After getting tired of manually setting project paths for files that were already open, I made a simple script that does exactly that and then prompts you to reopen the file so assets from relative paths load correctly:
The script assumes that you are using the standard project/scenes format, with the currently open file in the /scenes/ folder. There are some scripts out there can monitor your Maya session and do this automatically but I personally hate scripts that do stuff for me with added polling. Maya is a fickle beast, so the last thing I need is another thing adding potential instability. So, grab it here lest ye waste more time by doing it manually.
If you want the script shown in the video that opens your active project images folder, grab that here.
2 notes | Permalink
Frequently, when you work in Maya, you want to create a flat colour to mix with a utility like a blendColor or Multiply/Divide. Now that I use the Node Editor for all my shader networking needs, I want to type “Constant,” Nuke style and many Maya users are probably wondering why Maya doesn’t have a simple constant colour swatch. Well, it does. For anyone accustomed to using a linear workflow, the Gamma Correct is basically a Constant swatch with gamma controls:
This is obviously a very basic tip but it took me a while to think to use the Gamma Correct instead of a flat ramp, back when I was learning the ins-and-outs of Maya. Maybe this will save you some time.
So I’ve updated GoP with some handy changes which bring it up to version 2.0 (download link). If you don’t know GoP, it’s a script that lets you send selected objects in Maya to Photoshop for texturing. The original version used the OBJ format as a go-between but 2.0 now uses .dae COLLADA format, which has some nice advantages – most notably, camera support:
As you tell, that has great potential to be used as an aid for matte painting or texturing with specific angles in mind. By default, Photoshop opens 3D files as square, but you can get the correct cropping for your scene by matching the aspect ratio or dimensions of your Maya scene:
As you can see above, this also supports basic coloured Maya lights. I can’t claim any credit for this stuff. It’s just Adobe’s excellent COLLADA support that’s doing all the work. You may need Photoshop CS6 for camera import support but meshes will import fine. Anyway, this should come in handy as Adobe adds more and more 3D features to Photoshop Extended.
0 notes | Permalink
Sky Boy, 2012. Recent painting mixed with inket canvas print. Made and rendered the backdrop image in Maya/V-Ray with post tweaks done in Nuke.
3 notes | Permalink
If you do compositing in Nuke, you know it can be annoying to get camera data in and out of a 3D package like Maya or Max. Imported camera data quickly gets outdated when new frames are rendered, which forces you to jump back and forth between your 3D app and Nuke. Fortunately, yesterday I discovered a script for Nuke that makes it dead simple to generate camera data from the camera metadata embedded in V-Ray’s EXR-rendered images. After installing the Python script as a menu item, just select a V-Ray EXR render and the script will make a camera node that you can plug into a 3D scene template. It’s amazing:
It even works with animations, meaning you never have to jump back to your 3D app to get new camera data – just kick out a new camera node for the newer EXR frames.
So, here is how you install it. Grab the Python code from the Pastebin site here. Paste it to a new plain text file in your Nuke scripts folder. In OS X and Linux, that’s ~/.nuke/ (where ~/ is your home folder). OS X users can make short work of it by doing this in the terminal after copying the code:
pbpaste > ~/.nuke/createExrCamVray.py
pbpaste is a command line version of a pasteboard paste command in OS X (pbcopy does a copy if you want to pipe to the clipboard). Next, add the call to the script to your Nuke menu bar by adding these lines to the end of Nuke’s menu.py file (For me, it’s located in /Applications/Nuke6.3v4/Nuke6.3v4.app/Contents/MacOS/plugins/menu.py):
m = menubar.addMenu("V-Ray")
m.addCommand("Create Camera from EXR", "createExrCamVray.createExrCamVray()")
The code is wrapping on my blog site, so it’s better to grab it from this text file. Then, once you relaunch Nuke, you’ll be set up.
5 notes | Permalink