That’s right! Althought I missed the 100 days anniversary, I am still very happy to see that my server has gone through over 115 days of labor without a single hiccup, error or restart.

So, hopefully, at the very least another 115 days will come by without any issues what so ever.

But it has been pretty busy here. I’ve done countless budget estimates for various projects. Mainly TV commercials. So, hopefully at least some will come to a fruition. Also, been pretty busy getting my material for the EUE 2010 master class. I think it’ll be pretty interesting for those new to this topic of Pipeline, Workflow and Data Management.

In case you haven’t seen the TV commercial we finished in the begining of May, Dr.Max (a local chain of pharmacies here in the Czech Rep.), please, check it out, it’s pretty cool I think and all the artists involved worked very hard, very long hours, to bring this, way above average (locally speaking), TV spot to life.

Also, on the technical field, I’ve invested quite some time and cash to learning new technologies like WPF along with IronPython and a new IDE, Visual Studio 2010, which seems pretty damn promising (not there yet, but getting close with each release)! So, hopefully, I’ll finally find some time to properly design some nice UIs for our Tactic connections from within 3ds Max. Oh, and I managed to get the very latest build of Tactic from the ever-so-awesome guys at Southpaw, so, I’ll be playing with the new toys pretty soon.

Anywyas, I’ll start posting some interesting stuff as soon as I get back from Utrecht next week, so, please, stay tuned!

I’ll be delighted to see you there for a chat and a few drinks…

I’ll elaborate on this topic some more later, but I thought I’d let you know that I’ve successfully deployed, configured and tested Prime Focus’ Deadline®, the render manager of choice for duber studio.

I’ve had a chance to cooperate with James Hindley from FPA Architects on a pretty comprehensive article on Linear Workflow in 3D. Go check it out!

I’m trhilled to be able to finally showcase, at least, some of our very own Python implementation into 3ds Max!

First off, our primary reason for writing our own, proprietary, Python connection to 3ds Max is Tactic by Southpaw Technology. An awesome asset management system entirely written in Python that I decided to invest in and integrate our tools and software packages into. Another reason for this connection, later came up, was the need for writing much more complex scripts with complex GUIs, since, as you probably know, a few functional lines of code are hardly enough in a modern, efficient, VFX production of today.

The heart of our Python integration is dotNET from Microsoft. I can’t express myself enough how much I appretiate this framework! The brain of our Python integration is IronPython. Also a product from Microsoft, completely open source and free, which are two very important aspects for any pipeline tool in any production facility of any size. Not the price as much as the availability of the software. And with IronPython and Microsoft, I am certain that this piece of software will be around for years!

So, what have we done?

• We’ve developed a bridge that connects MAXScript and Python via dotNET.
• The bridge converts most of native Python and MAXScript data types to and from one another.
• We’ve implemented several, custom, methods in Python that allow us to directly communicate with 3ds Max via MAXScript.
• We’ve also implemented error reporting so that when an error is thrown in Python, it’ll return the exception in MAXScript for debuging.
• Everything is based on dotNET and written in C#.
• The best part? Our Python bridge is completely platform and 3ds Max version independent!

Let me talk about the custom Python methods first. We’ve incorporated a class called mxsCon, that stores several methods for direct communication with 3ds Max as well as a variable
that stores passed arguments from MAXScript to Python for greater flexibility, especially when executing short code snippets.

The initial design meant to provide a way of directly running Python code from within MAXScript. However, with more complex tools needed nowdays, this proved to be insufficient and thus we’ve developed a way of executing more complex Python scripts written externally using IronPython. This works perfectly well if you plan on using 3ds Max’s interpreter and just want to pass values around MAXScript and Python. This is perfectly efficitent and enough for writing really complex tools based on Python. In our case, it’s the connection to Tactic.

However, later, it occured to me that since we have most of the hard work done, why not bring everything over to the Python side. Since Python is such a great and powerful language, why bother with MAXScript! So we developed another method for executing MAXScript code directly within Python scripts and have the result, evaluated in MAXScript, be passed back to Python. IronPython that is. Since all the value conversions had already been done, this proved to be an extremely powerful and efficient way of writing very complex tools, now even, with very complex GUIs. Since everything is based on dotNET, we can utilise IronPython and some of the IDEs available for super quick GUI development. I used SharpDevelop, an open source IDE for writing dotNET applications, for all my GUI and code stuff. Then I just hook up MAXScript commands that I pass Python values to in order to perform some actions in 3ds Max, like opening a file from our server stored in Tactic. Or, create objects and list them in a ListView. Or even write a direct 3ds Max – Maya translator! Why not?

