что такое astc texture

Using ASTC Texture Compression for Game Assets

Since the dawn of the GPU, developers have been trying to cram bigger and better textures into memory. Sometimes that is accomplished with more RAM but more often it is achieved with native support for compressed texture formats. The objective of texture compression is to reduce data size, while minimizing impact on visual quality.

Table of Contents [show/hide]

With the flood of mobile devices came even more urgency to use texture compression. Memory was typically shared with the CPU and thus even more of a scarce resource. In addition, mobile data networks were slow, and storage in the device was small, so smaller data over the wire was important.

Also important to the mobile space is power use. For textures, there are many places where smaller data saves power: reading from storage, any unpack/unzip or transcode step, writing data to memory, and reading that data during rendering.

This guide aims to provide developers with the following:

The overall goal is to assist developers in achieving their desired balance between image quality and texture size. In addition, at the end is a more detailed walk through of some real-world compression testing results.

Quick Guide to Converting Assets to ASTC

For developers who want to «get right to it», consider the general guidance below to try first when targeting the latest GPU hardware. This jumps ahead of the discussion in the following chapters, and describes one possible approach to immediately leverage ASTC for your base of assets.

Figure 1: Example of ASTC block compression
(Click for larger version)

Take your textures, and separate them into groups of similar content based on the content categories in the next section. For each category choose if you want:

Note: although many of the tools use the term «best compression» we avoid it as it is easily overloaded. The best compression might mean the highest compression levels and lowest bit rates, but with too many artifacts. That said, you may find content which «tolerates» highest compression well, or decide that smaller size is more important than the resulting artifacts. Experiment with increased compression when time permits.

This is only a «quick start guide». You must evaluate your particular needs, desires, and content. It is a starting point from which you can decide to further increase or decrease compression levels to hit your desired balance of size and quality.

One last note: ASTC compression takes time for best results. DXT tools might run 2-10x faster. On the plus side, ASTC tools are 4-20x faster than its closest competitor, ETC2, for production output. ASTC can run in faster modes, generating lower quality results in short times, when you are testing and don’t yet need or want production quality.

Modes to Try Based on Content

In each case below, «Higher» quality should be less than or equal to the file size of DXT but significantly better image quality. This is especially the case if previously you have avoided using DXT on specific assets; you might now try ASTC formats vs leaving the assets uncompressed.

The following suggestions are based on the ARM «astcenc.exe» command line tool in «thorough» mode to ASTC-compress a small set of test assets at different bit rates.

RGB (24b, diffuse maps)

ARGB (32b, diffuse with alpha)

Normal Map (16b, possibly also RG/LA maps)

Single Channel (8b, possibly detail/light/AO map)

Compressed Texture Formats

S3TC/DXTn/BCn

In the modern desktop computing age, there has classically been one answer to texture compression: DXT. It is also referred to as S3TC due to its origin, or BCn for certain DirectX implementations. At its most basic, it is a fixed 4×4 block format that uses 4bpp to encode each RGB block. To store alpha information, there is either 1-bit alpha (using 1bpp of the encoding space), or a second 4bpp alpha-only block for high quality alpha encoding. There have been later variants of this approach that store LA or RG data in two separate 4bpp blocks, for better quality.

In the mobile space, NVIDIA is one of the few vendors enabling easy porting of desktop content to devices, with its support for DXT in the Tegra processors. Other mobile chip vendors created other compression formats.

PVRTC/PVRTC2

Imagination develops the PowerVR GPU and created a proprietary PVRTC texture compression format. It is well known for its use on iOS devices for texture compression. It offers both 4 and 2bpp options for greater reduction in size. More recently Imagination has released the PVRTC2 formats, which offer better compression quality in the same footprint.

ETC/ETC2

To avoid the myriad vendor-specific codecs, Khronos defined vendor-neutral codecs. With the introduction of OpenGL ES 2.0, the ETC compression format became an available multi-vendor extension, offering DXT-like compression at better quality levels. However, it had issues that hampered its widespread adoption: it was not a required piece of ES 2.0, there was no alpha support, and it had only one mode, 4bpp RGB.

With the release of OpenGL ES 3.0 in 2013 (and full OpenGL 4.3), the ETC2 format became a standard, with backwards compatibility and important new features. First, it added full alpha support like DXT3/5 (in 8bpp), as well as 1-bit «punch-through» alpha (in 4bpp). Second, it brought the EAC format, which supports 1 and 2-channel data (R and RG, in 4 and 8bpp respectively). Third, it added sRGB data support. And last but not least, it claimed to offer better quality than competitors at the same bitrate. The biggest issue with ETC2 are complaints about its extremely slow compression tools.

And Then Came ASTC

