Open Mesh Effect branch (prev. Houdini Engine modifier for Blender)

@brecht @Elie @Keavon

Similar to Keavon’s suggestion…

Instead couldn’t a middleware Asset Engine (handler/converter) be constructed?

An Asset Engine (Handler/Converter) could do the following;


  1. Open Asset Engine (Handler/Converter).
  2. Select Houdini asset file.
  3. Edit parameter.
  4. Asset file (temp autosave) in Asset folder.
  5. Open Blender.
  6. Append Asset file (temp autosave) from Asset folder.
  7. Adjust Blender Asset Refresh to desired refresh rate.
  8. Continue editing in the Asset Engine (Handler/Converter).

The only linking to Blender, would be by the user appending an asset file in Blender.

Blender: Asset Refresh

  • An asset refresh timer would allow Blender to update the asset data after X amount of time.

Asset Engine (Handler/Converter): Asset autosave

  • A (temp autosave) would allow the Asset Engine to automatically save data after a parameter change.

If the update timing of the two programs a relatively the same, the user could have the asset update in Blender within moments of the Asset Engine parameter change.

Do to the nature of the middleware, the GPL should not be an issue.

Lol. In a sense, Blender could be used as a viewport for the Asset Engine (Handler/Converter).

You could create various plugins allowing other functions/programs to do the same.

@brecht I tried your suggestion of making a variant of blender_add_lib for dynamic linking:

But it still tries to use hbridge.o/.obj when building blender.a/.lib, apparently:

10>------ Build started: Project: blender, Configuration: Release x64 ------
10>   Creating library E:/SourceCode/blender/build_windows_Full_x64_vc15_Release/bin/Release/blender.lib and object E:/SourceCode/blender/build_windows_Full_x64_vc15_Release/bin/Release/blender.exp
10>bf_intern_hbridge.lib(hbridge.obj) : error LNK2019: unresolved external symbol __imp_HAPI_CreateInProcessSession referenced in function houdini_Modifier_runtime_ensure
10>bf_intern_hbridge.lib(hbridge.obj) : error LNK2019: unresolved external symbol __imp_HAPI_Initialize referenced in function houdini_Modifier_runtime_ensure
10>E:\SourceCode\blender\build_windows_Full_x64_vc15_Release\bin\Release\blender.exe : fatal error LNK1120: 22 unresolved externals
10>Done building project "blender.vcxproj" -- FAILED.

The function houdini_Modifier_runtime_ensure() is a static function of hbridge implementation, there is no reason for the blender project to even be aware of its existence…

I first though it was because the build system would force static linking of what is in BLENDER_LINK_LIBS defined in blender_add_lib but I could not find any other references to this variable in the CMakeLists.

@Dev1 Thanks for giving it a though, but imho this sounds a bit overkill. ^^ If the middleware approach works, then the strategy of building a generic hbridge should be valid too.

I believe that is your only option here. I would suggest going through an intermediate file/stream format that is open and documented, such as Alembic or USD - not only will that useful for debugging, but it will also allow it to be modified to work with programs besides Houdini.

Anything else is about as clear of a GPL violation as I can imagine: You’re taking Blender and Houdini Engine and link into a single program. You’re releasing a version of Blender for which you can’t provide the full source code, as your build relies on third party source code.

Reimplementing the Houdini API as a no-op GPL stub is something that may infringe SideFX’ copyrights. I don’t know the details of the license of Houdini Engine, but depending on the jurisdiction you’re in, simply usign the same function names could be interpreted as a copyright violation.

I understand your motivation, Houdini is a powerful software and when used together with Blender, one can do spectacular things. And it’s cumbersome when going through the import/export tools. I’m all for improved exchange between Blender and other programs, but I don’t want you to get into legal trouble over this.


I have also been keenly eyeing the Oracle v. Google case and hoping the Supreme Court accepts its appeal (although I haven’t seen any updates on that lately). The entire software world has operated until now on the assumption that API naming is free to use, as long as you don’t steal any code (just the names of the interfaces).

But assuming that is the case (the English text that is the name of the interfaces) is fair game to reuse, then that also begs the question: how does any add-on (for example) for Blender (or any other GPL software) actually violate the GPL license if it doesn’t actually contain any licensed code? Sure, it “happens” to be code that does useful stuff if some user decides to download that code and stuff it into Blender, but the actual author of the code just wrote their own original code, unrelated to Blender’s code. How, legally speaking, can the GPL claim to have any jurisdiction over someone’s original code?

Oracle v. Google is about a clean-room implementation. A Blender add-on does not only use the same names as the Blender API but also directly relies on their implementation by calling them and sharing data. You can’t develop a Blender add-on without using Blender.


@brecht @Elie

You’re welcome.

The idea is more like a plug in/add on, then a full blown middle ware.

I should have thought a bit more about the usage of the terminology, my apologies.

Below is a simplified version of the idea.

Plug in for Houdini: Generate a temp autosave asset file upon a parameter change to a user defined folder. (Toggle: On/Off)

Add on for Blender: Auto refresh assigned asset after X amount of time. (Toggle: On/Off) (X: User defined) The assigned asset would be an appended asset.

The asset file format could be Alembic or something.

It would be nice to have an auto refresh asset feature in Blender. This would be helpful when working with vertex paint and vector displacement nodes.

Reimplementing the Houdini API as a no-op GPL stub is something that may infringe SideFX’ copyrights.