Anyways, here are the methods and their purpose in 3ds Max:

• Python.run( <string> ) — will execute a Python script wrapped in double quotes (effectively a string).

Example:

Python.run
(
	"import sys
	mxsCon.setResult( sys.version )"
)

In this case, Python.run() will return whatever the mxsCon.setResult() will pass to it (more on that later).

• Python.runFromFile( <string> ) [ args:#() ] — will execute a Python script stored in an external file and alternatively pass it custom arguments.

Example:

Python.runFromFile @"C:\myPythonScript.py" args:#( 10., true, #(1,2,3), "some string" )

In Python, you’ll have to catch the passed arguments in order to use them, however the conversion of the data types will be done automatically for you.

• Python.inspect( <data type> ) — this method will inspect what data type you passed to it and how it will convert it to Python.
• Python.getError() — this method returns the last unhandled exception in Python code.
• Python.setVerbosity( <int> ) — allows you to set the level of verbosity for error reporting.
• Python.getVerbosity() — retreives the level of verbosity you currently use.
• Python.resetPy() — a very useful method for resetting our bridge residing in memory in case you’ve changed something radical in the source code etc…

And here are the custom methods developed in C# for IronPython use in the scripts. These only exist when run via our Pythoner.dll module. If you run the Python scripts without Pythoner, you’ll have to handle their lack of presence. I’ve done this via a custom class that I import in the scripts I use. This is extremely flexible since when I run the code outside of 3ds Max, I can still use its functionality without having to deal with error handlers all over the place.

• mxsCon.setResult( <data> ) # this method will return whatever it encapsulates directly to 3ds Max as well as in Python should you need to work with it later in the script.

Example:

import math

def myFunc( arg ):
	sum = arg + 100.
	return mxsCon.setResult( [arg, sum] )

if __name__ == '<module>':
	myFunc( math.pi )

The myFunc function will not only return a List of whatever you pass to it as well as the result of addition, but it’ll also pass this List directly to MAXScript for later use in 3ds Max.

• mxsCon.getResult() # this method will only return the last value stored in memory using the .setResult() method. Useful for later usage in Python.
• mxsCon.convert( <data> ) # this method will convert the input data types from Python to MAXScript compatible data types, but will return then wrapped as a string. This
  may be useful for other usage reasons. I used it for debugging or printing values in Python in MAXScript format.
• mxsCon.execute( <data> ) # here’s where the magic happens. This method is quite complex. It not only evaluates whatever is passed to it in a String format, but it’ll also wait for the result from MAXScript and return it within Python. Another, very cool, feature of this method is similar to String formatting capabilities known from Python.

Some examples of the mxsCon.execute() method:

# assume here's a ton of complex Python code that invokes this method
returnedVal = mxsCon.execute( r'Box()' )
# will create a box in 3ds Max and return OK (converted to True) back to Python.

returnedVal = mxsCon.execute( r'getDir {0}', r'#scripts' )

The .execute method will first evaluate its input into a single string,
in this case: r’getDir #scripts’, in a similar fashion the .format method works in Python.
Then it’ll execute the command in MAXScript and retun its output back to Python.
The output, in this case, will be a string: ‘C:\Program Files\Autodesk\3ds Max 2009\scripts’

But, enought with the talk, see it for yourself in action in this short Windows.Forms demo. (clicking the image will take you to the video)

If you still haven’t bought the book yet, DO IT NOW!

Or at least, do it after you’ve read this thorough review of the book.

I can’t resist to quote what the reviewer is saying about my chapter, of which I’m quite proud, obviously.

The advanced unwrapping chapter I found very useful as unwrapping is not my strongest skill in Max. By the way, none of the authors are shy about suggesting outside plugins and stand alone utilities if they think they will do the job better or at least faster than Max. In this Chapter 4 Lukas Dubeda suggested a small separate program for UV layouts that I downloaded to try myself. It does seem to be quite capable at getting the job done. The following sums up this section pretty well:

…

That “…just scratching the surface” seems to be the sentiment of many of the experts in this book. Believe me that they are all making some pretty deep scratches, providing us with an in-depth look at their chapter’s topic.

Anyways, here’s the full review for those still undecided.

Here are my top 10 reasons why FrameCycler is the single best sequence player on the market:

• It is 64bit.
• It supports very flexible 3D LUT files.
• It sports very robust review and edit features.
• It does Stereo pretty damn good and fast.
• It is rock solid and reliable.
• It is extremely fast.
• It supports command line input.
• It plays nice with other production tools.
• It has amazing support.
• It is really cheap.

If you still preview your sequences in an absolutely obsolete and impossible RAM Player in Max, or terribly outdated and rigid FlipBook, do yourself a favour and buy a license today!

I’ve finally received all the parts for my first render slave and immediately got into assembling and installing it. The rig is quite simple, very mainstream and very affordable. A standard ATX board placed in a 1U rack chassis, a Core i7 CPU, 8GB of RAM, two drives, one primary for the system and software and the other for buffering stuff, no DVD drive, no GPU, 350W power supply and that’s it. All running 64bit Windows 7 Professional.

I was kinda curious how this baby would perform once installed in the rack and how it’ll compare to my workstation, which is also a Core i7, 12GB of RAM, tons of HDD space (about 4TB), GeForce GTX285, some BD and DVD drives and other stuff all crammed on a standard ATX main board.

Here’s a quick video of the setup and of the first benchmark, for which I used the latest 64bit FryBench renderer. Quite surprisingly, the render node performed a bit faster than my workstation (might be due to the fresh install, though). It rendered the glass scene in 00h:07m:12s.

Music © Frank Klepacki

My workstation finished the scene in 00h:07m:29s.

I’m quite pleased with not only the speed of the render node, but also how cool it is. The temperature never went above 70°C, which is very, very good! Especially in a crammed rack setup. But obviously, the more nodes in the rack, the more heat they’ll produce and I’ll certainly have to deal with that later, especially during summer.

I’m still amazed how useful DOS can be, even in 2010! And the main reason I thin it’s the most revolutionary OS of all times is that it actually brought the entire PC industry to regular folks’ hands.

Now, by DOS, I’m actually referring to the simplest form of OS environment, IO.sys, MSDOS.sys and COMMAND.com. That’s all you need in order to communicate with your system. That’s all you need to actually get some work done! Isn’t it amazing?

Obviously, Windows and MacOS heavily extended the OS functionality and brought something else in the game. But that’s just evolution. However, DOS on the other hand was truly revolutionary. I may be skipping some other important OS attempts, but DOS was the first OS I ever used as a little kid. I remember when I was about 8 or 9 years old, my grandpa had a, at the time, high-end 286 computer, 512KB of RAM, some 30MB HDD, it was a beast! and it was running DOS. I learnt a few basic commands, such as CD, MD, CLS, COPY etc… just to be able to run Prince of Persia or Wolf3D

A few years later, when I started a high school, one of the computer classes started with a comprehensive DOS course. We learnt all the tricky bits and hidden gems of the OS. We learnt to use batch files effectively, escape sequences, pipes, even a bit of BASIC programming. This was in 2003.

Obviously I don’t have to tell you how much time I spent in DOS trying to configure or repair my Windows 95 or Windows 98 installations.

Then Windows 2000 came along, the first NT OS for the masses, in my opinion, which desperately tried to get rid of DOS for the users. There were several reasons for it. One of them was the NTFS file system. You simply weren’t able to access those NTFS partitions from DOS. Another was security. This is also tied to the NTFS, but security was a big concern. Another reason was the fact that Microsoft, ever since it introduced MS-DOS, tried to get rid of it. They wanted people to use Windows exclusively and not the cheap OS alternative. But even so Microsoft added an RConsole (I believe the name was? I might be mistaking it for the RAdmin in NetWare?).

Funny thing is, even nowdays there are software companies that still write software for DOS. Mainly database systems for large enterprises, like Post Offices, Banks, Account Management companies etc… This really surprises me on one hand, on the other, it makes some sense. You can run DOS on your wristwatch, it doesn’t multitask (well, there are programs that allowed a limited amount of multitasking) which means it can’t run viruses effectively without the user noticing, it’s pretty bulletproof (because it’s extremely simple) etc…

Now, it is 2010 and I still use DOS from time to time. Obviously not that often, but recently with the addition of a dedicated server and a network storage to my studio, I’ve spent a lot of time in DOS configuring the storage controllers, BIOSes and running other little utilities. It’s interesting how important this OS still is. And in my opinion we won’t get rid of it any time soon. It’s so simple, yet powerful, that people still need it for some lower level system configuration. One of the proofs of DOS’s power is the Shell. Sure it existed long before DOS in nix systems, which makes the point even more valid, it’s the simplest way of communicating with the system for the user. I wouldn’t be surprised if I was still using DOS to configure my uber-servers in my, by then, huge VFX facility.