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:

hsh = dotNetObject "System.Collections.Hashtable"

This will create a dotNET object, Hashtable, in MAXScript, so you can start adding Key:Value pairs to it. Which is the closest thing to Python’s Dictionary objects I’ve found. Very helpful.

Let’s add some data to the Hashtable for our demonstration purposes:

hsh.Add 1 "test"
hsh.Add "foo" "bar"

Now this data type is rather simple, it stores Key:Value pairs, so you can later call them similarly to calling array items: hsh.Item[KEY] and it will return the VALUE associated with the KEY.

hsh.Item[1]
"test"

hsh.Item["foo"]
"bar"

Brilliant!

But, what if you don’t know all the Keys, or you want to dump all the Values and the Keys into an array, or do something else with the data. Naturally, the first thing I wrote was:

for o in hsh do print o.Key

Well, the friendly message you receive is as follows:

-- No "map" function for dotNetObject:System.Collections.Hashtable

Which is essentially saying FUCK YOU! You cannot iterate over a collection!

But why? Why couldn’t I iterate over an obvious collection/iterable? I have no fucking idea!

So then the real question was, how the hell do I get the data out of the object if I don’t know the KEYs? How do I even get all the KEYs of the Hashtable?

The, not so obvious, answer was Enumeration. Simply put, you need to get an Enumerator object of the Collection and iterate on that in order to retreive the data in MAXScript. It’s cumbersome, nonintuitive and unnecessary, but that’s the only way I’ve found that works reliably.

In order to do just that, call the .GetEnumerator() method on the iterable object and store it in a variable. Then use that variable to “walk” through the Enumerator and get its data, like this:

hshEnum = hsh.GetEnumerator()
while hshEnum.MoveNext() do print hshEnum.Key

After running this code, you’ll get:

1
"foo"

Which you can then use later in your code to retreive the Value associated with these Keys.

Dumb, isn’t it? I spent hours looking on forums, searching Google and asking around to figure this out. It took me this long since in IronPython I can, naturally, iterate over collections and iterables without jumping through Enumeration hoops. Here’s the same program, except written in in IronPython:

from System.Collections import Hashtable as hsh
hsh = hsh()
hsh.Add(1, "test")
hsh.Add("foo", "bar")
for o in hsh: print o.Key

DONE! How smooth, simple, easy and intuitive is that?!

I just realized that after seeing what Autodesk has been doing to the (at the very least) DCC software packages for a long time now.

They just can’t write good software. Nothing breath taking, let alone revolutionary. Just look at it. All they sell is software they bought from really smart and bold developers in the past. Then they pretty much kept it the same way it had been, including all the bugs, quirks and issues, but slapping on fancier and fancier GUIs they also bought or licensed from someone else (Qt anyone?). They don’t have the balls, even though they pretty much have a monopoly on the DCC field. Pussies.

Seriously, when was the last time you were excited a new version of anything from Autodesk is coming out soon? I haven’t. Hell, I haven’t been even excited about their betas in a long while. Autodesk doesn’t listen to the users, they don’t care much about the old time power users either. They just don’t give a shit, in my opinion.

So, with all seriousness, I’m truly considering cancelling my subscription and just don’t give a shit back.

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.

There would be no fun without VFX!

I was shocked and very pleased to hear that Shotgun Software decided to unify their pricing and bring it down to $49 USD per month per user with the API! How awesome is that?!

That brings me to a thought of actually releasing our duberPython plugin for a ridiculously low price so that EVERYONE can use Shotgun and our Python module in their pipeline!

Let me know what you think, guys and I’ll prep the installations in the meantime.

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.

I promise I’ll write about some really fucking exciting shit (oh yeah: Max, Mari, Nuke…) pretty soon, but I’ll have to deliver two more TVCs this and early next month. So, possibly right after that.

Stay tuned, you won’t be dissappointed, I promise. Cheers…

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.

Up until now I’ve been dealing with this via MAXScript and Deadline. I wrote a handy dandy PostLoad script that gets executed right after a Max scene file gets loaded up, then the renderer fires off and renders correctly. This has worked flawlessly for me and probably will work forever. However, you always have to supply this script along every submitted file. So, this gets a little more problematic with more complex PostLoad scripts that you also need to run occassionally for specific jobs/shots.

Then, not very long ago, I bumped into these two commands in MAXScript:

getMAXFileAssetMetadata <filename>

and

setMAXFileAssetMetadata <filename> <array of AssetMetadata_StructDef instances>

These commands will allow you to source a special stream of data off of a given .max file and will allow you to overwrite it with whatever you supply the methods with. This is a perfect solution for a situation where you have to batch modify a ton of .max files in order to prepare them for the network rendering. Unfortunately, though, you have to have 3ds Max running in order to perform MAXScript operations. This is a bit prohibiting on a server side, where you usually don’t have a 3ds Max license available or you don’t want to use up a single seat of floating licenses.

