質問: 圧縮テクスチャはファイルサイズが少量で済むと聞いたのですが 512x512のpngをETC1テクスチャ化すると サイズが 10k(png) => 120k(pkm) に増えてしまいます Androidではapk書き出しでzip化され その 120k(pkm) => 500バイト まで減るのですが 通常時にpngよりファイルサイズが大きいのは、正しい挙動でしょうか? 大量の圧縮テクスチャをapkに含めず、zip化したものを外部ファイルとしてDLさせる場合 解凍すると、100M => 1G 程になってしまいます 展開後の1Gをストレージに保存するのが正しいのか zip状態の100Mを保存し、起動するたび、メモリやキャッシュに展開して使用するのか あるいはzipのまま使う方法があるのか... 何だか根本の考え方が間違っている気がするのですが、おかしな点を指摘して頂けると助かります
回答: 圧縮に関しては詳しくはありませんが、ETC1とpngでは圧縮アルゴリズムが違いますので、そんなものかと。 * ETC圧縮のアルゴリズムとは? * 呑みながらでもわかる! これくらいなら知っておきたい「PNGのしくみ」 上記によると、ETC1はファイルサイズはおおよそ1/6になるそうです。 それに対してpngは、大雑把に言えば同じデータをまとめるよう圧縮しますので、内容によってサイズがまちまちです。 (写真と、白一色の画像のサイズを見比べてみれば、差が目に見えて違ってくるのではないでしょうか) > > 展開後の1Gをストレージに保存するのが正しいのか > > zip状態の100Mを保存し、起動するたび、メモリやキャッシュに展開して使用するのか > > あるいはzipのまま使う方法があるのか... > > > ご自身でメリット・デメリットを把握した上で、お決めください。 zipの状態で保存し、実行時に全て展開する 単純に考えて1Gのメモリを使う事になるでしょう。 いくら最近のスマホはメモリが多いからといって、動くかどうかすら怪しいです。 展開した状態で保存する 1Gのストレージを使う事になりますが、うーん、どうでしょう。 ユーザの事を考えると、ちょっと気が引けますね。 zipの状態で保存し、実行時に必要なものだけ展開する androidであれば、使った事はありませんが、`ZipInputStream`で処理できるのではないですか。 * ZipInputStream - Android デベロッパー iOSは知りません。 png画像を使って、圧縮しないで保存する 先のリンク先にも書かれてますが、png画像をzipで圧縮しても、サイズは変わりません。 であれば、zipなど使わずに、png画像そのままで保存するという手もあるかと思います。 (一つのファイルにまとめる必要があるならば、アーカイバを自作しましょう。それぐらいは頑張ってください) ただ、pngはETC1と違い、**GPUでは扱えない画像フォーマットです。** 大抵の場合、CPUでRGBA32などのR画像に変換してGPUに送る事になると思いますが、そうなると当然実行時のメモリの負荷が高くなります。