Compressed Stage3D Textures With ATF
Adobe has recently released tools to allow us to use compressed textures with the
Stage3D API via their ATF tools. What are these compressed textures? Why would we want to use them? How do they work? Today’s article is an overview of compressed textures covering these questions and more.
Let’s start with the uncompressed textures we’ve been using using
Stage3D was released with Flash Player 11 over a year ago. It would seem that if we are loading a PNG or JPEG image to use as a texture that it is already compressed by their respective algorithms. Well, GPUs don’t know anything about the PNG or JPEG file formats and won’t allow you to use them directly. So when we upload uncompressed textures we’re always uploading them via
Texture.uploadFromBitmapData. This means that the PNG or JPEG file has already been uncompressed into a
BitmapData and we are uploading the full, uncompressed RGBA pixels to the GPU. There are many problems with this.
The first problem is that uncompressed textures take up a lot of precious GPU memory: VRAM. Typical VRAM sizes range from about 64 MB up to 1 GB and potentially more for high-end computers. In comparison, system RAM is typically at least 2 GB and often up to 8 GB and beyond. So VRAM should be conserved as much as possible. Unfortunately, an uncompressed texture takes up
width * height * 4 bytes of VRAM. For example, a 512×512 texture for a character takes up 1 MB. A 2048×2048 texture takes up 16 MB! A low-end computer with 64 MB of VRAM couldn’t even handle four of these.
A related problem is that uploading data to the GPU means that it has to be transfered from system RAM to VRAM. This upload involves a copy across the video bus, which may be a slow channel like AGP. When your textures are large, this upload process takes longer.
A final problem is that uncompressed textures can cause your rendering to be slower by increasing the working data set used during any single draw call:
Context3D.drawTriangles. Smaller textures will typically perform better for this reason, but compressed textures will reduce the size of the data set just as well.
Well this all sounds great, but are there any downsides? Well, for starters you need to convert your images from “normal” file formats like PNG and JPEG to the all-new ATF (Adobe Texture Format) file format. This will add a step in your art production pipeline and the result will be a file format that isn’t recognized by most programs. You won’t get previews in Windows Explorer or Apple Finder. You can’t open them in Photoshop or Gimp. About the only program that can show you what they look like is Adobe’s own ATF Viewer, which comes with the ATF tools.
Another downside is that they’re pretty opaque to your AS3 code. You load them up as a binary blog (
ByteArray) and upload them to the GPU with
Texture.uploadFromByteArray. If you want to inspect them to see simple attributes like the width and height, you need to parse the
ByteArray yourself via the ATF file format specification included with the ATF tools. This is obviously much less convenient than dealing with a
BitmapData. You also can’t display them on the regular 2D
Stage via a
Bitmap. Your AS3 code can’t read their pixel data or, perhaps worse, change it. Your AS3 code is meant to be a simple middle man: just load the binary blog and pass it to the GPU.
One final problem is that the ATF files will often be larger than the equivalent PNG or JPEG textures. As noted above, this will not be the case when the uncompressed textures are stored on the GPU. This means that ATF represents a tradeoff where file size (and load time) go up but VRAM usage goes down.
Are these limitations worth the benefits? Only you can decide for your own application. In a lot of cases, yes they are worth it! Huge swaths of your 3D scene can easily be textured with ATFs. In strange cases where you’re generating textures with AS3, you won’t be able to make ATFs on-the-fly, but this can hopefully be kept to a minimum. For most textures you will want to take advantage of the (typical) 8:1 compression ratios you can get on a GPU with ATF.
For more information, check out the ByteArray.org post, download the ATF tools, and start playing around with compressed textures!
#1 by AlexG on November 5th, 2012 ·
So using ATF we can increase very much the quality of graphics?
By the way, it would be great to have a system of email notifications of comments response.
#2 by jackson on November 5th, 2012 ·
Well, you can have a lot more textures in your scene so that would naturally lead to bigger, more complex scenes. Or you could just have much higher (e.g. 8x) more pixels in each texture with your existing scene. Both really help out the quality of graphics.
There isn’t any e-mail for comments, but you can subscribe to a feed with the button next to the “Comments” heading. This one is for today’s article. I’ll see what I can do about an e-mail…
#3 by AlexG on November 12th, 2012 ·
Thanks. I see the RSS for comments. Is it for this article comments or this RSS is for comments from entire site?
#4 by jackson on November 12th, 2012 ·
Just this article. I checked the feed and there are only three comments in it. Once I post this there will be four. :)
#5 by i.o. on December 2nd, 2012 ·
Could you post little live ATF texture example in pure Stage3d?
I just have some troubles with that because usual BGRA texture uploaded from BitmapData working fine. But ATF texture (COMPRESSED or COMPRESSED_ALPHA) uploaded from “CompressedTextureFromByteArray” is invisible on screen.
I don’t understand what I’m doing wrong because I’ve seen working AFT texture in Away3D example (and downloaded that texture but nothing…)
#6 by jackson on December 3rd, 2012 ·
Check out today’s article for a little “getting started” guide for ATF.
#7 by Trey on December 26th, 2012 ·
hi, i find a little mistake in your article:
“A 1024Ã—1024 texture takes up 16 MB!”, i thinks A 1024Ã—1024 texture takes up 4 MBï¼ˆ1024x1024x4=4Mï¼‰not 16MBï¼Œam I rightï¼Ÿ
Just remind you and your article is helpful for me, thanks!
#8 by jackson on December 26th, 2012 ·
Good catch! I meant to type 2048×2048. I’ve updated the article.