Corrupt mips using StaticLoadObject on a UTexture

Development Rendering
, , , ,
1

I’m building a package of very simple data (textures and wav files) in one project and loading it in another. This is aimed at user generated content and I’ve got to this solution after bashing my head against the unreal packaging system (square peg, round hole syndrome).

Finally textures are now loading from uassets, but the larger mips (perhaps only the top mip) are garbage data.

Pack file hookup:

FString StandardFilename(rPakFileName);// m_DownloadedCache.GetCacheRoot()); //
FPaths::MakeStandardFilename(StandardFilename);
StandardFilename = FPaths::GetPath(StandardFilename);

if (!mp_DLCPakFiles->Mount(*rPakFileName, 0, *StandardFilename))//DLCPakMountPoint))
{
	return false;
}

FPackageName::RegisterMountPoint("/DLC/", StandardFilename);

Image loading:

FString unrealPath = "/DLC" / FPaths::GetBaseFilename(m_FileName, false); 
			auto ret = Cast<UTexture>(StaticLoadObject(UTexture::StaticClass(), NULL, *unrealPath, *uasset));

Any ideas why the mips might be corrupt? The UTexture meta data seems correct.

I’m assuming mips because when I scale my window down and make everything smaller it starts drawing the correct textures.

2

The corruption are pretty frequently another texture. It’s just like the top mips are bound to some random memory.

3

Likely a problem with the cooking process, for editor builds I create a pak file of the precook uassets, each texture uasset is about 3x larger than that in the cooked pak file.

Two different projects are used, one to cook the assets, one that is the actual game. Could there be a difference in their settings causing one to cook assets without the top level MIP and the other to miss the fact that they don’t exist at runtime?

4

Also happens on Mac which makes sense as I’m using the same pak file and works fine on iOS where I would assume the engine isn’t using the top mips of the textures I’m using.

The process for building the pak file is:

  • import texture from png (no human interaction involved)
  • RunUAT
  • Extract the cooked assets and repack again (primarily to add some non unreal files, I also adjust the paths slightly in the pak)
5

Well - I only repack the files I think are needed, perhaps I’m leaving out something important - looks like UE3.0 had some special texture streaming files for cooked builds. Will dig around in the morning and see if anything stands out.

6

Looking at it though I’m just skipping the CookedAssetRegistry. It’s very bloated and doesn’t seem to contain anything interesting but perhaps there’s something useful in there?

7

Still open as an issue - what might cause me to miss the top level mips in my custom repack stage?

I only need the custom repack because there is no ability to pak non unreal assets into plugins, adding a custom UObject type to put my loose files into unreal type data would mean custom code which would mean no packaging iOS on PC.

Rocks and hard places all around :slight_smile: