Thought I’d share my Visual Studio setup for creating and compiling custom DSO’s for Houdini 12. Included are a Solution, 2 project files, documented examples and a houdini file.
Get the package HERE
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:
- H12_PATH : C:\Program Files\Side Effects Software\Houdini %H12_VERSION% where Houdini is installed
- H12_VERSION: 12.1.33 the version you are using
- HOUDINI_DSO_PATH: %CUSTOM_DSO_PATH%;& extends the default dso path
- 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:
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.
Now for the actual header files. Houdini ships with a lot of them and they be found (in all their glory) right here:
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 .
- -I “$(VS2008_PATH)/VC/include”
- -I “C:/Program Files/Microsoft SDKs/Windows/v6.0A/Include”
- -I “$(H12_PATH)/toolkit/include”
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
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!
Some useful external resources:
Pingback: Creating a VEX DSO: Adding Photoshop PSD Support to Houdini | A Pile Of Grains
Check this => http://forums.odforce.net/index.php?/topic/17885-visual-studio-startup-project/page__gopid__108460#entry108460 topic. I mentioned there problem of debugging and how you should approach it if you want to setup Visual Studio project correctly for it.
Thanks, I’ll update the example later to reflect those changes.
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.