Interchange framework is bypassed on the second attempt after a failed import

Development Pipeline & Plugins
, ,
1

Hello!

We have encountered a bug with the Interchange pipeline. When an interchange texture import is cancelled due to non-power of 2, and then the same texture is imported again without any changes, the texture is imported with legacy pipeline. This fallback seems to occur even though the asset was never fully imported via Interchange and never appears as a .uasset.

First import log:

LogInterchangeEngine: [Pending] Importing

LogInterchangeEngine: Display: Interchange start importing source [C:/…/T_Cat_D.jpg]

LogInterchangeImport: JPEG file [C:/…/T_Cat_D.jpg]: Pipeline setting ‘bPreferCompressedSourceData’ has been overridden by Editor setting ‘RetainJpegFormat’.

LogInterchangeEngine: Display: Interchange import completed [C:/…/T_Cat_D.jpg]

Interchange: Error: [C:/…/T_Cat_D.jpg : ‘’, Texture2D] Cannot import texture with non-power of two dimensions

Interchange: Error: [C:/…/T_Cat_D.jpg : ‘’, Texture2D] Unable to retrieve the payload from the source file.

LogInterchangeEngine: [Pending] Importing - Operation completed.

LogInterchangeEngine: Error: [Failure] Import Failed

Second attempt:

LogEditorFactories: Performing atomic reimport of [C:/…/T_Cat_D.jpg]

LogFactory: FactoryCreateFile: Texture2D with ReimportTextureFactory (0 0 C:/…/T_Cat_D.jpg)

LogEditorFactories: Display: JPEG imported and retained as JPEG in uasset.

LogEditorFactories: Display: Image imported as : TSF BGRA8

LogEditorFactories: -- imported successfully

What is the best way to prevent this behavior?

2

Steps to Reproduce
Repro steps:

  1. Make sure interchange pipeline is enabled for textures
  2. In DefaultTexturePipeline set Allow Non Power Of 2 to false
  3. Import a texture with an invalid size (eg: 1025x1023)
  4. Note that the import is cancelled
  5. Immediately try importing the same texture
3

I’ve debug this one a bit

First what is a bit “weird” is that In ImportSubSystem, after failing the texture import… it keep a memory of the failed texture that is marked for garbage collect! Garbage hasn’t pass yet so if we re import it won’t go in the import list , but will go in the reimport list since its using staticfindobject !

UObject* ExistingObject = StaticFindObject(UObject::StaticClass(), Pkg, *Name);

if (ExistingObject != nullptr)

{

ReimportFiles.Add(Filename, ExistingObject);

}

Then

it will go trough ReimportAsync and will discard the interchange reimport factory

trough this function Handlers[HandlerIndex]->CanReimport :

it will down the road call bool UInterchangeReimportHandler::CanReimport(UObject* Obj, TArray<FString>& OutFilenames)

which will call GetSourceFilenames … and later on : bool FFactoryCommon::GetSourceFilenames!

but will fail ! since AssetImportData member has never been set has a UInterchangeAssetImportData, since the first import failed and its still the base type !

Then the next handler will be tken in consideration which is the UReimportTextureFactory

It still failed down the road withouth later with a message telling it failed, but no reason why ( ie … wait for GC To go trough :stuck_out_tongue: )

has for the log posted above by jerome

There was a modifications on our project that made the texture go trough , which should have never happenned !

For info, this is still 100% reproable on a 5.6 vanilla editor !

If you have any question let me know ! If you have suggestion for a workaround , let me know also… il probably outpur more info or force GC untill there is a real epic fix

4

Hi Maxime,

Sorry for the inconvenience and thanks a lot for taking the time to troubleshoot the issue.

I logged a bug, UE-304023, so you can track our progress on this issue. Note that it can take some time before the link becomes operational.

Regards,

Jean-Luc

5

Hello,

A fix was submitted for this issue under CL 44080149. It might take a while for it to show up on GitHub.

I hope it helps. Feel free to reach out if you have further questions.

Best,

Vedang

6

hello !

Thanks a lot for the fast fix !

The fix works perfectly fine :wink: Juste integrated it on our side :slight_smile:

Best,

Max

7

Glad to be of assistance!

Thanks,

Vedang