You can find it on my Houdini page or you can get the asset directly from here.

For those interested, here are the attributes you need to get sprites on points:

1. spriterot: class: point, type: float, size: 1
2. spritescale: class: point, type: float, size: 2
3. spriteuv: class: point, type: float, size: 4 (spriteuv[0] = U-offset; spriteuv[1] = V-offset; spriteuv[2] = U-scale; spriteuv[3] = V-scale)
4. spriteshop: class: point, type: string

Note: Video re-done on 5/25/2009. I thought it could be cleaner and more focused on production nuances so I re-recorded it.

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.)

Now I won’t be proclaiming that everyone should abandon Windows in favor of Linux as I have always stated that as long as the machine is doing what you want you should continue to use it happily. But I will say that it is enjoyable and much more easy to use than I remember from past iterations. If you ever do switch here’s some things to keep in mind (which is valid as I write this, who knows what will happen down the road):

1. Fedora 10 32-bit live cd doesn’t have the samba client pre-installed (easy to add though).
2. Lots of applications that support Linux seem to be available only in 32-bit (Google Gears) but there seems to be a slow push towards adding 64-bit support for some apps (e.g. Flash support for Linux 64-bit just went alpha).

Of course I installed Houdini and for the sake of saving others some searching, here are some things that I did in Feora 10 that got it installed:

1. Get the video card driver for your machine. Sure there is the default driver loaded on your machine but for me at least I needed to the full monty.  For Fedora, I used the ATI rpm as per the instructions here (NVIDIA instructions found here). For the ATI portion be advised that after using the init 3 command you’ll leave the GUI, so be sure to have the rest of the commands written down somewhere.
2. Install Houdini by unpaking the gcc 4.1 build of Houdini and in a terminal going to the Houdini install folder and typing ./houdini_install as root, then follow the instructions. I didn’t seem to need to do add the “source houdini_setup” line anywhere for Houdini to run.
3. If you’re running SELinux, set the default to permissive and when you run Houdini for the first time, quite any SELinux warnings (so you don’t see them pop up again everytime you open Houdini.

P.S. I fixed Windows on the laptop by running chkdsk, but decided to install Linux anyway.

P.S.S. My main desktop machine is still running 64-bit Vista.

First thing that I came across was that when I booted from the DVD I got a black screen. After trying it after a cold boot I finally got it working and got Windows installed. I played around with it for a while and it did run smooth but have have no illusions about that since all clean installs run smooth for a little while and Windows 7 comes very light (if you want them, you need to download a lot separate applications like Windows Live which has Messenger, Mail, Photo Gallery, Movie Maker beta, Writer, Family Safety and others). During the whole time I played with it it struck how much like Vista it was. No real big changes other than what I see as a natural progression of the software. A lot of people are hyping it as a huge change from Vista, but I’m not seeing it. That’s likely due to so much bad press about Vista convincing people it was terrible, so that logically, anything newer must be better. For the record, I like Vista – it does want I want without any issues and I never ran into any issues after I turned off UAC.

I did run into a few issues like the OpenOffice installer failing (conspiracy theorists cry foul here), and a weird error in the Houdini viewport that is persistent (below captured with Windows 7 snipping tool).

This shows up in the Houdini viewport with Windows 7 and a Radeon x700 Pro (and didn't when in Vista was on this same machine).

But I’m not sure I can say that’s a Windows issue since it could be a graphics card OpenGL issue (the ATI drivers I used were beta as well). It’s really hard to judge Windows 7 since it’s a beta – so any issues I do come across (I already submitted an issue to MS) will likely be fixed down the road. I do see Microsoft’s gearing more towards a network centric ideal with their home network feature which is also hooked into the firewall permissions, which is a natural progression in today’s world. I also liked the choices you can make to determine your default search engine, e-mail app, etc.

I put a help section in the asset, though as it’s not working right now, I’ll say that there is an added output called occlusion which is basically 1-coverage. Using this removes the need for the later subtraction step I note in the video. If you would like to see the help you can right click on the VOP, go to Type Properties, then go to the Help tab.

You can find the asset here (also linked to on the tutorial page).

1. v1: Initial Release

One issue that arose though is that the help file and built-in Houdini icons don’t work as described in the Custom VOPs tutorial, so though the help file is written in the asset it doesn’t work right and there are no icons (at least the one I wanted to use).  Another issue is that Houdini (at least in 9.5) has the limitation that you can’t get illuminance loop derived image planes from area lights.

You can find the asset here (also linked to on the tutorial page).

1. v1: Initial Release
2. v2: Adding a parameter to rough now works.  The fix causes the rough not to be hidden when diffuse is used, but it doesn’t case any harm keeping it unhidden.
3. v3: Added string input parameter so you could select the BRDF type after promoting the inputs.

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.