The reason I use Visual Studio is because of it’s great debugger and clear way of structuring (and maintaining) code. Unfortunately there isn’t much help on how to set VS up in order to use it with the Houdini development kit. This guide should have you up and running in no time. After completion you should be able to compile and load the compiled dso’s in Houdini and inspect them using the debugger.

Quick note on the HDK: The HDK is a comprehensive set of C++ libraries. These are the same libraries that the Side Effects programmers use to develop the Houdini family of products. With the HDK, you can create plugins that define nodes, commands etc. I often use the HDK to optimize earlier prototypes written Python and sometimes Vex. But this isn’t always necessary. Only when speed becomes an issue I rewrite some older operators to gain some responsiveness.

First things first. Houdini 12 is compiled for windows using MSVC9, shipped with Visual Studio 2008. For that reason it’s only possible to compile Houdini plugins with that specific Visual Studio compiler. So try to get your hands on a complete Visual Studio 2008 installation. I believe the express edition won’t work because you can’t link to dll’s, but never tried. When running a 64 bit version of Houdini, make sure to install the x64 compiler as well. This option is turned off by default. For this tutorial I will focus on the x64 version of Houdini.

After installation the compiler can be found here: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64
If you haven’t included the x64 compiler during installation this directory is missing…

You should have a Houdini 12 version installed (duh ;)). This particular setup is tested with Houdini 12.1.33×64 and 12.1.92×64. Both versions worked fine. It’s important to remember that rather significant code changes can happen between Houdini releases, even daily builds. Therefore your code might stop working or won’t compile when switching to a different version. I try to stick with a specific release for as long as possible (most often Production builds), and only switch when necessary (new major release, a bug fix etc.)

Now Houdini and Visual studio are installed, it’s time to set up the Windows environment. We’ll do two things here:

Set up some environment variables that will be referenced in the visual studio solution and projects

Specify a new DSO path where the plugins will be stored

Open up the environment variables dialog in windows and add the following variables:

CUSTOM_DSO_PATH: G:\WorkCoen\HoudiniDSO where the custom dsos are stored (customize to your liking)

For the second step we want to create a Solution that contains a project that can be compiled in x64. In the package provided you will find a solution that can be opened in Visual Studio 2008. This solution contains 2 projects that define 2 different types of operators: the well know SOP Star and my own UV Interpolator. After setting up the projects we can build them and debug the operators using VS.

First we want to check that each project is linked against the correct Houdini library. Open the project properties and browse to Linker > General > Additional Library Directories. This value for this field should state:

$(H12_PATH)\custom\houdini\dsolib

The Output File parameter controls where the dll will be stored. This directory needs to be included in the HOUDINI_DSO_PATH.
For that reason I pointed it to the CUSTOM_DSO_PATH variable.

$(CUSTOM_DSO_PATH)\$(ProjectName)_$(ConfigurationName).dll

Now for the actual header files. Houdini ships with a lot of them and they be found (in all their glory) right here:

$(H12_PATH)\toolkit\include

Make sure the Additional Include Directories parameter points to that directory

The command line arguments are important. They define how the operator is build by the compiler. Houdini uses a lot of arguments and I don’t know them by heart. What I do know is that the -O argument is an optimzation preventing me to debug my code. When you want to dive in and look for the source of a problem there are two important arguments to set / remove:

Remove -Ox (disables optimalization)

Add -d (enables debugging)

I currently use the following arguments:

-TP

-Zc:forScope

-DVERSION=”$(H12_VERSION)”

-DI386

-DWIN32

-DSWAP_BITFIELDS

-D_WIN32_WINNT=0×0501

-DWINVER=0×0501

-I .

-I “$(VS2008_PATH)/VC/include”

-I “C:/Program Files/Microsoft SDKs/Windows/v6.0A/Include”

-I “$(H12_PATH)/toolkit/include”

-MD

-EHsc

-GR

-DSESI_LITTLE_ENDIAN

-DNEED_SPECIALIZATION_STORAGE

-DAMD64

-DSIZEOF_VOID_P=8

-DMAKING_DSO

If we want to launch Houdini from within Visual Studio to debug the dso’s, it’s important to set up the Debugging properties. The Command property should point to the Houdini version you’d like to launch. In this case that’s:

$(H12_PATH)\bin\hmaster.exe (houdini master)

To ensure the dso is loaded when Houdini is launched, the CUSTOM_DSO_PATH variable is added to the HOUDINI_DSO_PATH variable, specified in the Environment property

HOUDINI_DSO_PATH=$(CUSTOM_DSO_PATH);&

With all of the above in place you should be able to build the projects and start Houdini by pressing F5 (launching the current active project). Everything should be loaded and an empty session should appear. From here on try to create the node (Star or UV Interpolator) and put down a break point somewhere in the source code. When the node is cooked the break point should be hit (if it’s in the right place). Happy debugging!

Immediately compilable projects plus the fact that with very few issues it was possible to create my project from scratch may definitely prove this description’s validity. Thanks a bunch for explaining for I certainly would like to optimize some python SOPs.