Lighting build failed

I get the error: Lighting Build Failed - Swarm Failed to kick off.

Log from swarmagent:

9:43:20 PM: [Interface:OpenChannel] Error: System.IO.IOException: The process cannot access the file ‘C:\SwarmCache\AgentStagingArea\8487AD2E5DBA413C81373D29B2915895.C697AFCF4FD55F51E71D90B7DE56F1CD.mtrlgz’ because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream…ctor(String path, FileMode mode, FileAccess access, FileShare share)
at NSwarm.FSwarmInterface.OpenChannel(String ChannelName, EChannelFlags ChannelFlags) in D:\Perforce\Epic\UE4\Engine\Source\Editor\SwarmInterface\DotNET\SwarmInterface.cs:line 1590

Following other users solutions on the internets I have tried, one at a time:

-made sure only one instance of swarm is running

-restarted UE4 and computer

-made sure the firewall isn’t blocking it

-added exceptions in Windows Defender (virus scan in Win10) for the swarmcache folder and swarmagent.exe

-Deleted the files in the swarmcache folder, and then cleared the cache and verified

-Moved the SwarmCache folder to c:\swarmcache

-updated the reflection captures

-deleted all the lighting, reflection captures

-removed the last few meshes placed in the scene

-made sure no two meshes have the same name

-verified the build of 4.10

-installed 4.11p4 and cloned the project into that

I don’t get this error when building lighting in other projects, which must mean something particular is wrong with this project level.

I really, really don’t want to have to start this project over from scratch. Any help is appreciated.

Hi Tauricity -

If it is only happening with one project, look through the World Outliner and see if you have any Static Meshes or Actors with a reference to None instead of an actual mesh, in which case delete those actors and see if the build will succeed.

Thank You

Eric Ketchum

Forgive newbie my ignorance, but I don’t know what “reference to None” means. How do I figure out if a mesh or actor has a reference to None?

No problem you are looking for a mesh or actor like this one:

Eric Ketchum

Oh, okay, I get it, thank you.

But no luck. Each item in the world outliner than can have a mesh has one. But this did get me thinking. So, I went through and started deleting one object at a time, trying to find the culprit.

Turns out one object had the “same” material in two different element slots. Which I didn’t think should be a problem, except somehow I had imported the Starter Content twice: FP_StarterContent and StarterContent. So there were two materials with the same name, but actually different files being referenced. D’oh. Cleared one Materials Element and it builds fine.

A silly mistake on my part.

I really appreciate your help, Eric.

Your answer is almost correct. One common reason you may get the “used by another process” error is when .uasset files are duplicated in a project without being imported in the regular fashion. When a uasset is created by Unreal it is assigned a Lighting GUID. If you duplicate that uasset in your project using your file manager without Unreal assigning a new Lighting GUID, then both copies of the asset will have the same GUID. If you then use both of the assets within the same level, lighting builds will fail because Swarm is literally trying to write to the same file multiple times, one for each asset with the duplicated GUID.

Unfortunately Unreal does not provide any built in tools to deal with this scenario, and it is very easy to have this happen. It’s important to note that this has nothing to do with the material/mesh/texture’s name or location in your Content folder. You can have multiple assets with the same names in different subfolders of your Content folder without any issues, contrary to what you will find on many answers relevant to Swarm Failed to Kick Off (SFKO?). Your options are to painfully track down the duplicated asset (which I don’t recommend if your project is nontrivial), or reassign the GUID of the duplicated asset. There are no tools I know of to actually surface what assets are sharing lighting GUIDs, so a surgical solution is not easy. Provided you don’t have a primed Swarm cache you are hesitant to blow away however, you can just reassign the Lighting GUIDs for all of your assets which ensures that none will be using the same GUIDs using an editor plugin you can find on another question (listed below). Make sure to have a backup of your project and allow for a fair bit of processing time unless your project is small, and note that the editor plugin does not have confirmation dialogs or undos. The editor plugin has buttons for reassigning Meshes, Materials and Textures, and you might notice that the file extension of the file Lightmass chokes on indicates if it is a mesh (meshgz), a material (mtrlgz). I’m not sure what the indicator is when a texture lighting GUID is duplicated.

Anyway, you can find the editor plugin here: Lighting build failed. Swarm failed to kick off - Rendering - Epic Developer Community Forums

See littlerussian’s answer.

The biggest lesson to learn here is always use the Unreal Content Browser to handle bringing content into your project, as well as making copies of assets. Don’t do it from your file manager!

The second lesson is that it’s always good to minimize duplication of your assets even if your lighting is building fine. The Paragon assets are a perfect example of where you can end up with tons of duplicated materials and assets that could be shared (not that just installing the Paragon packs without fiddling in your file manager is likely to lead to the IOException SFKO issue), and it seems it’s mainly a failure of the design of the Unreal Marketplace installation system – I don’t think there’s any way for multiple packages to share assets, or to declare dependencies so that a hypothetical “ParagonCommon” package could be auto-installed when you install any of the Paragon characters.