I’m beginning to wonder if I’ve fallen into the social networking trap. Am I one step away from telling the world on Facebook what I’m doing any given day? Am I on the verge of commenting on photos of people I haven’t thought of in decades? Social networking in any form is a slippery slope to playing Farmville all day. So in order to bolster my commitment to my own site I think I’ll start posting in both places, the WotC site for the social user’s benefit, and on geneome.com for my own.

The Encounters concept is a good one and conducive to how I like to play: very structured story, short game once a week, game is on rain or shine, and an ample supply of people wanting to play. Of course, the main reason I liked it was because it was set in Dark Sun, so I’m uncertain if I will continue after the 15 week season unless there are more Dark Sun adventures available. The way Encounters is set up allows for people to be able to miss games and not be out of the loop, which is good because it’s hard to imagine being available for all 15 sessions. I also got a DCI number (formerly the RPGA number) so I can feel extra cool/foolish. I say foolish because it is a strange concept to me that playing an rpg needs an organizational structure that warrants numeric identification.

I started playing D&D again specifically because of Dark Sun being announced as a 4E campaign setting. It is my hope that these Dark Sun Encounter sessions will be an nice bridge until the main campaign setting comes, allowing players to get into the setting and bettering the chances of a regular Dark Sun group being established.

With this method I was able to collect every Dark Sun game product produced for 2E even including the books that had small references to Dark Sun (Ravenloft’s Domains of Dread and the Book of Artifacts). I even got the extended and revised Dark Sun books. Not because they were good in anyway, but I wanted to complete collection just in case I had need for them as a reference in the future. Additionally, along with all the Dark Sun novels published during the 2E days, during my last gaming material clean-up I took out all the Dark Sun related articles from the old print Dragon magazines I had (I took a picture of them for all to see!).

Dark Sun 2E articles from the in-print Dragon Magazine.

I still get a nice feeling that I have them since they are hard to come buy and hold fond reminders of the Dark Sun setting.  However, with 4E Dark Sun coming, my possession of these books takes on new meaning. Since new material for the 4E setting won’t be readily available, if I need a map of Tyr, Ur Draxa, some interesting weapons, monsters or adventures, I’ll certainly have a good source of references.

The hip file I’m using is actually based on a workshop that used to be online (but doesn’t appear to be anymore). I used it because it had the exact components to demonstrate everything.

Also, I’m sure my friend Jason will say that he is in no way regal when it comes to compositing, but seeing what he’s been up to lately certainly indicates that he knows what he’s doing .

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!

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