Hello wonderful people of the Unity beta forum, long time no see 
My Texture3D Atlas Import Pipeline (link) causes problems in Unity 2022.1 with “Load texture data on demand” enabled.
Case 1408325 contains the project I use in the video.
2 Likes
QA was able to reproduce the issue and added a public issue tracker item. Thank you!
2 Likes
Hi @Peter77 , good to see you! Thanks as always for the great report.
1 Like
Not sure if I should report it separately or add to this report. When I make a build with this option, some textures end up empty in a build. I also get this errors multiple times during building (it says access denied). And error “There was no texture data to upload” appears in a log.
2022.2.16
I’ve spend two weeks not understanding what is going on.
Would love to comment on issue tracker if it allowed me to log in at all.
Same issue for me on 2022.2.18f1
UPD: Also reproduces on 2022.3.5f1 (LTS). Would hope that LTS will also get the fix.
Still reproducing on 2022.3.16. Have to always turn it off before build.
Hey, I wasn’t aware there was this forum thread as well … @Peter77 and @Genebris , to what extent is it a solution to mark your source textures as readable?
In an accurate sense, this is actually by design but CopyTexture is not strict enough apparently … As the docs mention, “This method copies pixel data from one texture to another on the GPU. If you set Texture.isReadable to true for both src and dst textures, the method also copies pixel data on the CPU.”; so, since this code is trying to store a Texture3D asset using the CPU data, by design the source should have its data readable … The observed effect is indeed this: there’s no readable data, so nothing gets copied and you see garbage in that Texture3D.
Just for me to get some grip on the context: is having those source textures readable a solution here? Are there reasons why this is actually not a (desired) option? Or was it simply not clear that this was the cause of the issues?
I’m marking several textures as read/write in inspector to solve this bug in the editor. Some special textures appear empty even in the editor. This is not happening with textures for regular models but for things like clouds texture in HDRP cloud layer or SMAA texture which results in SMAA doing nothing. Marking them as read/write solves this. But this is in the editor. I’m going to assume this also works in build but I obviously can’t mark all my textures as readable as this doubles the memory cost afaik. In build this can happen for any random textures used by models or .exe icon or cursor, so this would require marking everything.
Well, since the original post concerned a “Texture3D Atlas Import Pipeline” I was under the impression that this was about behavior in the Editor 
Regarding behavior in Player builds, this should never have worked … If something did regress there, that sounds like a genuine bug and should be reported. “Load texture data on demand” should definitely not affect Player behavior.
But in short, yes, if you need the CPU data you need to mark the textures to be readable. It indeed “doubles” the memory cost, in the sense that you’ll have a copy in CPU memory and a copy in GPU memory. Again, this is only if you need the data on the CPU. I don’t know the exact use-case, but:
- if you just need to copy the data for rendering, just the GPU copy maybe suffices and you don’t need readable textures?
- if you actually need to do some pixel operations, maybe an alternative is to implement in a compute shader to again avoid needing readable textures?
- if you know when you “no longer need the CPU data”, you can call tex.Apply with makeNoLongerReadable to discard the CPU memory … Just mentioning it in case it would be a viable way forward
Does any of this help you? Or am I missing details for your use-case?
Hi jonaskhalil,
thank you for your interest to help.
I use Graphics.CopyTexture to copy a Texture2D into a Texture3DArray, because it doesn’t require the source texture to be marked as readable and is quite fast.
The problem is that Graphics.CopyTexture doesn’t work when the “Load texture data on demand” project setting is enabled.
What I’m looking for is a way in the editor to make Graphics.CopyTexture work when “Load texture data on demand” is enabled. My idea why that happens was that perhaps the texture data isn’t loaded when I call Graphics.CopyTexture, because it’s loaded on-demand only (perhaps even asynchronously).
I’m looking for a way to load the texture data synchronously to make Graphics.CopyTexture work (without altering any asset settings), even when the “Load texture data on demand” project setting is enabled.
Making every texture “isReadable” doesn’t sound like a great solution to me.
The code utilizes Graphics.CopyTexture that, according to the Unity documentation, performs the copy on the GPU.
Have you tried toggling Load on demand option right before doing your logic? It’s not in the API so I had to edit the config file itself in the build pre processor. In my experience it solves the problem most of the time.
The issue should be fixed in Unity 6, see Unity Issue Tracker - [CopyTexture][AsyncLoadInEditor] CopyTexture doesn't copy in Editor when 'Load texture data on demand' is enabled
Updating from 6.0.44 to 6.0.45 introduces this kind of bug with Unity related icons - TextMesh Pro, Cinemachine, Volumes ect. With this option turned on icon are just pixel mess and console’s spammed with erros “Texture of width 128 and height 128 is not accessible.” “Texture of width 64 and height 64 is not accessible.”
Turning off Load on demand option works fine for now.
Also broken in 6.1.0 and 6.1.1.
Please report this issue (“Help → Report a Bug…” in the Editor). If you have a project with a consistent reproduction, make sure to attach it to the report. Thanks!
Hi, Jonas.
Reported CASE IN-100599. New blank project, repeatable evety time.
1 Like