We build several internal C++ libraries and plugins on top of Unreal’s OpenUSD SDK, and Boost is a hard dependency for a lot of that code. Currently, Unreal redistributes only a subset of Boost modules, so we build our own Boost binaries for the rest rather than mixing sources — but we’d much rather consume Epic’s Boost directly wherever it already covers what we need. Could you consider distributing the complete set of Boost libraries alongside the engine instead of a curated subset?
Here’s the exhaustive list of modules our code touches:
Hi Yurii, we don’t ship all of Boost for install size reasons. We’d remove Boost entirely if we could honestly. At this point, OpenUSD could be built without Boost so I think we only have OpenVDB that requires it and even then it uses it for a feature that we don’t so with some work we could drop it.
Hi Jean-Michel, thanks for your answer. When you say that OpenUSD could be built without Boost, do you mean that this is, in fact, how you build OpenUSD?
If you’re still using Boost when building OpenUSD, please provide the full Boost installation. This seems to be a requirement for us in UE 5.8, since your USD builds started routing global operator new/delete through USD’s own runtime memory-overload hooks instead of the CRT: if a third-party module linking against a separately built Boost doesn’t participate in that same allocation scheme consistently, you get heap corruption that only shows up intermittently, depending on load order and process layout, which makes it painful to diagnose. Shipping a complete, matched Boost alongside the engine would let us drop our own builds entirely and remove this class of cross-module allocator/ABI mismatches for anyone building USD-adjacent plugins against Unreal.
Ideally, we would just use your Boost in our OpenUSD plugin as a shared dependency.
Hi Yurii, I’ll forward your question to our USD expert. I don’t think our flavor of OpenUSD needs Boost but we still have it on our module rules as a dependency.
We did override USD’s memory allocation functions in 5.8 as USD by default uses the std allocator and its been a challenge to work with heap allocated USD objects on the UE side.
I’ll give the context to our USD engineer and they’ll work with you to figure out how we can get your USD + Boost plugins working properly.
Hi Yurii, as Jean-Michel mentioned, OpenUSD in our recent releases (5.6 onwards) does not depend on Boost. Removing Boost was a Pixar initiative that I believe first landed in the 24.11 release.
The module rules that still list Boost as a dependency are a leftover from before that and need cleaning up on our side (it contributes nothing to the built binaries today). As far as I know the only remaining consumer of the Boost we ship is our OpenVDB, which uses boost::iostreams. There’s a compile-time switch that removes even that, which is something we’re considering as it would let us drop Boost from the distribution entirely. Also note that the shipped Boost libraries are not modified to use the UE allocator (FMemory) and so can lead to heap corruption unless used carefully in a Win64 UE module or plugin (many Boost libraries are header-only though, and will therefore pick up the module-level UE allocator).
Regarding the changes in 5.8, we now compile replacement global operator new/delete into every OpenUSD DLL. They route through a single hook that UnrealUSDWrapper points at FMemory during module startup (note this is our patch, since upstream only has a glibc malloc-level hook that’s Linux-only). On Win64 this replaces the previous FScopedUnrealAllocs/FScopedUsdAllocs mechanism which (at the cost of significant code complexity) did offer some manual control over the active allocator. So if you’re using your own dependencies (Boost or otherwise) built against the CRT, and ownership of allocated objects crosses between those and an FMemory-based UE module, an allocator mismatch and heap corruption is possible.
Hopefully this information is helpful. Let me know if you would like more details of how we’re handling the replacements in the OpenUSD DLLs as it might be possible to do something similar for your own dependencies.
Thanks for the clarification, Anthony. I’m happy to hear that Boost is not used in the UE build of OenUSD and therefore wouldn’t cause any misconceptions with our build of this library. We managed to incorporate the UE allocator into our in-house USD plugins on the Win64 platform, and as of now, it runs without heap corruption errors, which we saw before.
An interesting note on `FScopedUnrealAllocs`/`FScopedUsdAllocs` - do you mean that they are now deprecated and we should stop using them in our Unreal plugins in 5.8?
Hi Yurii, good to hear you got your plugins working with the UE allocator.
Re your question, FScopedUnrealAllocs/FScopedUsdAllocs are effectively no-ops in 5.8 - they’re unnecessary now that the USD libraries are built to use the UE allocator. So yes you can safely remove them from plugin code (note we couldn’t deprecate them as such because we had to make a choice at build time between the scoped allocators and/or patching the USD DLLs. We chose the later because it’s hopefully simpler for everyone).