Xnconvert mipmaps drivers#
Xnconvert mipmaps Pc#
Xnconvert mipmaps plus#

Honestly what you probably want to look at is something like Basis. ASTC has variable block sizes, with a ASTC 6圆 looking better, and having an overall higher compression ratio than ETC1 (roughly 6.75:1 for 24bit RGB, nearly 9:1 for 32bit RGBA!), but may potentially be slightly slower to render due to the additional cache usage. ETC1 textures are small (6:1 compression vs a 24bit RGB source), but have more obvious compression artifacts. (Well, maybe the latest Apple hardware, but they, or really most mobile GPUs, don't support DXTC formats.)įor the Quest you should be using ASTC, or ETC1 textures. This will include all mobile hardware, since none of them have the computation power to encode to DXTC formats in real time. So plenty of devices out there can accurately say they have support for both extensions, but will throw an exception if you try to tell it to generate mipmaps for a compressed texture. It should also take more time to generate those mips and recompress than to just load precomputed mipmaps unless you're on a slow network connection.

Xnconvert mipmaps drivers#

The fact that desktop drivers do allow for automatic mipmap generation and runtime recompression of DXTC textures is outside of the spec. There's no interaction between the two extensions in their spec, nor any comments about the later allowing for runtime compression to those formats. GL_EXT_texture_compression_s3tc is explicitly only for loading and decompressing DXTC format textures of the types DXT1, DXT3, and DXT5. GL_SGIS_generate_mipmaps is explicitly only for handling uncompressed textures. Is it going to be faster than what you can generate in Unity? Probably. For Direct3D the spec actually defines what formats can be used, and any compressed textures are supposed to fail silently(!?), though I suspect it'll work there too for DXT1 & DXT5, at least for non-mobile Direct3D.īut yes, this is happening fully on the CPU, not the GPU. On Desktop, AMD & Nvidia will certainly accept DXT1/5 textures. I've heard some Mali devices will accept ETC1 textures, but that's a fairly simply format so it's plausible to do real time compression of those on a mobile device (but it's still going to be pretty slow).

Xnconvert mipmaps Pc#

Something like ASTC takes a beefy desktop PC several seconds to minutes(!) to compress, so there's no way a mobile GPU can do it. Textures that are imported by Unity in the editor, or when calling tex.Compress() will generate the mipmaps on the CPU as part of the import and compression rather than on the GPU to ensure the CPU side has access to those mipmaps for storage & optional script level access.ĪFAIK if you try to upload a compressed texture and ask for automatic mipmap generation on a mobile device you'll either get an error, black mipmaps, or an uncompressed texture.

Xnconvert mipmaps plus#

Plus you really don't want to be generating mips from the compressed image, only from the uncompressed source, otherwise any compression artifacts will be amplified.

GPUs hardware cannot generate mipmaps for compressed textures since GPUs don't have built in acceleration for re-compressing those textures and all mips must be using the same format as the top mip. Texture2DArray, Texture3D, and CubeMap all have similar setups.įor a RenderTexture, this is set by if mipmaps and auto generation are both enabled.Ĭompressed textures are different though. Automatic, hardware generated mipmaps is enabled by default for all dynamically created uncompressed textures.įor a Texture2D, if the texture has mipmaps enabled (controlled by the Texture2D constructor), calling tex.Apply() on them to upload the texture to the GPU automatically generates the mipmaps on the hardware.