Search Unity

  1. Looking for a job or to hire someone for a project? Check out the re-opened job forums.
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Unity Feedback Wanted: Global Texture Import Size/Compression Overrides

Discussion in 'General Graphics' started by Aras, Jan 15, 2021.

  1. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,659
    Hi! So, importing textures often takes "forever" in a decent size project. We've been spending some time doing general optimizations for texture imports in 2021.x versions (see this thread), but here's another idea that would be good to get feedback on.

    My theory is that there are cases during production, where it's basically "I don't care if textures look slightly wrong or don't match the final look". If someone is a programmer investigating some physics bug, or an audio designer, or someone working on character controller, they probably don't care about exact look of the textures.

    Question: What if there was some easy way to globally (per-user, not affecting version-controlled import settings) to reduce imported texture resolution and/or turn off lengthy texture compression?

    A hypothetical place where this could be placed is, say, within the Build Settings window itself. Like this: texture-overrides.png
    by default it would not change any behavior, but within the overrides you can pick, for example:
    texture-overrides-maxsize.png
    texture-overrides-compression.png

    Some of this is somewhat similar to already existing "Compress Assets on Import" editor preference, that basically does the same as "Force Uncompressed" above (i.e. skips texture compression).

    The "Force Fast Compressor" above is where textures are still compressed (so they take the same amount of memory, load time, GPU performance), but sets the compressor itself to use "fast" compression mode, where it spends less effort trying to compress the texture. For some formats (ASTC, BC7 etc.) it's 5x-10x faster at doing the compression, at some expense of image quality.

    So the questions are:

    1. Does the above sound like a useful thing to have?
    2. Is Build Settings a good place where to put these settings in?
    3. Something else I haven't thought about?
     
    Last edited: Jan 15, 2021
  2. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,947
    1. Yes useful to have!
    2. Yes or project settings
    3. Extra option - Only compress textures used in build ( not all in project folder )

    I would use the faster way during development and only compress at full slow speed quality when starting the optimization phase.
     
    futurlab_xbox and AcidArrow like this.
  3. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    7,445
    Yes. Uncompressed but half res would be useful too (I guess uncompressed and something like max 512 is fine). The use case is "I just want to make a build NOW to check something unrelated / I need to show something at a presentation, and half of my textures aren't compressed yet". It happens surprisingly often.

    A Warning in the console when you're building with those overrides would be also prudent, since you also probably don't want to release something with these settings.

    (and / or make sure we can turn this off by code so when we click our "Prepare for final build" button we can make sure these are turned off)
    Yes.
    Another dropdown where I can override the compression format for iOS (like you can for Android).
     
    Lars-Steenhoff likes this.
  4. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,947
    Currently in quality settings there is also the option the half the texture resolution, just to keep in mind that it may be better to have all in one place.

    Perhaps a new quality setting for fast exports?
     
  5. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,651
    I like the "force fast compressor" option idea, as it only effects quality. The problem with setting a max texture size it is may kill LUT tables, and break all kinds of things that use them and expect them to contain exactly sized data. (This is, btw, one of my main issues with all of unity's texture scale settings, and why I never use them - there are issues with MicroSplat that happen if the user sets the project to half res textures and try's to pack the texture array- it ends up having one less mip with white in the last mip map). Could a texture have an "do not resize" flag? That would fix that issue both here and for my current use cases as well.

    Ideally Unity would be able to do things like this in sweeps on a background thread- so bring in all textures as fast as possible as a first pass, then go up a mip or two and do a second pass. The real problem here is the blocking nature of the editor, if this was fixed I wouldn't care if all textures were standard checkerboard patterns until compression was done, but I realize that's a larger task. But it is the right one to solve.
     
  6. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    7,445
    I believe the one in Quality setting still adds the full res texture in the build (and ram at runtime), but forces everything to ignore LOD0 and start at LOD1. (unless something changed)
     
  7. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,947
    Yes good good points Jason!
    The blocking is what stops us from doing any work during the compression stage.

    @AcidArrow Thanks I did not know that
     
  8. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,947
    As an example lets say I have a project with 100 GB uncompressed textures coming from various assets packs in order to kitbash together a prototype.

    Lets say I made a scene that uses 1 GB of textures coming from these packs.

    I set compression at import to none.

    What is taking the most time:

    1. compressing 100 GB of textures to a format that I will not use in the final
    build ( because default texture compression settings )

    2. Manually setting the right compression format for each texture

    3 Blocking the editor during compression

    4 Finding that one texture that is set at 8k exr and eating up all the storage in the build.

    @Peter77 Had a nice tool for 2 and 4, texture overview. I wish Unity would make a texture overview tool native so we can easy change many texture settings at once and easy sort by properties.
     
  9. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    7,445
    +All the textures from demo scenes in downloaded assets that I have spent so much time compressing over the years and they have never made it in a build.

    I do think this is an Asset Database feature/issue though, which is probably outside of the scope of what Aras is doing (and it's a bummer that we semi-recently had Asset Database v2 introduced, and really not that much has changed? all the issues and quirks are still there).
     
    Lars-Steenhoff likes this.
  10. xgonzal2

    xgonzal2

    Joined:
    Jul 3, 2012
    Posts:
    35
    My main problem with texture compression is that it blocks the entire editor like Jason said. If it could be done in an asynchronous way that alone could be a massive workflow improvement for me.

    I think if you guys had some sort of texture group settings similar to what Unreal has where you can specify global settings for the textures in that group would give us a little more control. Plus you could also do what you are proposing with the global settings you mentioned.

    For example, if I wanted to set a certain texture mipmap bias I currently have to write an asset importer and somehow identify the specific textures I want to modify whereas if I have a centralized location to specify a configuration for a group of textures kinda solves the problem neatly.
     
    Jes28 and Lars-Steenhoff like this.
  11. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,651
    Actually just the copy into the library folder is enough to make this time consuming.

    Having worked on projects with 18 hour import times (on a meticulously clean data tree, mind you), and contracted with companies with 8-12 hour import times, I can honestly say that in my opinion making this not a blocking operation is the #1 quality of life improvement that could be made to Unity. I hate having to charge someone a day's work because my computer is just sitting there importing a project filled will assets that they aren't even using, and I hate even more trying to convince the team that it's worth their time to clean up their project instead of focusing on whatever they are trying to get done. (Though to be honest I'd still be doing that if texture import times were not an issue).
     
    xgonzal2 and Lars-Steenhoff like this.
  12. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,651
    In theory one day some combination of UAS rule changes and the package manager would allow us to move those outside of the main packages, making them optional, which would be nice to decrease this burden.

    To be fair, this is because mipMapBias is not exposed on the Texture Import settings, which just seems like a funny oversight.

    But yes, Unity's texture importing/scaling stuff is anemic for most real world cases, as it will destroy LUTs and lacks any kind of fine detailed control. So no real project I've worked on has ever used it, and I think a lot of the hobby developers just use it because they don't understand performance and think they should half the texture res of everything "to increase framerate". It basically treats mobile as if we're all on iPhone 1's or 2's, not the wide ranging ecosystem it is today.

    So what happens to a 2048 texture which is set to max1024 with these new settings, and half res textures in the quality settings? Does it compress a 1024 version then drop the highest mip for rendering? What does its .mipMapCount and width/height return? I do a lot of texture packing in MicroSplat, and the texture size settings are on my configs, so it would scale the input to 2048 and output a texture array at that size (in a scriptable object, mind you, not the new texture array stuff added to 2021). Ideally, I'd prefer if my editor code could work with the original, uncompressed texture data, not from the data in the library folder. Then I would be unaffected by any of these settings, which can already cause issues that are hard for users to reason about.
     
    JoNax97 likes this.
  13. xgonzal2

    xgonzal2

    Joined:
    Jul 3, 2012
    Posts:
    35
    True enough but that detail has always bugged me so much and complicated things more than it should have.
     
  14. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,659
    Thanks for feedback so far! Answering all of them in one go:

    and
    These are being considered/designed by other folks as we speak, i.e. ability to set import settings not for each& every individual asset, but based on some "rules" (paths, folders, packages etc.). But that's a much larger/longer thing.

    and
    That one is also being worked on by other folks, i.e. both ability to import things "on demand" and "in the background", and also to import more than one asset in parallel, etc. But again, much larger/longer thing.

    This one is only a runtime setting, that does not affect import at all, and (mostly) does not affect the build (not 100% -- if all the quality settings that are included into the build say "half resolution textures", then it can drop the largest mip level).

    Yeah. Good question is, where/how would that be specified. Easiest one is adding some optional command line parameters that one can pass. Besides that... where these would be set? Somehow in the Hub UI?

    Yes.

    From what I remember, it was because some platforms (IIRC OpenGL ES and Metal) don't have such a concept in the sampler state. But my memory is fuzzy on this.

    Exactly the same as if you'd manually set it to max 1024 in the import setting today. In the build it would be 1024, then quality setting would make the largest mip be dropped at load time, so effectively it would become 512. Yes that's confusing to some extent, but is it more confusing than today? I mean today you have exact same thing with texture import max size setting & the runtime quality setting for "drop some mips", right?

    In any case -- if we had things like "import assets in the background" and/or "compress textures in the background", and/or "configurable import settings that are easier to setup across whole project than setting them for each asset", and/or "configurable build variants with setting overrides" or somesuch, then the above would most certainly not be needed. Most of what I mentioned here are being investigated or worked on by some folks at Unity, but all of these are "long projects". Whereas the above suggestion I literally have working on my computer today. So the question is, does it make sense to have this small improvement, that likely will get obsoleted in Some Years by better systems.
     
    mariandev and JoNax97 like this.
  15. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    7,445
    This drop down has plenty of space, but it could also be part of Advanced Project Settings?

    Screenshot 2021-01-15 at 10.19.24 PM.png

    Also this is slightly off topic, but the "Compress Assets on Import" preference should be changeable from the hub as well, since if it's On, I either have to suffer the whole project compressing, or I have to create a new dummy project (or have one around), go to preferences, close that, open the project I actually want.
     
    Lars-Steenhoff likes this.
  16. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,947
    Yes it is a welcome option!
     
  17. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    7,445
    I haven't tried on Metal, but bias definitely works on GL ES 2.0 and above (not sure about 1.0, and I'm fairly sure it works on metal, but I haven't actually tried it). Also... maybe on platforms that the settings does nothing, then it does nothing, not sure why that prevents something from being in the importer :)
     
  18. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    9,836
    A "nice to have" feature would be if using Force Uncompressed would use a dynamically calculated per texture max size to prevent exceeding the memory usage of the intended compressed settings for that texture. So, for example, a 512x512 DXT5 or ASTC 4x4 would end up as a 256x256 RGBA32, 512x512 DXT1 or (RGB) ASTC 6x6 would be a 128x128 RGB24. Not perfectly like for like, but on memory constrained platforms or projects pushing limits, this would be exceedingly more useful than global clamps. Especially since it wouldn't impact any already uncompressed textures. Those generally don't require significant import times (ignoring convolved cube maps, which maybe need a separate option?).
     
    hippocoder likes this.
  19. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,651
    I guess my vote then would be to add the texture compression quality option and not the max size option, if anything at all. I guess it depends on the timeline; I hate putting in stuff that's just going to go away, because I'm always working across 2-3 years of unity versions, and then you end up with tons of #if UNITY_X all over the place to handle stuff.
     
    hippocoder likes this.
  20. Kleptine

    Kleptine

    Joined:
    Dec 23, 2013
    Posts:
    119
    It would be nice to have some way to set this as a profile. One thing that's important for me is to make it easy to kick out a build with production settings, and not have to re-make the build because you forgot you had the wrong texture settings.

    This might be a larger change, though. It'd just be nice to be able to define a build profile that had arbitrary modifications to Project Settings. :)
    - Debug (Mono-512textures)
    - Production (IL2CPP-maxcompression)
     
    bgolus likes this.
  21. slime73

    slime73

    Joined:
    May 14, 2017
    Posts:
    70
    One thing I'd like is a "Force Disable Crunch" option. In a large project I work on we've gone through multiple project cycles where we turn crunch compression on for several thousand textures when we first start making final release builds for testing "1.0" of that game, and then we turn it back off when starting production of the next iteration of the game because import times would skyrocket if we left it on outside of the weeks/months of bug fixing time. We also don't want texture quality to be worse in the editor than when we ship the game so we probably wouldn't use a 'force fast / low quality compression' option.

    It sounds like this sort of override feature would be a good fit for that situation, where we could just turn it off without messing with thousands of texture import settings / meta files - ideally in an 'override settings' file that can be put into version control along with the rest of the project.

    Maybe there could be a project-wide override and then a user-specific override which takes precedence, similar to the Cache Server / Accelerator enable settings.
     
    Last edited: Jan 15, 2021
    futurlab_xbox likes this.
  22. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,890
    This suits me.
     
  23. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    601
    To be honest, marginally. Considering the first time you're importing any large project is going to take a lot of time anyway its not really for that case, we suggest everyone does that overnight since its a one-time-thing.

    So the use case is when a lot of textures are comitted, which for us at least doesnt really happen all that often. An artist might commit a lot of textures at once initially, and then iterates on one texture individually.

    I personally dont think i spend that much time waiting for texture imports after updating SVN, there are plenty of other, imo more urgent, bottlenecks. Such as the long time it takes to enter playmode, script compilation being slow, general startup times etc. I do these actions far more often than i have to import textures so even a smaller gain there has more impact. Luckily a lot of that is being worked on.
     
    Last edited: Jan 16, 2021
    TheSecretGordon likes this.
  24. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,659
    Yes, that's the "configurable build settings" thing I already mentioned above; this is being worked on, but it's in a "timelines are long or uncertain" stage.
     
    Kleptine likes this.
  25. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,337
    For us, the time this would be useful is when we get somebody external on the project (usually sound person) that needs to open it to work on something that's unrelated to graphics. In that case, it would be nice if they could specify on their first import that they're fine with low quality textures.

    It gets old to tell them "hey, you need to leave your laptop in a useless state for like 12+ hours in order to be able to work on our project".

    That being said, that stops being a problem once on-demand imports of assets becomes a thing, so the usefulness of the feature very much depends on how long it takes before on-demand imports arrive.


    Would this be relevant for builds at all? I guess if you're creating a build for a different platform?
     
    futurlab_xbox likes this.
  26. Hyp-X

    Hyp-X

    Joined:
    Jun 24, 2015
    Posts:
    384
    This would only be useful if it is a big time saver.
    As I understand for example in our case Texture importer is bottlenecked by the PNG reader. :(

    But for people who bottlenecked by the texture compression the best would be a mode that:
    - Has a simple checkbox (on/off)
    - Doesn't change the texture size (that can break things)
    - Doesn't change the texture format (that can break things)

    What it could change is:
    - Fall back to the fastest resize/mipmap filter available
    - Disable crunch (as somebody already suggested above)
    - Use a super fast version of the texture compressor

    All texture compressors can be sped up at least an order of magnitude if you don't want the best quality.
    Most of these should be already available in libraries or relatively trivial to write.
     
  27. Hyp-X

    Hyp-X

    Joined:
    Jun 24, 2015
    Posts:
    384
    Just found this on PNG decoding speed:
    https://github.com/putara/pngbench
    Not sure how useful this is for Unity as you need a cross platform solution (I only use the editor on Windows so a Windows only speedup would be very welcome...)
     
  28. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,659
    It does apply to builds, i.e. it's literally the same as if you went through all your textures and changed max. size on them, or set compressor to fastest mode, etc. So if for example you reduce the imported sizes globally this way, and then make a build, then (to some extent) the build also gets made faster, is deployed faster, possibly loads faster on the device etc.
     
  29. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,659
    That's exactly what's in the above proposal as one of the options ("Force Fast Compressor"). It does not apply to all the formats, but yes, to the slow compression formats that is the case (e.g. DXT1/DXT5 compression does not have a "fast" mode, but then, it's already really fast anyway).
     
  30. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    676
    It will be good to have texture format override per platform, e.g. on iOS and Android I want all textures to be ASTC compressed not ETC or PVRTC. Option to override compression from something to ASTC (without touching uncompressed textures, just touch compressed with another format)
     
    hippocoder and Lars-Steenhoff like this.
  31. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,659
    That already exists on Android (texture subtarget) since forever. I think mobile folks are looking at doing something similar for iOS too.
     
  32. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    676
    Yes it need for iOS too and for android I can only set ASTC but can not set witch ASTC to use, and better to have few options like for ui use ASTC 4x4 for everyting else ASTC 6x6

    Another thing is to have one format for all Arm platforms (ASTC) and another one for all other platform (DXT) just because today many project want to use ASTC LDR for all ARM platforms (dont want to set same texture setting for every platform) and may be even dont create build for older phones.

    Minimal help can be just checkbox to use Android texture setting for iOS so we can just setup Android platform settings and iOS will take it.
     
    hippocoder and Lars-Steenhoff like this.
  33. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,890
    I just need really high quality for some VR mobile devices which means more ASTC options. As I understand it, the current compressor / setup isn't as high quality as it could be...
     
  34. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,659
    What makes you think that?
     
    hippocoder likes this.
  35. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,890
    Back when I was doing builds I couldn't specify the block sizes I wanted and ended up with a slightly uglier image vs the standalone compressor. This was a year ago and much could have changed. I will get back to you once I've done current-day tests.

    Anyone else chime in with ASTC?
     
  36. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,651
    I've had it crash Unity a lot on the mac, at least when compressing Texture Arrays. But this reminds me, now that there is a proper texture array workflow coming, is it possible to compress into a texture array and not have unity complain about the format? Essentially, the old workflow is to compress texture arrays and save them into a scriptable object- and if your, say, targeting a platform that uses ETC2, you'll get a massive stream of errors complaining that the format is not supported - because it isn't for the PC your compressing them on.
     
  37. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,659
    You mean with a scriptable object approach, or "just have a regular image file with array slices next to each other"? The latter should work the same way as any other regular texture - you can specify import settings, formats etc. per platform, and so on.
     
  38. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,659
    Some update (see original message in this thread) on what "keep everything the same, just use Fast texture compression mode" means with import times. Here I'm importing all the textures in "Book of the Dead: Environment" project of ours (~2GB of source texture file data, 400+ textures).

    This includes general speedups done for 2021.1 (see other thread), as well as some that are for 2021.2. But the last two entries in each group are:
    • Blue: default settings as specified by all the texture import settings,
    • Green: override to use "Fast" compressor for all compressed textures. All the texture formats, dimensions, memory usage etc. etc. all stay the same, "just" they have slightly lower quality pixels (i.e. more compression artifacts). But look at these import time savings, especially for mobile formats!
    Book of the Dead Environment texture import times, in seconds (1).png
     
    jbooth, hippocoder, Peter77 and 3 others like this.
  39. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,651
    ok, let me give the complete picture. MicroSplat takes a list of textures, extracts all the data from them and then packs them into custom layouts stored in texture array scriptable objects. Essentially, most users don't understand texture packing, and the best formats are rather funky anyway, so I handle it all for them. This has a few issues. Imagine we’re on Android and compressing to ETC2:

    1. since the editor is on windows, the textures are likely in DXT format. So we end up loading the DXT compressed source instead of an uncompressed texture, with all the DXT crappiness.
    2. After we create the texture in memory, we call the editors compress function to compress it into ETC2 format. Since the editor is on windows, it throws a warning about not supporting ETC2 for every texture we are creating as we copy them into the arrays.


    So basically, I’d love a way around both of these, so I could get higher quality source data without having to muck with the import settings of 100 textures, get access to the higher compression/mip map options of the importer, and also not spam the console with warnings. Preferably I also wouldn’t litter the project with a bunch of files, either, and would properly handle storing this data in the library in platform format.
     
    Last edited: Feb 10, 2021
unityunity