Yelmond
commented
8 years ago - Support more than one version of Houdini
- The reason we can't quite do this yet is because we may still break the API within a major version of Houdini (ie. within 15.0). This means the Houdini Engine API version is not enough to guarantee compatibility. It's also just simpler to lock all versions together so we can eliminate a whole class of problems from the start.
- Allow Unreal integration when Houdini isn't installed.
- As you said, we're not too comfortable adding HAPI headers into the UE4 plugin source. What we're thinking is to simply stub out all HAPI calls (in HoudiniApi.h/cpp) to do nothing if a certain define is set, otherwise forward the call to the appropriate HAPI call. We can then build the plugin without HAPI.h just by adding some logic to the plugn .cs build file.
- Add !IsRunningDedicatedServer() in HoudiniEngine.cpp so that we can run headless.
- Yep, this will be added pretty much as you suggested. Expect it in tomorrow's build.
- Avoid duplication between HoudiniEngineEditor.Build.cs and HoudiniEngineRuntime.Build.cs
- Ya, we'll look into it but it's probably not a trivial thing to add and the benefit is fairly minor. We actually generate these files from our own internal template files so it's not as easy as just moving the code to common place.
ttvd
JaapSuter
...as well as allow usage with more than one version.
Note, I don't expect you to accept this pull request as is (it's specific to our use and contains a bunch of company specific comments). But it should give an idea of what we'd like to see and provide a start for how you may put this feature in the official version (i.e., I welcome discussions or suggestions on alternate ways to do the things below).
There are three separate requests in this pull request (and a third minor one):
Allow use with more than one Houdini version. Some of us are using Houdini 15.0.355, others are still on 15.0.244. Meanwhile, HAPI has not changed in a significant manner, so the plugin works fine with either version of Houdini installed. This way we don't force everybody to upgrade at the exact same time. Obviously when a breaking upgrade in HAPI/Houdini happens, we will in fact upgrade.
The way I've implemented this currently is not ideal. I'm just hard coding a list of versions I've seen in the wild, and running a for-each over that:
Instead, perhaps you can enumerate the available Houdini installs, extract the version number, and check if the minor or patch part of that number is within a supported range.
Not everybody on our team has Houdini installed.
The Unreal plugin system doesn't allow selective disabling of plugins based on decisions made in the plugin build file itself. That's why the Houdini plugin files throw a BuildException when it can't find a Houdini installed.
I've changed it so that it merely becomes a silent fail. The plugin will continue to be build and enabled. The key part is that it now has to refer to an embedded version of the five HAPI headers.
I'm not sure how you'll feel about including these five HAPI files with the plugin (since they come with Houdini already, but it's precisely to allow compilation when Houdini is not available).
At runtime, Unreal will load the plugin, but it just won't initialize properly. This isn't a problem as long as people without Houdini don't try to change Houdini assets (they just see the baked versions).
!IsRunningDedicatedServer()inHoudiniEngine.cppso that we can run headless.HoudiniEngineEditor.Build.csandHoudiniEngineRuntime.Build.csThese two files are very similar. Is there a way to share some code between these two? Perhaps we can extract things into a separate 'FindCompatibleHoudiniOrEngineInstallation' function that lives in a common place? I don't know how easy the C# Unreal build system makes this. This is pretty minor,