Issue with iostore/any way to check if build made with IOStore enabled?

Development Platform & Builds
, ,
1

Hi there,

We are using Unreal 5.3.2 to maintain some legacy titles with large amounts of data between levels with complex materials. We are not using Lumen or Nanite in this project. We do use RVT on and off between these projects and the following issue presents itself despite this setting being enabled or not. We are not using Virtual Textures for the materials impacted by the following issue.

We have encountered issues in these builds between loading and unloading levels where it appears that some material proxies may be created before the resources they need are fully loaded. This ONLY occurs when iostore is enabled. Portions of materials show up partially bright white or grey (not default material, just like they are missing some data from the materials themselves) when this issue exhibits itself. Attached is an image of how the issue can present itself.

We need to keep iostore enabled for certain platforms to improve loading times on them, so disabling iostore is not an option for us here.

A workaround we found for resolving these issues for now is firing off UMaterialInterface::RecacheAllMaterialUniformExpressions(false) after a level load is complete, but that isn’t the ideal solution (ideally, the solve is that something related to async loading code underneath all of this can just make sure everything related to material proxies are created before the proxies themselves are made). Simply firing off this code after seeing the issue present itself instantly resolves it for the time-being, until another level unload/load has completed (to which you’ll then need to re-run the code).

We’re asking for two things:

  1. Is there a way to check if a build was packaged with iostore enabled? We only want to run this workaround code between loading with UMaterialInterface::RecacheAllMaterialUniformExpressions(false) if we know the build was made with iostore, but we cannot find any documentation on this (there only seem to be checks during cook/packaging for this flag that we can find, not at runtime), and
  2. Are there any ideas as to how we could resolve this at a lower-level? Maybe some async loading or iostore-related code changes related to resolving issues like this with materials using iostore that went in after 5.3.2 that we could merge back into our copy of 5.3.2?

We do not have a sample project to reproduce this issue, nor would it be possible for us to due to what we perceive to be some complexity with how large our project and assets are here.

Thank you,

Hannah

2

Steps to Reproduce

3

Hi Hannah,

Thanks for your feedback. I’ll get in touch with someone more knowledgeable of the IOStore and gather some potential leads to follow. Please bear with me.

If you have any new/additional information to share regarding this issue please let us know.

Thank you,

Massimo

4

Hi Hannah,

To answer your first question, we internally do something like this:

bool IsRunningWithIoStore()

{

    static const bool bRunningWithIoStore \=

        FIoDispatcher::IsInitialized() \&\& FIoDispatcherInternal::HasPackageData();

    return bRunningWithIoStore;

}

Second, about the deeper issue you’re seeing: from your description, it sounds like this isn’t actually a bug directly caused by IOStore itself, but rather a symptom that IOStore exposes because loading happens faster and some initialization logic might happen out-of-order because of this. It could be that your materials might be trying to render before the parameter data they depend on has fully loaded or has been set up, for instance.

One suggestion to debug this would be sprinking your RecacheUniformExpressions() and generally uniform expressions update to print out the state of the parameters of the affected materials to prove this. This might help pinpoint if certain parameters are initialized late, perhaps in a PostLoad() event or asynchronously, which would make them unreliable timing-wise.

Let me know if that makes sense or if you need any more information.

Best,

Massimo

5

Hi Massimo,

Thank you for the response! We are out of the office until August 18th but will check back on this as soon as we can with your suggestion of pinpointing the problematic material parameter that might be loading too late.

6

Hi Hannah,

Sounds good!

Massimo

7

(Bumping just to make sure this doesn’t auto-close by the time we’re back in the office)

8

Hi Hannah,

I will go ahead and close this ticket as answered.

Feel free to reopen it should you have more insights or need a followup.

Kind regards,

Massimo