Just Another Right-Wing Rant

Saturday, July 28, 2012

I'm So Annoyed I'm Resurrecting This Blog Just To Moan

I have had it with software development.

Absolutely.

I am going to Tibet.  To farm goats.

Recently I've started a new personal project.  It's pretty cool, if you're into that sort of thing.  Particularly cool is that it's not a lot of code in itself.  It takes a few packages that are out there, ties them together with about 100 lines of clever code and some bespoke data, and it does cool stuff.

Or that's the theory.

So far, it uses these packages:

  • Blender, for modelling things to be displayed.
  • Ogre3D, for displaying the things that are modelled.
  • OpenAL, for playing sounds.
  • OpenNI, for motion capture.
Actually OpenNI is pretty peripheral - all I want to do is capture a sequence of movements using the Kinect sensor from my XBox 360, import it into Blender, attach it to a modelled skeleton and have the skeleton in Blender reproduce my movements in the real world.  Simples, right?

Wrong.  Oh, so very wrong.

There are a few videos on YouTube demoing exactly this sort of thing, so, "How hard can it be?"  I thought.

First, I started to look for solutions that would work out-of-the-box with no coding effort on my part.  NIMate claims to do it, but it's not free - my project is a hobby, to be released as open source, and there is not money in it for me or anyone else.  Besides, all I want to do is capture about 3 seconds of motion - paying for a tool to do this is not an option.

Bloop also seems to do the right thing, and it's free.  The source is available.  So I downloaded it to give it a go.  It's not nearly so simple as installing a Blender plugin and clicking a button.  There are four separate packages you need to have working at the same time:
  • Two Blender plugins.
  • KinectToOsc - takes data from the Kinect SDK and re-broadcasts it as OSC, whatever that is.
  • The Kinect SDK.
So I install the Kinect SDK from Microsoft.  And download KinectToOsc.  And run it.  Nothing happens.  No error message.  No message box.  No window.  Nothing.  No process left running.  Nothing.

So I start digging into the code.  It has lots of references to Microsoft components that don't exist on my system.  "Maybe I haven't installed the right things."  An hour or so if installing and re-installing components later, I'm pretty sure this isn't it.  Another hour or so of Googling later, I discover that I have the Kinect SDK version 1.5 and KinectToOsc was developed against the pre-release version.  Microsoft kindly decided to completely reorganise the API in between and no-one has got around to updating KinectToOsc.  It's just not going to work.  I could learn the Microsoft Kinect API, and the differences between the versions, and essentially rewrite KienctToOsc, but life is too short.

"Well," I think now, "I've written software to get data from a Kinect before.  OpenNI provides a nice interface.  It has a Python wrapper.  Blender has a Python scripting module that can manipulate scene data.  Two things in Python-land, and all I have to do is shuffle data from one to the other.  How hard can it be?"

So I get PyOpenNI from git and build it.  It uses CMake, which I'm not very familiar with, but seems nice enough.  It spits out a library which I can install into Python.  Then I can run the examples and they work.  Great!  I'm nearly there!

But wait.  Python in Blender won't load the PyOpenNI module.  Why?

Well, it turns out that the OpenNI module I built was for Python version 2.7 and Blender uses Python 3.2.  So I install the module into the Python 3.2 modules directory.  It won't load, though, because the Python API has been reorganised between versions 2.7 and 3.  I need to actually build the module against Python 3.2.

Well, PyOpenNI uses CMake, and the CMake configuration includes these lines:
find_package (PythonInterp 2.7 REQUIRED)
find_package (PythonLibs 2.7 REQUIRED)
 Surely if I change that '2.7' to '3' or '3.2' it'll work, right???  I mean, CMake is supposed to make this stuff easy, isn't it?  We can say which package we want, and which version we need, and it just figures it out, right?


Wrong.  CMake only supports Python up to 2.7.  Sure, Python 3 was released nearly four years ago, but no-one has bothered to add support for it to CMake yet.


