Houdini-Blender Clipboard

Intro

Houdini-Blender Clipboard is a set of simple scripts which I initially wrote for myself to make it easier for me to move geometry between the two programs. I’m a GNU/Linux creature, so jumping between many programs that do one thing, but do it well is no alien to me. Of course, Houdini and Blender are huge programs that can do many things, and many things they do very well, so you may say that it’s not an appropriate comparison. It’s true, but there are some different aspects of computer graphics that those programs specialize in. It’s easy to do procedural stuff in Houdini, but modeling in a traditional way is much easier in Blender, for example.

That said, while modeling an asset, if there’s a specific part of the process which I know I can do faster and easier in other application, I’ll do it without hesitation. Then I’ll move the modified geometry back to where it was exported from.

The standard way of passing geometry from Houdini to Blender, and vice versa, is to use manual means of opening a file exporter window or dropping an appropriate ROP SOP, choosing appropriate options, saving the file and then loading it in target software. This becomes tedious and time consuming very fast, and like all other repetitive actions, increases the chance of user error. Therefore, I needed some means of automating the process. Let the computer do what it was designed for.

Presumably, it’s unnecessary to explain the boost in productivity that various “AppLinks” and “Bridges” provide by removing perceptible boundaries between applications. I’m sure many of you, dear readers have, or still are and will in the future, use at least one program which creates a tight connection between two tools that you’re using frequently.

Project Structure

Choosing the structure of the project was the only tough decision I had to make while working on the Clipboard. Both Houdini and Blender have at least one official and one semi-official repository, and they all have different requirements in regard to file hiearchy and other aspects of the candidate add-on.

Houdini’s official repository is its Content Library, which holds at the time of writing 73 items, so not much. They’re all official resources provided by SideFX and many of them are already shipped with Houdini binaries. No user-created uploads is allowed. The less official site, but which accepts user content, is Orbolt, but it’s more of a place to upload digital assets than a source code of a Python project.

Blender’s official repository does allow for user-created content, but that content needs to follow precise guidelines. This wouldn’t be a problem if this add-on would target Blender only. But because I wanted a single repository to handle Houdini’s and Blender’s side at the same time, I had to ditch the idea of uploading it there as the project structure wouldn’t comply with the requirements.

All in all, I decided to create a structure compliant with Houdini package specification while at the same time following Blender’s guidelines inside a nested /scripts directory, which then could be symlinked in Blender’s add-on path residing in $XDG_CONFIG_HOME. This makes the root of the project to be recognisable by Houdini as its package, and contents of /scripts as a Blender add-on. A typical Chinese win-win situation.

Geometry Exchange Format

Being a guy who fully endorses free and open standards (“free” as in “freedom”), and who needed a format that could support subdivision creases, point colors, and other custom attributes, I couldn’t choose anything else than Alembic.

FBX is a terrible proprietary black box. Because of that I always held it in a very low esteem and I’m sure I’m not alone in my opinion. In fact, I’m in the process of completely removing this format from my pipeline. Begone, foul beast!

The good old Wavefront OBJ is venerable, but its specification hasn’t been updated for ages. As a fully open, and a text-based format, it could easily be brought up-to-date to hold any geometry attributes. Why didn’t the developers of DCC software come to some form of agreement on updating this standard? I don’t know. Apart from that, the format has some other disadvantages. It doesn’t support animation (though this can be mitigated by exporting one file per frame). Then, it’s an ASCII file, so it’s slow to write to and read from, especially if we’re dealing with high-poly geometry.

From open formats, there’s also Collada, but to be honest I don’t know anyone using it in his or her pipeline. And finally — GLTF, but it’s perhaps more of a final output format than an indermediate one, although it can work in this role too.

Alembic is an open format, supports animation, custom geometry attributes, and can be saved in binary format, so the choice was pretty much obvious. It’s a perfect intermediate file format for geometry exchange, at least for the time being until someone can come up with a better solution.

A Practical Example

Using the Clipboard is very simple. After completing a trivial installation process, which is exhaustively described in the README.org file, you’ll have “Blender Clipboard” shelf in Houdini and a “Houdini” panel in the viewport’s sidebar in Blender.

Houdini’s shelf will contain three buttons: “Yank”, “Paste” and “Yank (Anim)”. Why “yank” instead of “copy”? Purely a preference of vim-key user.

Blender’s panel will lack the “Anim” button. The reason behind that is simple. I animate in Houdini, so I don’t need to export animation from Blender. It’s also problematic to paste animation into Houdini (again, consult the README.org file if you want to know why). But to be frank, the MERE reason why the “Yank (Anim)” feature exists at all, is that I thought that someone would complain that this feature is missing. Personally, I don’t use it at all.

So let’s put all what have been said into some practical context. Here’s a WIP of a subdiv Soviet D-8 armored car asset that I’m currently working on. All base shapes were started in Houdini, most subdiv parts which were too time consuming to model in Houdini, I’m passing to NVil or Blender, depending on which program I feel will make it more convenient to achieve the goal.

The car is still missing many parts, and one of them is armor cover of the windshield on the driver’s side. The base shape is already partially done, but requires proper topology for subdivision.

At this point, I could fix the topology in the program itself and there are a lot of different ways to do it, like using a long chain of PolySplit SOPs or by working with PolyDraw. However, this type of operation, especially if the geometry doesn’t need to be procedural, is usually best done outside of Houdini.

Besides, PolyDraw is a destructive node. In some ways it acts like a Stash SOP, which holds a modified copy of input geometry. After the initial edit operation, it prevents upstream nodes from affecting its contents, until all edits executed in PolyDraw are reset. We can observe this by enabling the View → Dim Unused Nodes flag from the Network’s menu.

Therefore, whenever I feel the need of using PolyDraw, it’s a good indicator for me that tasks which I intend to perform would probably be faster to accomplish with other software.

Here’s a short video of the clipboard in action, which demonstrates how to copy and paste two SOPs from Houdini to Blender, make some modifications to one of them, and move it back to Houdini. There’s no sound, so please don’t regulate your speakers.

The clipboard can be obtained from my git repository. Maybe someone will find as useful as I do.

Happy modeling.