koobas.hobune.stream
What are possible causes and solutions to randomly garbled textures on standalone builds?
Our game has been randomly garbling textures on standalone builds, but not during play-in-editor. We've seen this affect TextMeshPro fonts, GAF-based character sprites in our overworld, and Unity UI images. Seemingly any texture is susceptible to it.
The repro for this is really odd. If I make a build starting at our main menu and transition into the game world from there, lots of things get garbled, text included. If I rearrange the scenes so that the player starts directly inside that first scene, nothing gets garbled. When we repro it by transitioning in from the main menu, the same objects/textures will always be garbled in the same way. We have found more than one way to reproduce this bug, but it's most severe when we come out of our main menu.
We do not know how what gets garbled and what doesn't get garbled is determined, but we have found that changing the font asset for our text does have a chance to work in not garbling the text. I say a chance because some fonts will garble, and some fonts won't. Deleting and re-making the fonts that get garbled does not fix the garbling.
Things that we've checked:
- No errors occur in the console. There are no null refs, there are no missing reference exceptions, nothing indicates where or what might be failing.
- We aren't hitting the 4 GB texture limit yet. As it sits we only have 2 GB total in the Assets folder, and only about 0.56 GB of that is textures.
- We aren't using Resources to load in anything. All our characters are pre-placed. GAF does make use of a lot of resources folders itself, in a way that is black-boxed off and untouchable, but our text and our UI definitely do not.
- We have not yet tried separating assets into Asset Packages. It's during the process of looking into them that we found out how little space our assets were actually taking up.
- We've disabled every instance of async scene loading in favor of traditional loading.
- We aren't using the legacy sprite packer.
- The garbling happens on DirectX and OpenGL alike.
- The garbling is not dependent on hardware -- everybody's computer produces the same effect in the same places.
- Our texture memory load hovers consistently at around 1.4 GB from scene to scene, and this accounts for the majority of our memory use. It doesn't seem to grow with subsequent scene loads, and it shrinks accordingly when we hit scenes with lower counts of characters or less complex environments.
- No serious processing problems are indicated in the profiler, and performance is otherwise really, really smooth. The game is, apart from this texture problem, playable.
- Using quality settings to reduce texture sizes universally by half does not change anything, including the texture memory usage.
- Deleting large amounts of assets reduces the chance of textures getting garbled in the build.
- Deleting and re-creating assets on an individual level does not fix or change the issue, whether it's one texture or the entire asset wrapped around it.
- Migrating to a newer version of Unity does not fix the issue; this problem crops up just as easily on 2019 builds as it does on 2017 builds.
The more we investigate this, the more mysterious the issue seems to get and the less certain we feel about the nature of it. It presents almost consistently with the garbled textures from exceeding 4 GB of texture resources, but again, we haven't even got 4 GB of assets in the first place. Nothing else graphics-related seems to affect this issue.
So! Anybody encounter something similar to this? I'm going to keep trying things, but if anybody's worked on a game with a sizeable number of 2D assets and feels like they've seen this before, I'd very much appreciate help or suggestions!
Update: Altering the max texture size on our game's files caused the bug's presentation to change. Originally our max texture size was defaulted to 4096, which is way larger than the native size of any of these textures, but I went through and systematically reduced them to something that fit more closely. A few I went ahead and reduced below their native resolution. Upon building, the same characters still get garbled, but the garbling is different now.
Not completely sure what this tells me, but I'll strip some unnecessary textures and see what happens next.
Update: After removing a bunch of unnecessary textures from much earlier in the project, using the search feature for t:texture in the Project browser yielded a lot of textures that were previously omitted. I thought it was my imagination at first, but it seems like if you have beyond a certain number of textures it'll just ignore some of them. I don't understand what rationale the Project browser uses to cut off certain textures from the search results, but it's definitely not alphabetical.
If the system for referencing assets on a standalone build functions similarly to this then it seems like having beyond a certain number of textures might lead to broken references? That doesn't make sense of the fact that the textures are fine on the first scene that gets loaded, so I'm pretty skeptical, but I'm going to keep cleaning house and see what happens.
After deleting a lot of old textures from back when we were using 2D toolkit as our main sprite animation package, we got our characters back.
Several UI elements and fonts still garble, but the impact on them has been dramatically reduced. There seems to be a correlation between what gets garbled and what doesn't appear in the search feature. If this issue is related to the 4 GB texture limit, then asset packages will be viable for this use case as well -- though I want to emphasize that the amount of textures we deleted only amounted to about 120 megs.
Still, getting closer.
After a lot of investigation and conjecture, we finally bothered to look at the Build Report in the log. It shows that textures are taking up a whopping 5911.9 mb, or 5.9 gigabytes -- which puts us over the 4 GB texture limit. It might not be that big in the Assets folder, but uncompressed at build time apparently it is. Our solution will therefore be employing asset packages.
