Yes, that is true. Stuff that should be inherently and implicitly iterable, is not, when accessed from MAXScript.
I had to find out the hard way, so here I am sharing my findings and solutions so that you don’t have to waste time on this nonsense issue.
The problem I bumped into some time ago was when I tried to access Management Object Searchers in my code (for finding various HW IDs and serial numbers). When you call a dotNET iterable (or a collection) in MAXScript, you automatically assume you can iterate over its contents, just like with an array, for example.
WRONG!
Somebody at Autodesk decided that this isn’t the behavior you’d like and instead made you having to jump through hoops and obstacles to get to the object contents.
Anyways, lets look at this problem on a rather simple example of using Hashtables in MAXScript:
(more…)
Do you remember my post about repathing 3ds Max assets in the .max and .mat files without actually running 3ds Max? Well, I cooked up a little utility that can be run from the command line without any IronPython installed. You can use this simple exe file to repath or simply just list all your external asset paths inside your .max and .mat files, should you need to. And since it’s a command line utility you can run it from within your programs and catch the outputs or batch feed it data for processing etc…
Anyways, the syntax is pretty simple:
You need to call the program and then pass it a .max or .mat scene file. If you provide only that, it’ll list the file’s asset paths. But if you provide a -p parameter followed by a new path, it’ll re-path all the file’s external assets to the new location you provided. Unfortunately, there is no way for me (afaik) to distinguish what is an actual render output or RE output and what are texture or cache data inputs, so everything will be linked to the new directory at once.
Should you need any help, just call the program without any parameters, or with the parameter -h for help.
Download the program from here.
Another one of those little things that can save up a ton of time in day to day productions.
I’ve added a simple “render with 3ds Max” shortcut to my right-click menu, so that I don’t have to open up Max if I need to render a scene. This actually came in handy on the current project where I was modifying a few scenes and re-saving them. Then I went through a few of them manually and needed to render them out quickly for reference. No need to actually run Max, open the scene, hit F9… it was all setup, I just needed to render them out.
If you want to modify your right-click menu this same way, just modify this registry key (3ds Max 2013 in this case):
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\3dsmax\Shell\Render]
@="Render with 3ds Max 2013"
[HKEY_CLASSES_ROOT\3dsmax\Shell\Render\Command]
@="\"C:\\Program Files\\Autodesk\\3ds Max 2013\\3dsmaxcmd.exe\" \"%1\""
Done. 
As you may know, Nuke 7 is out and one of its very exciting features are the new re-lighting tools.
However, I’ve bumped into a bit of a problem. Since I’m primarily a 3ds Max user, all my world render passes are Z-up oriented. This is a bit of an issue, since Nuke is, more commonly, Y-up oriented.
Fret not! There is a rather simple solution. The ColorMatrix node, nobody seems to care about. All you need to know, if you’re not much into math and shit, is that in order to properly convert the RGB values representing the XYZ space coordinates in Max into Nuke’s world space, just type in these values:
- In the first row, type in: 1,0,0
- In the second row, type in: 0,0,1
- In the third row, type in: 0,-1,0
Or just look at the picture above.
Done! This is all you need in order to start re-lighting your renders in Nuke using 3ds Max’s World Point passes.
Just a shout out to those who downloaded my RV Explorer integration Python script.
I’ve updated it so that RV now accepts file sequences with various leading zero lengths as I bumped into this issue myself recently.
Hope I haven’t caused you too much trouble.
Here’s the updated script: v0.3
Ever since I read this blog post on the Area, I was intrigued to get this working in an IronPython environment (that’s pretty much all I know, in the “serious programming” area). Unfortunately for me, the article mentions C++, OLE and COM. Which are my least favourite technical subjects.
So, now when I finally really needed this solution (more on that some time later), I had to ask on the Autodesk forums.
Luckily I got an answer. But first off, huge thank you goes to Larry Minton, an Autodesk Engineer, without whom I wouldn’t have been able to get this thing going.
Now, about the problem. If your facility has a render farm and you happen to work off of your local storage, you have to point your assets to a UNC path where they’re stored so that all the machines on the network can find and load them when rendering. There are many ways of doing this and usually your pipeline TDs had figured this one out prior you even starting any work on the project. Unfortunately for me, I’m the only pipeline TD here. 
So I had to figure out a way of re-pathing my assets in 3ds Max scene files prior to rendering.
(more…)
This post is basically just a note to myself, because I keep searching for this every now and then and every time I forget the syntax. So, here’s what you need to do in order to extract .msi archives to a specific folder of your choice.
To extract files from a .msi file from the command line, type:
msiexec /a PathToMSIFile /qb TARGETDIR=DirectoryToExtractTo
For example, to extract files from X:\installs\someProgram.msi into C:\someProgram you would type:
msiexec /a X:\installs\someProgram.msi /qb TARGETDIR=C:\someProgram
In February, I wrote about calling the JSON variant of the Shotgun API from the IronPython 2.7.1. Now it is time to upgrade the pipeline tools to the latest versions of both IronPython and the Shotgun API.
There are, however, some steps you have to take in order to make things work without issues.
Naturally, you still have to follow the steps described in the february article. In addition to that, however, you also have to modify the Shotgun.py some more. On lines 52, 53 and 54, remove the relative module paths. So, basically just remove the dots from the “.lib“. For some reason, IronPython is having issues with relative imports outside of packages.
After that, everything should be running smoothly again.
Here are a few screenshots from the IronPython console as well as from the MAXScript Listener in 3ds Max 2013.
IronPython 2.7.3:
duberPython (utilizing IronPython engine 2.7.3):
Yesterday, I posted about RV integration in Windows Explorer. Today, I have the script and a tutorial on how to hook this up ready for your pleasures.
Just download the script, place it somewhere safe and follow the tutorial on how to create an RV specific right-click menu entry in Windows Explorer.
Enjoy!
Basically, I’m tired of this workflow: fire up RV, invoke the open file dialog, navigate to the folder where my image sequence is and finally double-click the sequence I want to review.
I want to streamline this workflow as much as possible. So, my idea is to add a right-click menu entry for the most frequent file types I review daily, i.e. jpgs, exrs, tiffs, etc. When right-clicking on any of the files in a sequence a script will figure out the sequence numbering and will pass the wild-carded file name to RV via RVPUSH.
When I’m done, I’ll post the scripts and how-to here, so stay tuned. 