Once again, I am not reimplementing SideFX’ API. What I reimplement is my own API, for the intermediate program I called here “hbridge” (I should find another name, not Houdini-related).

I think it is time for a little drawing:

My idea is to define some open API in the same spirit as OpenFX does for 2D compositing. There are multiple GPL implementation of an OpenFX host, nothing prevents it, even though some OpenFX plug-ins are closed source. Since there exist open source OpenFX plug-ins (like all of Natron’s nodes), then an OpenFX host can be GPL.

Same here, let’s call it “OpenShapeGraph”. Blender would be an OSG host, and there would exist open source OSG plug-ins. And as a Houdini-based OSG plug-in that would happen to be compatible.

I strongly believe that this actually is the spirit of the GPL: forcing one to route code through open APIs to foster open source alternatives. Because by doing so, we pave the way toward an open source substitute for the Houdini part, so in the end, thanks to the constraint of the GPL, my implementation of the Houdini-Blender bridge helps spreading open source software. I would love to see an open source alternative to Houdini and this may help.

To take another example, if Allegorithmic would like to develop an “Substance Engine for Blender”, they would then have to go through this work of defining an open plug-in standard and this would be good for the open source community. I think that this is the spirit of the GPL, the GPL is not meant to frustrate developers but to foster the emergence of standalone open-source ecosystems.

edit: As I read OpenFX’ specification, I realize that the Core spec can be used as is in our case, because it is quite general. We could write a “Mesh Effect” OpenFX API, similar to the “Image Effect” OpenFX API used by Natron and the likes.


I want to ask you to respect the logo guidelines. This is not a product made by Blender Foundation, so you have to use your own identity. I also think Sidefx would think the same.

Just use the words Houdini and Blender, and add the logo of your own company or your name/url if you don’t have this.

Our logo guidelines:

Ton Roosendaal
Blender Foundation


My apologies, I just fixed the banner of the GitHub repo. And you’re right, I removed SideFX’ logo as well. Let me know if it still feels too much like the original, I don’t know exactly what’s the rule for this.

Little heads up: I have started to draft an open API for modifiers based on OpenFX:

eliemichel/OpenMeshEffect on GitHub

The core contribution is in the file include/ofxMeshEffect.h. The repository also contains a draft of host code, that I could successfully run from a Blender modifier. Still a lot of work to do, but it’s taking shape.

Note to moderators It seems that all my posts with a linked to GitHub have been suddently flagged for spam, and discourse refuses me to send a message with a link to “github dot com” host… Any way to fix that?


Heads up again, I have been able to reproduce the original results with the Open Mesh Effect modifier and a Houdini-based runtime plugin:

So I removed the originally published source code, the one that had licensing conflict, and will release the OpenMeshEFfect branch on one hand, and the Houdini-based OpenMeshEffect plugin on the other one. Just need some time for clean up first.


The current implementation of the OpenMeshEffect modifier is now online:

Really WIP and dirty at the moment, open for feedback. In particular, I am not sure I handle the modifier parameter’s DNA/RNA in a very idiomatic way…


I’m not a developer but I was just thinking… instead of creating your own API on top of OpenFX core wouldn’t pixars USD work? (Honestly am not technical enough to tell but that seems to be the idea)
“But unlike other interchange packages, USD also enables assembly and organization of any number of assets into virtual sets, scenes, and shots, transmit them from application to application, and non-destructively edit them (as overrides ), with a single, consistent API, in a single scenegraph. USD provides a rich toolset for reading, writing, editing, and rapidly previewing 3D geometry and shading.”

If it did, though, it would probably allow you to do more (since USD itself will have lot of development from industry and it seems like Blender Foundation will at least sponsor work on USD as an import-export format)

1 Like

I can understand why the mention to “non-destructive edits” catched your eyes. :slight_smile: But it seems to refer to parameter overrides, not to some modifier-like standard. As far as I know, such a thing is not part of the USD format, but I’ll give it another look just in case. I am surprised tbh that there seems to be no open format for mesh effects, I would rather use something that already exists.

1 Like

OpenMeshEffect sounds really interesting, is this limited to just a mesh modifier or could it do things in general to the scenegraph as well?

Some ideas off the top of my head:

  • Gaffer/Cortex bridge, feed in a procedural scenegraph or use OSLObject nodes to modify meshes, this could be a good open source alternative to Houdini Engine
  • Use OSL shading code to modify geometry, much like Gaffer’s OSLObject node or Houdini’s VEX
  • ISPC loader to modify geo or use Spirv-Cross’s ISPC export so you can use GPU shader code eg. GLSL
1 Like

If you think about it, a modifier is no less than a procedural node like Houdini’s SOPs, provided that it can have multiple inputs through object pickers, like Boolean modifier does for instance. So, yes, I would love to see it be the base for some open source alternative to Houdini Engine as well.

Your ideas are interesting things to explore. I would add, from above my todo-one-day-list:

edit: Since I had some trouble finding how to add a new modifier in Blender at the beginning of my project, I just wrote a little guide for this:


@Elie Thanks for the guide. Your project looks very interesting I hope more talented developers jump on board with it. There is really a lot of potential here.

1 Like

The development of the Open Mesh Effect branch keeps on going with some noticable news:


Maybe you should change the title of this thread to OpenMeshEffect instead of Houdini


I wrote a blog post to summarize the current state of the project and its context: