问题
I'm aware that this is not entirely officially supported at the moment, but I'm trying to generate an ATF texture using the open source project ATF-Encoder. I'm then trying to upload it to a Stage3D Texture with uploadCompressedTextureFromByteArray
, which is, itself, supported since FP11.
This works in the sense that the texture is correctly uploaded and displayed. I can also verify that there are compression artifacts on the resulting texture, especially if I increase the quantization factor during encoding, and that the resulting ByteArray is much smaller (about 20x less) than a "raw" texture.
However, measuring GPU usage with Process Explorer, I'm still consuming the exact same amount of VRAM per texture (i.e. 5.333 bytes per pixel), instead of the expected much smaller value.
The texture is created with BGRA mode, instead of Compressed mode - if I try compressed, it gives me "incompatible format" when attempting to upload. From what I can gather, the ATF format supports "compressed mode" textures, but ATF-encoder does not output textures with that flag set? (I've tried forcing the flag on after the compression is done, which, unsurprisingly, just crashes Flash)
Does anyone have more information regarding this issue? Would encoding the proper ATF and uploading with Compressed flag solve the issue? Or is this an implementation bug, where it's accepting the compressed payload, but uncompressing when uploading? Any information here is valuable, really.
This is in hardware mode, on an AMD Radeon 6450, Windows 7 64-bit, Flash Player 11.3 (same thing happens in 11.4 beta).
回答1:
Just to clarify what renaun is saying, there are multiple types of compression at work in ATF:
Block compression (PVRTC, DXT5, and ETC1) are the compression types that reflect a savings in GPU memory. If you don't use block compression, your texture will be uploaded as RGBA and use just as much GPU memory as a PNG.
Aside from that, JPEG XR can also be applied to the ATF file, whether you used block compression or not. This will reduce the file size of the ATF, but not the amount of GPU memory required. Note that quantization level 0 is lossless, so it won't introduce further artifacts, but with Adobe's png2atf utility, you can set a quantization factor (compression level).
Bottom line: since the open-source ATF-Encoder you cited doesn't support block-level compression (citing lack of open source compression code), then it can't create textures that result in less GPU memory usage.
Additionally, ATF is a container format. That means it can hold one or more encodings (types of block compression) of an image. You can create an ATF file that contains any combination of PVRTC, ETC1, and/or DXT5, depending on which platforms you want the ATF to work on. For example, you can have your build process package .atf files for iOS only when packaging the .ipa file, and for Android only when packaging the .apk file.
IMO, the sweet spot is block compression + lossless JPEG XR compression. This represents GPU memory savings + small filesize. The commandline for this (again, using Adobe's png2atf) is:
PVRTC (iOS):
png2atf -c p -r -i image.png -o image.atfETC1 (Android):
png2atf -c e -r -i image.png -o image.atfDXT5 (Desktop):
png2atf -c d -r -i image.png -o image.atfAll 3 formats in one .atf file:
png2atf -c -r -i image.png -o image.atf
Also note that block compression can result in some pretty ugly artifacts. I'd only use it if you need the GPU memory savings.
Update - in regards to Dave Walker's comment - yes, PVRTexTool does a better job at creating high-quality results. It has a GUI and a command-line, you can explore all the options for yourself with the GUI, but my favorite commandline options (for top quality of semi-transparent PNGs with cartoonish sprites) is:
PVRTexToolCL -i image.png -o image.pvr -m -l -f PVRTC1_4 -q pvrtcbest -mfilter cubic
回答2:
ATF is just a file container format to help with packaging different formats into one file. You don't need to put multiple file types into the the ATF file but you can. There are various compressed textures for desktop and mobile devices, including dxt1/5, pvrtc, and etc. ATF also supports containing RGBA data, hence why you see the same texture memory size. If you had a compressed texture it would probably be different.
There will be some ATF tooling that will come from Adobe at some point. See Thibault's comments in this forum - http://forum.starling-framework.org/topic/atf-adobe-texture-format/page/2
I haven't used ATF-Encoder source code to know if its compression works for dxt or not.
来源:https://stackoverflow.com/questions/11652507/loading-of-atf-textures-in-flash-11-3-works-but-has-high-memory-usage