# Blog Archive

Viewing page 1 from archive of March 2013

# Anatomy of a Maya Binary Cache

## DAGs all the way down.

On a limited number of occasions I have had need to reach directly into some of the raw files produced by Autodesk's Maya. There isn't much documentation I could find on the web, so I will try to lay out what I have learned here.

The generic structure is based on the IFF format, but with enough small changes to warrant this exploration (with lots of kudos to cgkit's implementation, which helped with some of the gritty details).

Posted . Categories: .

# Resources for Learning Python

## We can do this the hard way, or the easy way...

I am often asked my opinion on how to get starting with programming, and usually with Python in particular. I usually outline three different routes that must be taken: learning how to work with Python, learning best practises for Python, and reading lots of good code from others.

Posted . Categories: .

These @GitHub contribution metrics are potentially quite disruptive to my social life; always have to git my green square for the day....

@mikeboers on . Visit on Twitter.

# A Pool of Shotguns

## A transparent connection pool for the Shotgun API in heavily threaded environments.

I have been working very heavily with Shotgun for the last several months, creating much deeper integrations between it and Western X's pipeline.

One of the things that bit me pretty early on is that the official Python API for Shotgun can not make parallel requests.

Under most conditions this isn't a big problem; the underlying connection would just serialize my threads' access to the Shotgun server, adding some latency, but it wasn't too bad. What was very irritating, however, was that a particular version of Python on OS X 10.6 would occasionally segfault during parallel requests. It took quite a few days of debugging Python in GDB (not a particularly easy prospect, especially since the problem was hard to reproduce) to isolate the problem to a bug in the ssl module's use of zlib to compress the request before sending it to the server.

Posted . Categories: .

This commit marks the end of an era for me -> https://github.com/mikeboers/Nitrogen/blob/master/README.md . Farewell, my dear web framework.

@mikeboers on . Visit on Twitter.

Categories: .

I just did a little work on one of my open-source projects, just so I don't break my streak on @github. Don't know if that is a good thing.

@mikeboers on . Visit on Twitter.

Categories: .

git filter-branch --tree-filter with 3k+ commits and 7k+ files on an overloaded NFS is not a recipe for a good time. #git

@mikeboers on . Visit on Twitter.

Categories: .

If my photos aren't canted then I'm not trying hard enough.

@mikeboers on . Visit on Twitter.

Categories: .

# SIGGRAPH 2012 - Day 5

## Until Next Year

This happened to me last year as well, and similarly with the smaller Vancouver SIGGRAPH events in the past few months, in which I lose perspective in the massive sea of expensive blockbuster film work:

We have gotten to the part of #siggraph where I develop a persistent rage for not being involved in enough awesome things. #neverenoughtime

@mikeboers on . Visit on Twitter.

However, perspectives need to be kept in check. My short, Blind Spot, has been doing rather well lately, getting into yet another festival (I think that is 6 now), and the VFX of that film was the result of only two people working in their spare time.

But for now the plan is to feed off of the helpful part of my rage and do the best job I can do, both at work, and independently. I'll be back next year, hopefully knowing a few more of you and having a slightly larger influence on the industry and presented works.

Posted . Categories: .

# SIGGRAPH 2012 - Day 4

## On Massive Projects

Sessions continued like normal, with me learning too much and inspiring me to try working with way too many of them... like normal. There was a theme that I kept hitting on this week, however, that requires some additional reflection.

My work in this industry thus far has been constrained to (relatively) small projects, mainly on episodic TV or direct to DVD movies. However, many of these sessions (not just the production sessions but also many talks and tech papers) reveal to me that the scope of these projects is at a completely different level than I am used to.

For example, I attended the ILM Battleship presentation on the 4th day in which there were a number of stats thrown around for a particularly heavy shot (the presenter said that he believed it to be the most complicated VFX shot, ever) including that it took 2-5 days per high resolution fluid sim (of which there were many), they cached approximately 20TB of simulation data, and it consumed nearly 23 years of sequential CPU time. Another was during the Disney Paperman presentation on the 5th day in which the director talked about how casually it seems like he was handed a few dozen animators who just happened to have some spare time.

These scales (of both tech and personel) are staggering since the majority of the work I have done in the industry has been limited to what can be accomplished in a few months by a handful of people, but I am very excited (although terrified) to hopefully be a part of these sorts of massive projects in the future.

I also greatly appreciate that the people who are involved in these projects still respect the work that us little guys do, as demonstrated by a number of the Pixar engineers when I discussed my work on The Borgias with them.

Posted . Categories: .
View posts before August 09, 2012