So, to recap:

  • I want to use my Kinect sensor to capture animation data in Blender.
  • To do this, I need to write some Python code, because Bloop has not been updated to the release version of the Kinect SDK.
  • To do this, I need to use OpenNI and PyOpenNI.
  • But PyOpenNI hasn't been updated to support Python versions less than 4 years old, so I need to modify its build scripts to build against a newer version (I still have no idea if it will work without modifications to the code).
  • To modify the build scripts for PyOpenNI, I also need to modify the CMake package definitions to add support for Python 3.2 to the CMake build system.
Honestly.  If I worked with these technologies all the time, I could probably manage most of this.  But I don't.  Most of the time, I write C++ code using Visual Studio, G++ and GNU Make.  I'm good at that. C++ using G++ and GNU Make are the technologies I've selected for the project because I'm good at them.

Now, because I want three seconds worth of motion capture, I need to:
  • Learn enough about the Kinect SDK for .NET to realise that Bloop isn't going to work any time soon.
  • Learn enough Python to try writing a Blender plugin.
  • Learn the Blender API well enough to start writing a Blender plugin - and, as an aside, the Blender documentation is rotten.  There are enormous stacks of it - so long as you are using Blender 2.4 or 2.5.  The API, to develop a continuing theme, has been reorganised between then and now and the documentation no longer applies.
  • Learn the differences between the C++ and Python interfaces to OpenNI.
  • Learn enough about Python to know what the differences between 3.2 and 2.7 are.
  • Figure out how the PyOpenNI source is structured and where to modify the build scripts.
  • Learn enough about CMake to add Python 3.2 support to it.
I'm sure many in the open source community would say, "This is what's great about open source!  The source is there, so you can modify it and make it work."  Well, I'm sorry if I'm particularly daft, but I've tried, honestly, and my brain has exploded in consequence.  All I wanted was to write some C++ code tying a few modules together and add some captured data tot it.  I don't want to have to figure out how to reprogram an entirely different build system just so I can capture that data.

I don't think I'm being unreasonable here.  I'm working on a project that will change a particular field of endeavour in a pretty radical way and I'm prepared to contribute it back to that community for nothing.  I'm sure I'll end up supporting it for nothing.  That's okay.

Three groups come in for harsh criticism in my view:
  • Microsoft.  You develop a cool new sensor, and an API to let people access it easily.  You generate lots of excitement, and even let people get a preview by releasing a preview version of the SDK.  Of course people will start developing with it - they're excited.  Then, for the release version, because now it's not part of Microsoft Research but part of Microsoft-Something-Else, you have to rename everything and (AFAICT) change how quite a lot of things work.  WHY?
  • Blender.  Don't get me wrong, Blender is cool and it's free.  I just wish they weren't so fond of wholesale change.  Learning to use Blender is painful anyway - the user interface is arcane.  When you know it well, I'm sure it's very productive.  But it follows no established convention in the work of computer applications and so every user has to learn it step by step, from scratch.  As if that's not bad enough, they also make very large changes in every release, leaving their existing documentation and tutorials pretty much useless.  It goes without saying that the documentation for the new version has lots of 'null pages'.  There aren't many tutorials out there for it, either.  They've also decided to re-organise the Python API.  A little more thinking-things-through up front would have saved a lot of people a lot of frustration.
  • CMake.  You do noble things.  You make navigating the maelstrom of library versions easy.  So why has it taken 3 1/2 years for Python 3 support to be not added yet?
Colour me frustrated.

3 Comments:

  • Thank you so very very much for writing this post and explaining what is really going on under the hood. I've been tearing my hair out trying to get all this to work and I don't have nearly your experience. Thanks for saving me hours more of frustration. I guess we now have to wait until something is improved. Sigh. Your criticisms of Microsoft, Blender and CMake are spot on target!

    By Blogger T.H. Culhane, at 03:06  

  • Cheers, @T.H. Culhane - nice to know someone else out there feels my pain. FYI, I have got PyOpenNI to build under Python 3, although only on Linux - see https://github.com/jmendeth/PyOpenNI/issues/27.

    By Blogger Tom, at 03:29  

  • I'd also just like to say thank-you. I was also wondering what I was doing wrong with Bloop, and have almost no idea when it comes to actual code. At least now I know to give up!
    Cheers

    By Anonymous Bradley, at 17:34  

Post a Comment

<< Home