1. The operators at the geometry level (the Python operator and Script SOP) are unable to poll the data. This seems to be due to cooking issues as well as the geometry operators using the hou module only to create/manipulate data.
2. The operator at the object level (the Python operator) does poll the data, however it seems that this polling becomes the dominant process in Houdini and you can do nothing else or stop the polling.

So the conlcusion that can be drawn is that the Python COM method for polling data is not a viable one. The idea of having Houdini write the values of the device to certain parameters and see the results in real-time just doesn’t seem to work. It is certainly possible I am overlooking something however I’ve spent a lot of time on this and with a working and better alternative out there now there isn’t a pressing need to continue. This project has helped me learn a lot about Python in Houdini as well as the common object model so the effort wasn’t entirely without gain. Now it’s time to move on and continue to learn more about Houdini!

Yes – I have something working! Read on for the story and where I’m at:

I’ve noticed a problem with a lot of animated shorts and student work: The camera work is atrocious. It seems like all the time is spent on perfecting the modeling, animation, and shading, then in the last 10 minutes of production someone puts in a camera and animates it going to the left. Seeing this as a major issue I thought that there must be a better way to have the camera animated easily and a whole lot better. I then recalled I had a 3DConnexion SpaceNavigator that I never use because no applications I use support it. The whole line of 3DConnexion devices might be just what animators need to have better control of their camera.

The SpaceNavigator seems ideally suited to be able to control not just a camera but any object in 3 dimensions, provided that the application can see and understand the device. Unfortunately, Houdini is not one of them. So I researched it a bit and found some hope in an obscure post on the 3DConnexion forum. Someone had been able to use Python to poll data from a device using a Python module called comtypes, a COM client framework (the Windows SDK for the device is a COM dll).  I tried it in Python 2.5.4 and it worked!  At the time it seemed like a simple thing to add the script in Houdini and replace the trans and rotate prints to “hou.node(‘/obj/cam1′).parm(‘my param’).set(my devices param)” and get the camera to receive data from the device.  Long story short – it didn’t work.  Firstly, Houdini doesn’t have _ctypes.pyd which is required by the ctypes module (so I added it to Houdini x.x.x\python\lib\ which worked).  Secondly, though it seemed that the device driver was being seen, an error kept posting.

So more research was needed. I thought maybe using the old comtypes (v 0.2.1) with the script from the 3DConnection post was the issue, so I upgraded to comtypes 0.6.0. But if you read the post, only 0.2.1 works with the script. More research… then after getting the script to work with 0.6.0, I still got the same error.

So off to odforce I went (to cry for help) which got me thinking more but all of those avenues were dead ends.  Then – you guessed it – more research.  Which lead me to figure out what was wrong. My comtypes module in Houdini wasn’t compiled! I had no .pyc or .pyo files anywhere! And that was it, after I compiled everything using the Python compileall module in Houdini itself it all worked out. Now I can get Houdini’s command window to print the data from the device just fine. The next step is to see if it’s feasible to get this data into Houdini beyond printing to a window, but that is for another day (and another post) mainly because some quick tests cause Houdini to freeze up when I try to use the data to send to a parameter.

Here’s a quick look:

Houdini Using A 3DConnexion Device Via Python from Geneome on Vimeo.

There are some 32/64-bit issues. The _ctypes.pyd that comes with Python only seems to be compiled for 32-bit machines.  So unless I compile my own 64-bit _cytpes.pyd, this only works with a 32-bit Houdini. You can use a 64 bit _ctypes, which works with Houdini 10 64 bit but you need to use a different ctypes module version (1.0.2). As we are using a COM dll to poll data, this is a Windows only method. I need to look at the 3DConnexion SDK for Linux to see if Linux is in the cards through this or some other method.

(See the follow-up here.)

1. An application can use Python 2.6 for a long time to come, not doing themselves any favors by staying with an ever older (and eventually unsupported) version.
2. An application can support both until 2.6 fades away.
3. Each application or a third party can branch off to make a supported Python 2.6-compatible version and everyone will start using that instead.
4. People will realize that they rather stay with 2.6 and 3.0 will die off.
5. An application can jump onto the Python 3.0 bandwagon, kill lots of scripts, but everyone will be better in the long run since we’ll have a better Python to use (plus, scripts can be fixed).

I’m for number 5.