In parallel to Khronos defining OpenGL ES 3.0, there was an effort to develop an industry-leading compression format that provided developers with finer grained control. This resulted in the mid-2012 launch of the ASTC texture compression format. The key to ASTC is that while it uses a fixed 128 bits-per-block, each texture can have a different size block fit in those 128 bits, unlike the fixed 4×4 block of prior formats. Leveraging a large variety of square and non-square block sizes, ASTC delivers a wide range of derived compression ratios, scaling from 8bpp down to just under 1bpp, as follows:

Thus, ASTC offers a huge advantage of tuning quality vs size. The alternative formats generally offer 4bpp for RGB or single channel data, some can fit alpha in that footprint, some offer higher quality alpha or a second single channel data block in a second 4bpp section. PVRTC is the other to offer a smaller variant, with its 2bpp mode.

In addition, ASTC offers support for 1-4 channels, including full alpha RGBA, normal RGB, 2-channel RG (LA), and 1-channel R (L/A) support, and custom X+Y and XY+Z normal map support. The net result being ASTC handles most types of texture.

One other key advantage of ASTC is that the method of encoding endpoints, weighting, etc. is selected per-block rather than globally, so the encoder can adapt on the fly to allocate the 128 bits to better represent the contents in each block. This delivers better image quality than previous formats, even at higher compression.

Hardware supporting ASTC has achieved sufficient enough market share that developers should seriously consider how to leverage it in their titles: to improve quality, decrease storage size, or both. This is especially true in titles that require a high enough level of graphics hardware such that ASTC is a given.

An Approach to Compressing Assets

For your product, you need to decide overall, as well as per asset, whether quality (vs the raw asset) or shrinking the file size is most important. More than likely, you will pick something in between. You should have at least a high design goal in mind for your project before starting to look at individual textures.

Finding the Best Format

With so many texture compression standards and tools, how to find the best match for each texture seems a bit daunting for existing large-scale projects.

Don’t Forget Screen Size

Historically, developers would either target larger desktop screens or smaller mobile screens. Today, you must think carefully about your market. While many phones are higher and higher resolution, the visual impact of extremely high resolution textures may be small. However, with the addition of HDMI, you could be running on a 50″ 1080P television, where pixels are large once again.

Developers porting to mobile devices may immediately look to cut down texture resolution first as a space saving method. But before you shrink the resolution of your textures, consider modern device screens. Then consider whether you want to use higher compression on larger textures where artifacts might be noticed less, or go with lower resolution and lower compression with fewer visual issues: a drop in resolution means 1/4 the data, but could lose key detail. In striking a balance, you might push for lower bit rates and be more flexible with what artifacts you are willing to accept.

Reducing File Size Further

File size is critical with modern content that can be a gigabyte or more in size. Thus the on-the-wire, on-disk and in RAM sizes are all key. How can we deal with these topics?

Transcoding

One alternate method that has been used in the industry is to compress assets with something like JPEG, tuning for a particular file-size reduction and trying to not trade off much quality. Assets are sent over the wire in that form, and transcoded to the optimal GPU format for the device either at first run or on-demand. That is a reasonable approach on desktop platforms, but on mobile devices the transcode can be more costly in time and battery. Plus there are additional, possibly undesirable, quality issues both starting with JPEG and resulting from a speed-tuned «fast encoder».

With the coming of ASTC, developers now have a wider range of compression bit rates, and should evaluate dropping ASTC bit rate (and quality) on assets before considering adding significant extra complexity with a secondary encoding tools and loading/transcoding process.

Packaging

A second approach is to experiment with different content packaging of post-codec content. Some presentations have noted better-than-JPEG sizes achieved using ZIP or LZW compression as a second pass. Decompression on the client is still required but it should be an order of magnitude or two faster than any transcoding process.

In quick testing, we used a tiny set of example ASTC textures (the same used in the next chapter) and compressed them with standard ZIP compression. The result was compelling: just over 20MB of total texture data was reduced to a 9MB zip file.

Assuming you pick texture compression that fits into memory limits well enough, layering standard compression on top can make a difference in both on-the-wire transmission bandwidth as well as on-disk storage. So this is a new wrinkle to factor in: if you can push compression enough to fit your RAM footprint, you may be able to use LZW or ZIP as a final step to achieve file size goals.

Example Compression Testing

To better discuss the effects of different codecs on content, we performed a batch compression run against a small set of textures and assigned a visual image quality (IQ) rating to each. We then considered which compression format seemed best for quality, gave a balance of quality and compression, or delivered a higher level of compression without resulting in extreme artifacts.

In this section we present tables of the acquired data along with some samples of the resulting textures using two of the tested codec variants. The presented textures show the same region under a high zoom to provide a direct visual comparison of the different compression methods.

The tables provide the details and evaluation of the batch runs on each texture for each of the tested compressors. The data includes: the image quality rating for each codec, some brief notes as to the rating (where comparisons are drawn to the original/raw image), and information on each codec in terms of bits per pixel and improved size if we were to compare to some base/assumed DXT format compression.

