Hi there, I have an issue importing USD files at runtime with the SetRootLayer function from the UsdStageActor. I have an actor that on beginPlay spawns a UsdStageActor and gives it a .usdz file (all done in Blueprints). At runtime in the editor, this stage editor has the correct Mesh. However, when I build the project, no USD files are loaded anymore. The Unreal Documentation says to add
to my ProjectName.Target.cs file because I am not using a Source Build of Unreal Engine. In this thread UE4.27 Runtime USD Import the solution is to build the Engine yourself. Is this still required for USD import at runtime in UE5.6?
After adding that, I get this build error:
Target 'ProjectName' contains a definition for 'FORCE_ANSI_ALLOCATOR' allocator define. It conflicts with the new allocator type declaration via UBT. Please use 'StaticAllocator = StaticAllocatorType.Ansi;' in your *.Target.cs instead
Doing that, I now get a runtimeError:
LogUsd: Error: The USD SDK is disabled because the executable is not forcing the ansi C allocator (you need to set 'FORCE_ANSI_ALLOCATOR=1' as a global definition on your project *.Target.cs file). Read the comments at the end of UnrealUSDWrapper.Build.cs for more details.
That comment says, to use USD import, you need to add these lines to your Target.cs:
so I added the second line as well, but the error message persists.
To clarify: my issue is the Engine throwing the USD SKD disabled error.
Is there any solution other than building Unreal Engine from Source (and removing the overrideBuildEnvironment line)?
you “HAVE” to use source code version. launcher version doesn’t support that target.cs modification or use gLTFRuntime to import GLB files instead of USD files. Btw. at core UE4 and UE5 are not that different. Runtime model imports are not Epic’s priority list.
I looked at why we needed to force UE’s allocator. Is it about OpenUSD or something else ?
Epic’s Developer Assistant told this.
> GlobalDefinitions.Add("FORCE_ANSI_ALLOCATOR=1");
> ```
>
> This ensures that both Unreal Engine and the USD module use the same (standard, CRT) heap allocator for all memory allocations.
So, **it's not fundamentally required by OpenUSD itself**, but rather is necessary when using the supplied OpenUSD/Intel TBB DLLs delivered with UE. It avoids mixing allocators between engine and plugin, and so ensures stability.
## Summary Table
| Requirement | Imposed By | Why? |
|--------------------------|-------------------|------------------------------------------------------------------------------------|
| FORCE_ANSI_ALLOCATOR=1 | Unreal Integration| To ensure all allocations use the same (CRT/ANSI) heap, preventing heap corruption.|
| USD built with ANSI heap | OpenUSD (default) | OpenUSD expects standard behavior, unless specifically reconfigured/debugged. |
## Best Practice Guidance
- **Always** set `FORCE_ANSI_ALLOCATOR=1` if using the USD Runtime Importer at runtime in Unreal (especially on Windows).
- Do **not** mix memory allocated by a third-party DLL (like OpenUSD) with Unreal Engine objects or allocators unless you're certain both use the same heap.
- This change is not needed if you use USD for offline/editor workflows only, because memory lifetime is managed more simply and boundary transfers are less likely.
---
### Further Reading
- See [Unreal documentation on memory allocators](https://docs.unrealengine.com/5.0/en-US/unreal-engine-memory-management-and-allocators/) for insight into how Unreal replaces allocators.
- For advanced users: If you build USD and all its dependencies _from source_ as integrated into the same binary (with Unreal's allocator), in theory, you could avoid this flag. However, this is rare and not recommended for most projects.
---
**In summary:**
The `FORCE_ANSI_ALLOCATOR=1` requirement comes from Unreal Engine’s integration needs for runtime USD importing, not from the OpenUSD project itself.
If you need step-by-step instructions on where/how to add this in your Target.cs file or need extra details on memory debugging, let me know!
So, it won’t an easy thing to do without core changes if we want to go with current pipeline.
But we can use other libraries. For example, I have an in-house OpenCASCADE based plugin that can import STEP, IGES, USDZ and GLB models at runtime. But it requires OpenCASCADE license to use it with commercial projects.