I did this test animation to see how well my time-warping scripts worked on the SLS rig I bloged about in the previous post.

So far, I’m rather satisfied. Now onto the actual animation…

By the way, play the animation at full-screen, it’s in 720p! [b]ZOMG! SO MANY PIXELZ![/b]

I’m working on one of my personal projects and wanted to share with you a demo of a car rig I did for the project.

Oh, yeah, by the way, it’s gonna be a very original and one of a kind car spots.

The rig sports a few basic features:

• Automatic wheel rotation system based on traveled distance on individual wheels level
• Manual suspension system
• Manual rotation of the front wheels, incl. automatic steering wheel secondary rotation
• Manual rear wheel spinning system for burn-out animations and sliding
• Secondary system for car sliding at the front and at the rear for drifting types of animation
• Manual body reaction to acceleration

Nothing too fancy, but it’ll get the job done and didn’t take too long to rig. Here’s the preview:

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.

With huge thanks to the Shotgun Software support, I was able to work around the few limitations and start using the latest API without issues inside IronPython. Here’s what you have to do, in order to make this happen:

• First and foremost, download the latest Shotgun API from the github site. Place it some place you’d like to use it from, most likely in the Lib\site-packages folder, though my folder structure is completely different and based on different rules.

Now if you try to instantiate the Shotgun class, you’ll get tons of errors, so, allow me to save you a few minutes (hours in my case, to be honest) searching and working around them.

• The first thing you have to overcome the “IDNA” encoding, which isn’t supported directly in IronPython. This isn’t as clean and easy as it could be, though the workaround is rather trivial, but bear in mind you might break something potentially doing this. I haven’t come across any issues yet, so, I’d consider this modification safe. Find the iri2uri.py module in the httplib2 folder, open it and change line 71 from authority = authority.encode(‘idna’) to authority = authority.encode(‘utf-8′). This effectively changes the codec under which you’ll be dealing with the unicode strings. Again, it’s not a clean modification and you can potentially run into issues doing this, but in my experience, all seems to have been working fine so far.

• The next problem will be SSL authentication, which, again, is tripping IronPython’s SSL module. To fix this, open the shotgun.py module and on line 73 change NO_SSL_VALIDATION = False to NO_SSL_VALIDATION = True.

• Then IronPython will still be complaining about a module called zlib, which is a compiled CPython module that cannot be used inside IronPython. Luckily there is a C# variant based on the same code as zlib. Download it from Jeff Hardy’s bitBucket site and place it somewhere where IronPython can source it (i.e. within your PATH). I put it in a recommended folder called DLLs directly in the IronPython folder. This means that the IPy interpreter will source the DLL automatically, but bear in mind you’ll have to add a reference to this library manually in your scripts when run outside the shell.

• The easiest way is to add these two lines in your imports into the shotgun.py module:

  import clr
  clr.AddReference("IronPython.Zlib")

This way you’ll make sure the zlib module required by some of the shotgun modules is going to be readily available.

That’s it! Let’s test it. Oh, one more thing, I’ve found these Python variant couples to be perfectly compatible and working in production: IronPython 2.6.2 and CPython 2.6 and for clr4 folks IronPython 2.7.1 and Python 2.7.2.

IronPython 2.7.1:

duberPython (utilizing IronPython engine 2.6.2):

I hope this helps you out with your IronPython and Shotgun scripting and I’m certainly looking forward to the new versions of the Shotgun API.

A huge thank you to the Shotgun Software support team!

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.

We’ve launched a brand new website, courtesy of our friends at refresh.cz, with some latest finished projects showcase, including our new demoreel. Head over to duber.cz and leave a comment if you like, hell, even if you don’t like the new site.

Thanks for watching!

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__"

This wouldn’t be such an issue in a Windows environment, however, when you start dealing with path and file names in Python and you start mixing up casing, you can easily get burnt.

So, the only option left in Python would be to use the re module and search or replace strings based on regular expression matching. In MAXScript, however, we don’t natively have a re module and its methods, but luckily for us, we can use .NET, so that the previous method written in MAXScript using regex would look like this:

