UsdResources is not being copied by UnrealUSDWrapper.Build.cs

Development Pipeline & Plugins
, ,
1

Hey,

After upgrading from 5.5.4 to 5.6.1, we’ve noticed that UnrealUSDWrapper.build.cs is not properly copying UsdResources. It works fine on 5.5.4 but on 5.6.1 the copy of the files never seems to happen and there’s no clear reason as to why.

I’ve added logging to UnrealUSDWrapper.Build.cs as shown below, this logging does fire when generating new project files so it is being executed but when you try and build Development Editor Win64 nothing actually gets copied.

Could you offer any insights into why this might be and how we can diagnose/resolve it?

Cheers!

				// TOMW
				Console.WriteLine("TOMW: 2 ");

				// Move UsdResources to <Target>/Binaries/ThirdParty/UsdResources. UnrealUSDWrapper.cpp will expect them to be there
				RuntimeDependencies.Add(
					Path.Combine("$(TargetOutputDir)", "..", "ThirdParty", "USD", "UsdResources", Target.Platform.ToString()),
					Path.Combine("$(PluginDir)", "Resources", "UsdResources", Target.Platform.ToString(), "...")
				);
2

Hi Tom, long time no see!

I’ve tried to reproduce this on an Editor build of the Lyra sample project on UE 5.6.1, and I can see all of the RuntimeDependencies from the UnrealUSDWrapper module copying. There should be three different sets of files copied:

Engine\Binaries\ThirdParty\Python3\Win64\python311.dll -> Engine\Binaries\Win64\python311.dll
Engine\Plugins\Runtime\USDCore\Source\ThirdParty\USD\bin\*.dll -> Engine\Binaries\Win64\*.dll
Engine\Plugins\Runtime\USDCore\Resources\UsdResources\Win64\** -> Engine\Binaries\ThirdParty\USD\UsdResources\Win64\**

I’d suggest checking whether the files exist in the source locations to confirm that there’s something there for UBT to copy. There should be 69 items in Engine\Plugins\Runtime\USDCore\Source\ThirdParty\USD\bin\*.dll and a total of 148 files under Engine\Plugins\Runtime\USDCore\Resources\UsdResources\Win64\** .

Assuming you’re still submitting all of the binaries so non-coders can use the editor, my suspicion would be that because some of the files haven’t changed, the timestamps may still match between the source and destination, and given UBT only invalidates based off timestamps, the files are not being copied because UBT sees that they’re already up-to-date. If you’re running a build when you’ve confirmed that the files don’t exist in the destination locations then it won’t be this, but if they do exist, it’s worth deleting them, running an Editor build and seeing if they are then copied.

If you confirm that it’s not the above timestamp behaviour causing the copy to be skipped, then given these files are third-party and won’t change until you next take an engine upgrade, you can just copy them yourself in a manner that preserves timestamps and submit them and then they should be present for the editor and shouldn’t cause you a problem.

If none of the above is sufficient and you want to further investigate the problem, then the relevant code that generates the copy actions begins at Engine\Source\Programs\UnrealBuildTool\Configuration\UEBuildTarget.cs, line 2687:

List<RuntimeDependency> RuntimeDependencies = new List<RuntimeDependency>();
Dictionary<FileReference, FileReference> RuntimeDependencyTargetFileToSourceFile = new Dictionary<FileReference, FileReference>();

I’d suggest breakpointing there and stepping through whilst debugging, running with arguments “EVEVanguardEditor Win64 Development” - RuntimeDependencies and RuntimeDependencyTargetFileToSourceFile should both contain the relevant output files, and the foreach loop immediately below should create the copy actions. To force this breakpoint to be hit, just add some whitespace in the file to force UBT to rebuild, which will in turn force a new manifest to be generated.