Источник

Русские Блоги

ASTC textures

ASTC textures

This document describes usage of compressed ASTC textures.

Introduction

This tutorial shows how Adaptive Scalable Texture Compression (ASTC) can be easily used in simple scene, which is a textured sphere spinning in 3D space. It simulates an earth globe lighted from one side with a camera zooming in and out on its surface.

In order to use ASTC formats you need to run your application on hardware which supports corresponding OpenGL ES extension(s):

Otherwise, you will be getting messages about invalid format/internalformat passing through glCompressedTex* function to underlying graphics driver.

What is ASTC?

The ASTC algorithm represents a group of lossy block-based compressed texture image formats. For information on why texture compression is needed see chapter Why use texture compression? Two and three dimensional textures may be encoded using low or heigh dynamic range. In this demonstrating example we take under consideration only 2D, LDR textures. Basic concept of encoding relies on division the compressed image into a number of blocks with a uniform size. Each block is stored with a fixed 16-bytes footprint, regardless of the block’s dimensions. That’s why it can represent a varying number of texels and bit rate is determined by block size (see below table), which allows content developers to fine-tune the tradeoff of space against quality.

ASTC offers also support for 1 to 4 color channels, together with modes for uncorrelated channels for use in mask textures and normal maps. Decoding one texel requires data from a single block only, which highly simplifies cache design, reduces bandwidth and improves encoder throughput. Despite this, ASTC achieves peak signal-to-noise ratios (PSNR) better than or comparable to existing texture compression algorithms (e.g. ETC1/ETC2).

​ For more details on ASTC algorithm visit 1

Texture preview

You can preview and analyse your texture image how it looks like after decompression using Texture Compression Tool (TCT):

Download and install TCT from 2

Open your existing image file.

Specify compression options in the ASTC tab which appears after pressing F7.

Confirm compression set up with OK. Preview is generated automatically.

Texture encoding

You can compress your texture image to ASTC format using command line interface:

Download and install ASTC evaluation codec from 3

Compress you input image file to ASTC format using following syntax:

​ For more information on how to use ASTC encoder just type:astcenc.exe

Texture loading

In this sample sphere is covered with color that is result of combining colors from three texture units: cloud and gloss unit, day time unit and night time unit. Hence, firstly all compressed ASTC textures have to be decoded and specified for targets in order to generate texture bindings that will be next bound to particular texture units. For doing it load_texture() function is responsible, which follows the steps:

After a new texture ID has been generated texture object can be bound to target. Then, compressed data may be passed to driver.

Texture updating

Once we have got all texture bindings for GL_TEXTURE_2D target we are able to use and switch them at our convenience. It’s a job of update_texture_bindings() function.

In each 5 sec texture bindings for texture units are refreshed following block size order from the table in section What is ASTC?

Visual output

You should see visual output similar to:

Appendix: Mesh data flow

Generating vertex positions, texture coordinates and normal vectors is implemented based on spherical coordinate system. All mesh data are produced by solid sphere constructor.

User is responsible for passing radius, number of rings (parallels) and sectors (meridians) to the constructor. It computes coordinates for each vertex according to formulas:

Texture coordinates indicating how to map an image onto mesh primitives are precisely covered in section Load Texture Function

Solid sphere constructor is also responsible for generating indices required for glDrawElements function. It has been assumed that each four vertices form two triangle primitives ( GL_TRIANGLES mode), so glDrawElements call needs six vertex indices to construct them:

In the next step generated vertex positions, normals and texture coordinates are loaded into buffer object.

After the above listing has executed, bo_id contains the unique ID of a buffer object that has been initialized to represent buffer_total_size bytes of storage. Passing GL_ARRAY_BUFFER as a binding point to refer to the buffer object suggests to OpenGL ES that we are about to put data in order to feed vertex attributes. Expected usage pattern of the data store is set to GL_STATIC_DRAW which signalizes graphics driver that buffer content will be set once, but used frequently for drawing.

Then, place the mesh data into the buffer object at the corresponding offsets:

Note
In this step the data are copied from a local memory storage to update buffer object’s content. Immediately after this, memory pointed by the sphere_vertices, sphere_normals and sphere_texcoords pointers may be freed.

Before we can go on, let’s create a vertex array object to store vertex array state.

Once it is generated and bound, we are able to fill in its content. The goal is to determine OpenGL ES to connect vertex attributes values directly with the data stored in the supplied buffer object.

Automatic filling of the attributes is enabled with glEnableVertexAttribArray calls. Next, we have to inform graphics driver where the data is and turn on vertex fetching for all attributes. Whereas a non-zero buffer is currently bound to the GL_ARRAY_BUFFER target, last argument in glVertexAttribPointer function specifies an offset in the data store of that buffer.

Sphere lighting

This sample uses Phong lighting model which has been explained in details in section Lighting

Источник