NowLoading...

NowLoading
  1. ホーム
  2. 技術備忘録
  3. Atlasを小さくするテクニック

Unity

  • facebook
  • twitter
  • line
  • hatena
  • pocket

Atlasを小さくするテクニック

色々なプロジェクトでUnityを触ってきたので、Atlasの作り方にも千差万別、個人差があるなーと感じる今日この頃。
Atlasがやたら大きくてアプリサイズを圧迫しているプロジェクトもあれば、3Dと混在するゲームは頑張って容量削減してるし、unityの画像周りは管理するだけでも大変。
専門知識を持つ人がいるかいないかで作り方も随分変わるものです。
今回はAtlasサイズを抑えるテクニックをご紹介します。

基礎知識

Atlasとは

細かく切り出された画像”sprite”を1枚のシートにまとめて出力したもので、Atlas化することによって読み込み処理を軽減させるための手法。
画像サイズが大きいと消費メモリも増えるため、小さくすることが必須。 また1画面で読み込む枚数を抑えることも重要です。 spriteatlas 画像をAtlas化する際に効率の良い方法を考えてAtlasするように心がけましょう。

ナインパッチを駆使する

Unityには”ナインパッチ”という、画像の一部分を引き延ばしたり、繰り返すことができる機能があります。
ナインパッチを利用することで小さな画像を大きく表示させることが可能にるわけです。 ninepatch ninepatch2 引き延ばしたい画像(sprite/Atlas)を選択し、inspecterタブから”SpriteEditor”ボタンを押すと、スライス編集画面が表示されます。

spriteediter
画像上でD&Dするか数値を入力すると画像がスライスされます。

サイズ違いの〇画像

〇画像の中央部分でスライスを切ることで、いろんなものに応用できるようになります。
角丸のデザインを多用するときには複数のサイズ違いを用意しておくと便利です。
白い(グレー)spriteならcolortintで色変えが出来るので各サイズ1つあればOK

角丸
スライスで引き延ばされるのは中間だけなので、角のサイズは変化しません。
スライスの特性をうまく生かしてsprite数を節約します。

マージンに注意

Unityに画像を取り込むと圧縮がかかるので、若干画像が荒くなります。 「Unityで画像を綺麗に表示させたい」:参照
そのため、画像パーツ同士の間隔が近いと隣の画像の色を拾ってしまう場合があるので、マージンは十分とりましょう。最低でも2px。
他の記事で紹介した、スマホは半分サイズのためです。 アプリの画面デザインで最低限知っておかないと恥ずかしい基礎知識:参照

スライス
3~4pxくらいとっておくと安全です。

Commmonをフル活用する

デザイン段階で使いまわすデザインをパターン化しておけば、画面ごとにAtlasが増えていくという事態は避けられます。 common デザイン的にも一貫性が生まれるので、画面ごとに見た目が違うといったことも起こりにくくなるでしょう。
Commonパーツですべて構成できるのがベストだと思いますが、多分不可能なので、個別のページごとのAtlasとCommonの2つを読み込んで画面を構築するという作り方が現実的かと思います。 page


アプリ容量削減のポイントは”極力画像を使わない”ことです。
文字をいちいち画像にしているプロジェクトがよくありますが、ビットマップフォントをそのままアプリに組み込むのと変わらないので、多用すると容量が増えます。やめましょう。
画像にしてしまうと文字として認識されにくくなるので(絵の一部に見える)UX的にも不利です。

番外編

ドローコールを減らす

Atlasが複数の場合、Unityは画像の重なり順(depth)を見るのでAtlasが分かれていると描画回数が増えてしまう場合があります。
重なりが近いもの同士を同じAtlas内に収めることでドローコールの回数を減らすことができるようです。 drawcall 詳しくはこちらをご覧ください↓

フォントを増やさない

デザインのクオリティを左右するフォントですが、フォントデータは非常に重いデータです。
PCだってたくさんインストールすると動作が遅くなりますよね。unityだって同じです。
フォントデータといってもただの画像の集合体なので、フォントデータを増やせばデータ容量を圧迫します。特に”日本語は五十音+漢字+記号”と1フォントで5000~10000字もの膨大な量のデータが含まれるので、日本語フォントを1つ入れるだけでかなりの容量を持っていかれます。
とはいえ、デバイスにデフォルトでインストールしているフォントは端末によって違うので、日本語フォントを一切使わないというのもなかなか難しいかもしれません。
ただ工夫次第ではかなり抑えることができます。

フォントデータを抑えるテクニック

自分の場合、Unity開発における埋め込みフォントは 日本語フォント1種+英数フォント1種 までと決めています。

デザインにおいて複数のフォントを使い分けるのはかえってデザインの質を下げてしまう可能性の方が高いので、システムフォントとして使用するフォントは1種類あれば十分でしょう。
font
デザインとしてスポット的に違うフォントを使いたいならデザイン画像に埋め込んでしまえばいいんです。
image
システムフォントにするということはパーツが分かれるので、ドローコール数も増えます。システム的に可変するような場所でなければ画像に埋め込んでしまった方が良いでしょう。
わざわざフォントデータとして持たせても使うシーンが限定的なら、その容量を無駄遣いする方がもったいないです。

英数に関しては英語(大小)+数字10種+基本的な記号(アスキー文字)で128文字しかないので、そこまで大きなデータ容量にはなりません。(それでも使い過ぎはダメ)

数字はデバイスのデフォルトで良くない?

フォントによっては拡縮すると読みづらくなってしまうものもあります。
ゲームのようにパラメータなどで多用される数字系の文字はデザインにこだわったフォントよりもデバイスにデフォルトでインストールされているフォントをそのまま使った方が読みやすい場合も多いと感じます。
また、こういった数字は小さく表示される場合が多いので、デザインにこだわったフォントでなくても特におかしく見えるということも少ないです。
Androidでは「NotoSans」「ROboto」iOSでは「ヒラギノ角ゴ」「SF」が標準搭載されているので、このあたりのフォントをそのまま利用してしまえば、unity内に組み込む必要がなくなるので、検討すべきかと思います。

関連記事

もっと見る

技術備忘録 でよく読まれている記事

人気記事TOP10