Texture Streaming Causing HUGE issues

I have been experiencing issues regarding the texture streaming in my project. My entire scene view can go black sometimes when i start up the project, and there is a persistent error which i can never solve.

This error is always there in my project (on opening), and i suspect this is what also points to the solution in some way.

“Graphics.CopyTexture could not find source D3D11 texture object. Maybe it is a RenderTexture that is not created yet?”
Screenshot 2024-11-28 160833

Worse yet, is that whenever i build the project and open the .exe, the view is completely black. This happens every time.

Prerequisites:
-I use windows 11, and build for “Windows”-“intel 64-bit”
-I use the HDRP
-My project is 3D, and uses textures
-There is a terrain in my scene

Everything i explained so far, does NOT occur when i uncheck:


And, after a restart, the scene view gets fixed, BUT NOT IN THE BUILD!!!

This is important for me to keep as True because without it, I have huge lag spikes as new textures are loaded in.

Editor True/False:

The build when “Load texture data on demand” = True:


The build DOES WORK, because when I input, i still get the charater to walk, i hear the sounds of the footsteps, i hear the environment, and the strangest of them all, only emissive things show up, such as the gauge on a handheld device, And is in the wrong color, should be green, but its plain white.
Example (look on the left of the image, youll see the gauge):

When i run the build in windows “cmd” with “myFileName.exe -logfile log.txt”, I find this error:

“Graphics.CopyTexture source mipmap size invalid when taking into account its current mipmap limit (0)”

This occurs about 30 times right at the beginning of the file.

I really need help on this, I need to be able to build my game, but removing the setting is not an option, as otherwise stutters are frequent.
I will attach a snippet of the txt to maybe see if the rest can clue us in on whats happening. Without the setting on, the build works perfectly fine and looks normal, but then my performance issues return, the ones which i was trying to get rid of.

log.txt (7.3 KB)

Hope to hear from some people soon, this is really important to me

This all started, when I posted this here (The topic of the post was resolved, unfortunately it broke my builds and gave me the errors previously mentioned):

Hi WishboneGames!

This sounds like a genuine bug. We’ve seen issues with the ‘Load texture data on demand’ before and I would advise to disable that feature. We are fixing some of the issues but we haven’t encountered this one yet. Could you submit a bug report?

Loading texture data on demand can be useful in the Editor when you are working on very large projects with many textures in your scene and you are running out of memory. If you are not out of memory, I would advise to disable the feature (until we have this fixed). Note also that it is a separate feature to Texture Streaming.

This is important for me to keep as True because without it, I have huge lag spikes as new textures are loaded in.
Load texture data on demand is not related to Texture Streaming (Mipmap Streaming). The tooltip is formulated in an unfortunate manner, mentioning ‘streaming’, but it is essentially delaying loading of your Texture assets in the Editor until the first time you need them. This is going to cause spikes in the Editor, that’s by design. But the feature has no impact on performance in the Player. If you want to avoid any spikes when doing Playing sessions in the Editor, you will need to preload your textures with a script or disable the feature.

Thank you for sharing. We would very much welcome a bug report on this so we can get it fixed.

Thank you so much for helping @BartPieters.
Ill be submitting the bug report later today. Thanks for clearing up my confusion about the feature, thats really interesting, and honestly a huge relief, knowing that it does not impact the player at all.
Im up for changing the title of the topic if you have a more accurate suggestion?

Once again thanks so much, I was clearly very misinformed about what this feature actually does.

What would be the best way to make sure a particular texture is “in demand” and not skipped by this feature? I have a list of a few tetxures that aren’t loaded ocasionally: SMAA texture, HDRP water noises, clouds. I can not set them as isReadable on CPU as they are part of HDRP package. How can I ensure that they are referenced by something that will make them always load up?

Hi @Genebris, I have to admit I’m slightly confused by the thread and the long span of time since the earlier discussion. For my understanding, were some of the issues you was already fixed by updating to a newer version of Unity? As Bart mentioned we have fixed issues with “load texture data on demand”, did those make a difference in your case?

On issues you’re still seeing …

If this is a texture streaming issue (as the title suggests), then my first thought would be to have a look at Unity - Scripting API: Texture2D.requestedMipmapLevel ; at least if this is runtime issue and you’re seeing spikes or you want to preload some texture mips, you could use this API to be ahead of the TextureStreamer and start streaming in the data.