Then there is the OLE stream. It has been possible, since 3ds Max 2010, to get such data out of the .max files without running 3ds Max and thus without needing a single license of Max to perform such pipeline tasks. It isn’t as trivial as the MAXScript approach, though, but definitely doable.

The problem with .NET languages, though, is that this was designed more for C++, than C# or even IronPython, or Python for that matter. But, luckily, there is a library, OpenMCDF, that allows you to manipulate OLE data streams in files. It is very simple to use the OpenMCDF objects and methods and works perfectly fine under IronPython (which is my case of using it). And so, the last piece of puzzle was to figure out how to access the meta data asset stream and, mainly, how to modify it – effectively re-pathing the assets outside of 3ds Max.

First of all, download and unpack the OpenMCDF assembly into the IronPython\DLLs folder.

Now, in IronPython, in order to get to the data stream, you have to Compound the .max file using the OpenMcdf.CompoundFile() method. If you want to modify it, supply a UpdateMode parameter and a couple of boolean variables denoting whether you want to recycle sectors and or erase free sectors.

from OpenMcdf import *
cFile = CompoundFile(r"pathToMaxFile.max")

You then have to access the RootStorage and its streams. This gets a little tricky. I had to look this up in the C++ SDK (kindly provided by Larry). The stream name you’re looking for is called FileAssetMetaData2, so with this in mind:

theStream = cFile.RootStorage.GetStream("FileAssetMetaData2")
buffer = theStream.GetData()

Now here it becomes a little cumbersome for high-level programmers like myself. Essentially, what we get is an array object full of Byte objects carrying data, like so:

Array[Byte]((<System.Byte object at 0x00000000000023BF [92]>,
<System.Byte object at 0x00000000000023C0 [108]>,
<System.Byte object at 0x00000000000023C1 [59]>))

Let’s take a look at the MAXScript output, to put things into perspective. If you run this command:

getMAXFileAssetMetadata @"pathToMaxFile.max"

you get something like this:

#((AssetMetadata_StructDef assetId:"{923B6C5C-1ACC-48D7-A879-FF472DC61589}"
filename:"D:\_SOME_PATH_\TEST\BEAUTY.exr" type:#bitmap))

It’s an array of AssetMetadata_StructDef objects. More importantly, the data it contains is: asset ID, what type of an asset it is and the file path, which is what we’re interested in modifying. The ID and type is not to be played with! You can get pretty nasty Max crashes if you do something wrong with these. Believe me.

Now that we know what data we’re looking for, we need to make some order out of the Byte array we received from the stream. To make things even more complicated, the Byte array contains not only the data we want, but also some descriptors (not really the best name, but at least that’s what I think of them). The descriptors tell you how long the next Byte stream is in order to retreive correct data. Here’s how the data is structured in the stream in order to make something out of it (again, huge thanks go to Larry for this):

• 16 Bytes – the AssetID (don’t modify this!)
• 4 Bytes – the length of the next Byte stream that contains the Asset Type name
• (len+1)*2 Bytes – the amount of Bytes you need to read in order to retreive the Asset Type name (UTF-16)
• 4 Bytes – the length of the next Byte stream that contains the Asset file path string
• (len+1)*2 Bytes – the amount of Bytes you need to read in order to retreive the Asset file path string (UTF-16)

So, that’s basically it. This recipe loops for as long as there are available Bytes in the stream. This, of course, means that if you want to change the file path string, you will have to update the preceding 4 Bytes denoting the file path string’s length, which is a pain in the ass, if you ask me.

I’ve figured out a pretty dirty workaround, which I’m presenting here. I’ll present a way of reading the file paths, so that you can use them in your asset management or production management software, for example.

The process is as follows:

1. Get the buffer Byte Array object
2. Decode it using the UTF-16 table into a unicode string
3. Split the string by using a special “\x00″ delimiter character
4. The resulting list object stores all the data you need in a human-readable form (well, that applies only to the file path string and the asset type string)
5. Filter out only every fourth item in the list, which is the asset file path

Unfortunately, there is no way (none that I know of) to tell what is the asset file path associated with. All you know is whether it is a Bitmap, or a Cache etc… but there is no way to tell whether it is a render element save file path, or an actual texture path etc.

But still, for repathing purposes, it’s all you need! Here’s the IronPython code showing the above process in action:

from System.Text import Encoding
assetFilePaths = (Encoding.Unicode.GetString(buffer)).split("\x00")[3::4]

That’s it! The resulting list contains all the Asset file path strings that are contained in the .max file you sourced. With a bit of imagination and some more programming, you can start re-pathing the file paths using these methods. Also make sure to read the OpenMCDF documentation for all the available methods and object properties.

I’ll post my scripts here as soon as they’re polished and thoroughly tested. However, I’m very thrilled to finally have a way of modifying asset paths in my .max files without having to run Max first, it’s such a time saver and it’s very helpful in a modern pipeline.