regex = dotNetClass "System.Text.RegularExpressions.Regex"
regex.Replace srcPath @"^(D[:])" @"\\RAMMSTEIN\__UNMANAGED_PROJECTS__"

This replaces the capital letter D in the source path srcPath with the UNC server path exactly the same way as the substituteString method above. However, since this is a regular expression engine you’re using, you can modify the search in order to match any casing, should that be your choice.

There are two ways of doing that. The ultimate way I chose in the end was to modify the search pattern to @”^([D|d][:])”, which matches both “D:” and “d:” in the source path and then replaces it with the UNC path at the end.

The other option you can use, should you choose to, is the RegexOptions Enumeration argument at the very end of the method call. If you want to ignore casing, just use this:

regex = dotNetClass "System.Text.RegularExpressions.Regex"
regexOpt = dotNetClass "System.Text.RegularExpressions.RegexOptions"
regex.Replace @"d:\testProject\projFolder\something.exr" @"^(D[:])"
@"\\MyServer\__myProjects__" regexOpt.IgnoreCase

Tadaaa! It’s as simple as that. No path splitting, no case testing, just a single line of a regular expression call (not counting the class call) and you’re done. Besides you can use this at a much greater scale with far more complex regex search strings for anything you like directly inside MAXScript.

Note that I’m replacing a D: drive letter in the source paths since that is my projects local drive. You can use whatever you want, hell, you can replace any and all drive letters in one regex call, if you want:

@"^([A-Z|a-z][:])"

I just updated to the final release of Deadline 5.1 after beta testing it for a few months and I couldn’t recommend any other render manager more. If you’re still on Deadline 5 or prior, this update is highly recommended! Especially since it boasts a full CPython support, tight Shotgun integration, draft, the ability to run multiple instances on one render node and much more. For more details, read the official announcement.

Here’s a video demonstrating the power and practical usage of Shotgun (data) brought over to 3ds Max natively via our Python plugin, duberPython.

I’ve been looking for the perfect phone since my good old Nokia 7650 I had in high school. It was a great phone, back then. Had a very comfy portrait keypad and a large screen. Since then I had a few more Nokias until finally switching to HTC phones. My first HTC was TyTN II, what a beast! Then, after the iPhone introduction, some more touch only or touch + type HTC phones. My last one was HD2. I loved and hated the phone equally.

You see, the problem wasn’t the hardware, which is still one of the best even today. The problem was software. TyTN II with Windows Mobile 5 at least had a stylus and wasn’t that much about touch interface (remember, this was a pre-iPhone era). It was cool. Very expensive, but pretty cool. Then Windows Mobile 6 came around with a touch “skin” made by HTC. It was OK, but far, really far, from being smooth, deeply integrated or polished as iPhone’s was.

I ditched Windows Mobile over a year ago in favor of Android (still on my HD2). It was great! I fell in love with Android very, very fast and love it even today. The problem was, again, the smoothness. It just wasn’t at par with the holy grail, in this regard, the iPhone.

Finally I took a blind leap in Windows Phone 7 direction not very long ago. About two months? I bought a HTC 7 Pro, mainly because I was afraid the touch-type experience was going to be mediocre again, so I wanted to be safe with the full hardware qwerty keyboard on board. Man was I surprised! The user interface is as polished and smooth as it gets! I’m loving my phone again. Even typing short e-mails or SMSes on the software qwerty is a joy!

I love the form factor, I love the size, I love the user experience. I am honestly, deeply impressed with Windows Phone 7 and I wish it succeeds in the mobile OS war.

It still doesn’t have the developer base as it should, so, there certainly are fewer apps than for Android or iOS, but it’s getting there and honestly, everything I personally need is there.

As for sideloading, I’ve purchased a ChevronWP7 Pass (for about $9 USD) and officially unlocked my device, so I can sideload any app I wish! The tools for doing so are freely available directly from Microsoft. And once IronPython makes it to the platform, oh man will I be all over the developer side!

Sweet times ahead. So if you haven’t checked Windows Phones out yet, give them a good hard look, they’re awesome!