If this is texture streaming, but it’s going wrong in the Editor, does it make a difference if you disable “Enable Texture Streaming in Edit Mode”?

My assumption is actually that this is still about “Load texture data on demand”, which is a bit unfortunately grouped with those two “texture streaming” settings. Since you mention you “cannot set those textures to readable”, am I then correct to assume you’re doing something with the data on the CPU?

(just trying to get a picture of where you’re at, right now, and what issues you might be facing …)

Hi @jonaskhalil , it’s simply the issue with load texture data on demand in the editor, not the mip map streaming. It’s still bugged unfortunately. I’m on Unity 6.1.12

Very simple case: HDRP package has a texture called FoamMask. It is used for water by default. Mip mamp streaming is disabled for this texture. If you have load on demand enabled and load a scene with water, you MAY randomly get water with no foam. Because this texture object exists but its data is empty - full black essentially.

I’m not reporting this as a bug because I’ve tried reporting this kind of issue in the past and they couldn’t repro it on their side due to random nature of it.

I know a workaround for this: marking texture as read\write enabled. This way editor will always load its data. But I can’t do that without modifying HDRP package and I don’t want to do that.

I think a different workaround should be possible: linking this texture to a monobehaviour in a scene and calling some method on it that will make editor realise that this texture needs to be loaded from disk. Hence my question for advice: what do you think should I call on this texture object to make sure it’s treated as being in demand by this editor feature?

Interesting, thanks for elaborating … So are you saying this is misbehaving out-of-the-box with Unity packages, or is there custom (your own or 3rd party) code trying to use those textures? Sounds like this might point to some internal issue; perhaps something that typically doesn’t pop up because of some orders of execution that internally triggers some “demand” but in your random case the demand is happening too late :thinking:

What you could try to do is use those textures in some throwaway Unity - Scripting API: Graphics.CopyTexture calls (which should suffice to trigger this demand, at least today). I do assume you’d have to make sure this is executed early enough, before HDRP needs these texture data in some way?

I’m not reporting this as a bug because I’ve tried reporting this kind of issue in the past and they couldn’t repro it on their side due to random nature of it.

Well that does sound concerning to me; and can you reproduce those issues on other devices, or is it tied to one specific device? The fact that it’s “random” should not be a reason not to report this. If it’s so random that it only happens once every 1000 runs obviously makes it harder to fix, but it doesn’t sound like that’s the case here …

Thank you, I’ll try this call soon.
This is with just HDRP package and nothing custom. My team members also experience this. I’ve reported empty textures with this feature in 2023 but it led nowhere. Will try to prepare a new report.

@Genebris just a quick ping since it has been quiet for a couple of weeks, did you already have the time to try this out?

Yes, I think it works well.

using System.Collections.Generic;
using UnityEngine;

[ExecuteInEditMode]
public class EditorLoadOnDemandWorkaround : MonoBehaviour
{
#if UNITY_EDITOR
    [Header("Editor only woraround for load on demand bugs leaving some textures empty")]
    public List<Texture2D> textures = new List<Texture2D>();
    void Awake()
    {
        MipmapLimitDescriptor mipmapLimitDescriptor = new MipmapLimitDescriptor(false, null);
        foreach (var texture in textures)
        {
            Texture2D throwawayTexture = new Texture2D(texture.width, texture.height, texture.format, texture.mipmapCount, texture.isDataSRGB, false, mipmapLimitDescriptor);
            Graphics.CopyTexture(texture, throwawayTexture);
            DestroyImmediate(throwawayTexture);
        }
    }
#endif
}

Okay that is great to hear! Regarding the workaround fix, I assume this is not a performance concern in any way (Editor-only) but if it was, this fix should work equally well if you even just copy one pixel of any specific mip level, to load the entire texture.

Now for the actual issue:

Just to be absolutely sure I’m not misreading your reply: this is an issue that happens with HDRP itself, right? This is not about custom user scripts using HDRP resources. From a quick scan, I don’t immediately see where this might be going wrong within HDRP itself, so any repro case or repro steps could be valuable. So if you find some time, it would definitely be valuable to have a bugreport on this so we can fix this properly and you can get rid of the workaround code.