CODEWITHSUNDEEP
texturesscenekit
sambro
sambro

Reputation: 816

How to compress textures for use in SceneKit

I tried the texturetool in Xcode to compress a bunch of .png textures for use in a SceneKit scene. Tried several options as per Apple docs.

  texturetool -e PVRTC --channel-weighting-linear --bits-per-pixel-4 -o ImageL4.pvrtc Image.png

The resulting image was 3 to 4 times the size of the original png. I expected it to be significantly smaller. These are square textures, power of 2 etc. Ended up making it smaller and doing a lossy optimization pass.

What is the right approach to texture compression (for iOS10)?

Updated with compression test results. With this image it was approx. 2x the size. Not surprisingly, the results were the same with textureTool. The PVRTexTool (from Imagination Technologies) offered a wider variety of formats to choose from.

PVRTests

Upvotes: 2

Views: 1108

Answers (2)

Simon F
Simon F

Reputation: 1055

This is slightly on a tangent to your question but there's a discussion of texture compression including PVRTC here.

(TLDNR: PNG and JPEG may be good for storage/transmission of texture data but they must be fully decompressed in memory before the GPU accesses them)

However, if you do have a texture that compresses well with PNG, there is a good-to-moderate chance that, with a little bit of re-ordering of the data, the compressed PVRTC/ETC/S3TC images may also benefit from lossless compression (e.g. zlib etc), which may then solve your storage problems.

Upvotes: 1

Confused
Confused

Reputation: 6278

There are three main ways (off the top of my head) to think about "right" in terms of compression of textures.

  1. The storage a texture takes up, and the compromises you're willing to accept in terms of loss of detail in the pursuit of ever smaller texture file sizes. This can include actually physically shrinking a texture, and expanding it later, but is generally fighting with different lossy formats, with consideration of...

  2. The extent to which compression impacts the loading time, because all compressed imagery in your package has to be decompressed to be used by the GPU/CPU and your app to present imagery on screen as textures, etc. Some image formats and compression types take MUCH longer to decompress than others. Some are lightning fast, but larger.

  3. The final concern is the format you're going to use, in GPU memory, of the texture. This is generally bit details, but there are some more options on some hardware. Is it, 2, 4, 5, 8 bits per colour? How many bits for alpha? etc.

Not all video accelerators and systems cater for multiple formats of texture, but Apple does, as you've probably discovered. Each of these is a blend of tradeoffs in size vs detail. Less bits for colours = less definition of gradients etc. Apple's hardware is also very good at decompressing some formats and terrible at others. And the ultimate size of your package is obviously a different concern on different device types.

You're limited to 200MB on Apple TV, before needing to use some storage management.

100 MB the limit for apps over cell data, etc.

Upvotes: 1

Related Questions