I’ve found a rather fascinating path issue with asset system. It seems to incorrectly process paths for asset’s Source File Path field. My best repro steps, plus explanation, follows:
Make sure UE4 is installed on C: in its normal location in Program Files. This may not work with a built copy. Create a project at c:/work/uproj, with a .fbx file at c:/work/uproj/art/model.fbx. Import file into project. Modify file in a very obvious way. Now right-click file and choose “re-import”. You’ll note a message saying it has re-imported successfully, but no actual re-import takes place.
Opening output log gives better information:
LogEditorFactories: Performing atomic reimport of [C:/../../work/uproj/art/model.fbx]
LogFbx:Error: Call to KFbxImporter::Initialize() failed.
LogFbx:Warning: Error returned: Corrupted or invalid file.
LogEditorFactories:Warning: -- import failed
And if you look in model info, you’ll see Source File Path is set to ../../../../../../work/uproj/art/model.fbx.
Removing first two sets of …/, leaving ../../../../work/uproj/art/model.fbx, will actually make it work - for exactly one re-import, at which point it’s set back to broken value.
It seems there’s a few bugs here:
-
UE4 is incorrectly processing file paths for project. Instead of giving a path relative to a sensible location - either relative to .uproject file, for example, or asset, or even arguably to binary’s working directory - it’s doing something relative to binary’s working directory, but adding a pair of extra …/'s to front. This leaves file with an invalid path.
-
engine does check to see if file exists before attempting to read it. On failure, it’s supposed to pop up a dialog you for a new file. However, this check is broken - it ignores extra …/'s prepended to beginning of filename, and FBX loader does not, meaning that it does not serve as a functioning check of whether file will be read properly.
-
While engine recognizes that FBX hasn’t loaded properly - see output log - it does not propagate this error code up to UI, and UI then assumes file was loaded properly, resulting in a very misleading status message.
I can attempt to track this down further if needed for fixing, but hopefully this is enough to fix those bugs.