As you might know there has been a significant change in the latest Shotgun API that’s somehow transparent to the CPython users, but presents a rather significant roadblock for IronPython users (including our duberPython bridge, that is based on the IronPython engine).
First, let’s discuss what’s changed in the API so dramatically that it breaks IronPython compatibility. It’s the introduction of a JSON formatting that requires a few specific CPython libraries that are not available in IronPython. The effect it has on CPython users is a faster data transfer to/from Shotgun, but other than that, the API looks to be unchanged from a user point of view. You still keep calling the same methods and you’re getting back the same objects. From IronPython point of view, you’ll hit a roadblock as there are a few modifications you’ll have to make to the Shotgun modules in order to make them run in IPy without issues.
(more…)
As with my previous post, I’m preparing a few handy tools for 3ds Max artists using Mari and Nuke. This bit is the fun part with Nuke: live communication between 3ds Max and Nuke.
Stay tuned!
I’m starting to write a useful set of tools for Mari and 3ds Max users. This is the very beginning – establishing reliable communication from 3ds Max’s MAXScript console directly to Mari. 
I’ll keep you posted.
I don’t think I have to praise regular expressions here, however, I wanted to point out one extremely useful case where regular expressions were pretty much the single most useful, fastest and not so obvious choice in my 3ds Max pipeline.
The thing with 3ds Max is that regular expressions are foreign to MAXScripters and they don’t usually use them. I too am more used to regex in Python or IronPython than MAXScript. However, since we do have access to .NET in MAXScript, we can use its Regex class inside MAXScript.
Why I’m mentioning this and why could it be useful to you? I bumped into a little issue with my pipeline’s handling of rendered files. They assume to be exactly the same as I set them up in 3ds Max, which is logical and correct. However, since I started using Deadline’s SMTD script for submitting my files to the render farm, which takes care of handling the path remapping and storing, it also accidentally took care of letter casing. So, in the end, my render files were being saved all upper cased: “\\SERVER\PROJECT\RENDERS\ABC.EXR” instead of what I set in the Render Dialog: “\\SERVER\Project\Renders\ABC.exr”. The reason was simple, I used simple MAXScript substituteString() method to re-map my local paths to my server, UNC, paths and I converted everything to upper case just in case I got a mismatch:
substituteString (toUpper srcPath) @"D:" @"\\RAMMSTEIN\__UNMANAGED_PROJECTS__"
(more…)
Here’s a video demonstrating the power and practical usage of Shotgun (data) brought over to 3ds Max natively via our Python plugin, duberPython.
Every TD knows that command line tools are among the most powerful in their arsenal of tricks and secrets.
I want to mention RVIO, as today it saved me quite a lot of time (again), which is absolutely key when a deadline is coming.
My client requested a minor tweak of animation (a lip sync, to be concrete) on an almost finished shot. So, the general approach would be to do the change, have the animation data go through the pipeline and at the end have the finished frames ready to be loaded in an existing edit, which then gets rendered out and the final result gets showed to the client.
All fine, until you realize your render farm is completely full with other shots, so you have to skip the “beauty” pass rendering and only present the client with a, somehow, polished preview directly from your 3D package, which isn’t the safest way, trust me. But this client is great and understands that what he sees is actually only a preview of the animation.
So, the last piece of puzzle to solve is to get the preview assembled with additional layers of information (such as frame number, shot name etc…), basically a slightly customized overlay. All this sounds nice and simple, you just open up (in my case) Premiere Pro, swap the layers, render out the portion you need and be done with it.
But this certainly isn’t the TD way. 
(more…)
Just a quick shout about the compatibility of duberPython and the latest and greatest IronPython 2.7.1 release (released a couple of days ago). All working smoothly and quickly, as expected.
Should you need more info on duberPython or what we’re doing with it and Shotgun or Tactic, just drop me a line and I’ll be more than happy to show you how cool duberPython is.
If you’re used to scripting your GUIs in Max with the standard rollouts via “createDialog …”, you might be a little confused and lost when you first try to use a 100% .NET Form object instead.
Whatever your reason might be for using .NET Forms instead of standard dialogs, you’ll still want to:
- Create the main form and define its properties
- Define other UI controls, such as buttons, checkboxes etc…
- Define event handlers for specific control objects
- Initialize and display the entire Form with all the controls and functionality tied in
All this is done a little differently in the .NET realm than what you’re used to in MAXScript. But before you start, check out Paul Neale’s great .NET tutorials on his site. Paul provides some great info for anyone trying to use .NET controls in their scripts.
Now, there is one thing I bumped into, you can actually use .NET objects in MAXScript rollouts, however, you cannot use regular max controls in .NET Forms! So, trying to assign a standard button to a .NET Form will result in an error.
You might think that this creates a burden on the TD to actually skin and customize the .NET controls to look like native 3ds Max GUI elements. You can do this, of course, but it’d really be a lot of additional work to hassle around with color classes, HWNDs etc… you actually don’t need to worry about this as there is an Assembly available in standard Max installations. It’s a little .dll, found in the root of Max, called MaxCustomControls.dll. This Assembly contains some of the more exotic controls, such as SceneExplorer, but it also contains a complete Form control that has already been modified so it reflects your 3ds Max environment, including all the colors, themes and even an initialization method for showing the control as a part of the max process/window.
(more…)
People have asked me how to actually write a plugin for Deadline that will automatically submit a Nuke scene (or any other, for that matter), so I put together a quick tutorial showing you just that.
I’m actually scared by the fact that even 24GB of RAM isn’t enough for a high-end workstation these days. And I’m talking about projects up to a maximum of full HD resolution! I don’t even consider 2K or, hell, 4K projects at the moment as I primarily work on TV commercials etc…
This is very interesting as I remember every time I upgraded the amount of RAM of my workstation, I was very pleased with the performance and the amounts of available memory every time I worked on something. But then, not long after, I started to reach the limits of the system’s resources.
The thing is, when you reach the cap of your CPU, or GPU for that matter, your renders just take a bit longer to finish. But as soon as you reach the RAM limit, your apps start crashing and the entire system becomes unstable! So, it is a bit of a problem.
I started reaching the limits not long ago when I had tons of apps open at the same time. Especially Nuke, Max, VMWare Workstation and Photoshop. But on recent projects I started reaching the cap with Nuke and Photoshop alone! It’s terrifying as it suggests that no matter how much RAM I put in the system, it will never be enough!
So, it seems that my next workstation upgrade will, indeed, be a RAM boost. Not sure I’ll be able to buy the full 96GB of ECC RAM at once, but, I’m certain I’ll get there very soon.
