Re:Creator’s Kansai

どうも、はじめまして。FirstBrandで働いているkgmです。主にFlashとか触っています。

なにを書こうかなーと考えてたんですが、意外とベタなFLASH技術について書かれているブログって少ないんじゃないかなーと思ったんですよ。
なんで、Flashを触れない、ちょっとしか触ったことがない、または触る必要も無いけど知っておく必要がある人にもタメになる、
「これくらい知っといたら、ちょっとFlash知ってるぜ的な顔ができる」的な記事を書いていこうかと思います。
いわゆる、コツってやつですかね。

じゃあ第一回の今回は・・・

ベクターか、ビットマップか　それが問題だ
って事にしときます。

Flashでグラフィック要素を扱う場合、イラストレーターやファイヤーワークス、Flashで図形ツールやパスツールなどで作った、ベクター要素と、イラストレーターやフォトショップ、ファイヤーワークスなどで用意したビットマップ要素（つまり画像。ラスタデータとも呼びますね）のどちらかを扱うことになります。

この二つは当然の事ながら別々の長所と短所を持っていて、対極に位置する関係です。
この二つを、しっかりと効果的に使いこなせるかどうかというのが、基本ですがとても重要になります。
このエントリは、是非デザイナーさんにも読んでほしいです。
よく、デザイナーさんとこのあたりで揉める事があるので・・・・。

で、この二つ根本的に何が違うの？って言うのを簡単に説明するとですね・・・

ベクターデータとは、直線、曲線、色、位置などを数値化した情報データのことです。
Flashでは数値化された情報データを、独自の描画エンジンにて描画し、グラフィックにします。

また、ビットマップデータ（ラスタデータ）とは、1ドットにひとつづつの色を置いた、点打ち情報のデータ
です。*1Flashでは、そのままいわれた通り表示する感じですかね。

*1　画像のエンコード方式によって、もちろん差異があります。
GIFなんかは色情報を横一列に記述するので、横一列が同じ色の場合、非常に軽くなります。
ためしに、フォトショップなんかで300pix*300pixあたりで縦グラデーションと横グラデーションでGIF書き出ししてみてください。
容量に大分差があります。豆知識豆知識ｗ

で、じゃあ具体的にどういう差が生まれるの？ってとこですが、
それぞれ長所短所があるわけです。
まず長所から見てみましょう。

■ベクター
• 点と点を結び、それに色を追加した情報の塊なので、超複雑な図形で無い限り、データ量が少ない（容量が少ない）*2
• Flash上でそのまま変形や色変更ができるなど、編集が容易
• 拡大、縮小などをしても、画質が乱れるようなことがない。

■ビットマップ
• ベクターでは表現できないような、高度な表現が可能。（フォトショップのフィルタ機能など）
• ベクターにくらべて、描画処理が劇的に少ない*2
• イラストレーターやフォトショップでのデザインデータからFlashに取り込む際に、変化なく取り込める（環境依存が少ない）

などが挙げられるかと思います。

で、短所ですが・・・

■ベクター
• 描画に演算処理が必要なため、複雑な図形になると、処理が重くなる。
• 基本的には点、線、色で描画するため、表現に限界がある。
• イラストレーターなどからFlashに取り込む際、データが変化する（ぶっ壊れる！）事がある。

■ビットマップ
• 凝った画像、でかい画像、色数が多い画像、アルファ（透明）を使った画像などは、ファイル容量がクソでかい
• 修正があった場合、非常に面倒（フォトショなどで元データ修正して書き出し、そして取り込み）

見たいな感じですかねー。

なので、ベクターかビットマップかを判断するには、
表示したいグラフィック要素が

• ビットマップでないと表現不可能なのかどうか？
• ベクターで表現して、処理の重さは許容範囲内か？
• 編集の容易性は、どれほど必要か？

などを考慮する必要があります。

つまり、グラフィックの再現性と処理パフォーマンス、そして編集の容易さを天秤にかけます。
グラフィック命の表現であれば、多少処理パフォーマンスに影響を与えようとも、文字や図形はベクターでやった方がキレイです。
逆に動きの表現重視であれば、要素を極力ビットマップにして行き、許容できる処理パフォーマンスまで抑えます。
単純に最終アウトプットの事だけ考えるのならば再現性と処理パフォーマンスだけ見ればいいのですが、
編集の容易さを無視すると、後で泣きます・・・・

というわけで、両方の長所・短所がわかり、使いどころもなんとなく見えてきたかと思います。
長かったですが、ココから本題。
それぞれのデータを使う上でのコツ、注意点です。

ベクター

とにかく、パスを最小限に抑える。

とくにイラストなどでよくありますが、スキャンした画像データなどをライブトレースした場合などは、イラストレーター上でスムーズツールなどを使って極力パスの数を減らします。
イラストレーターであれば、「パスの合流」や「透明部分の分割・統合」などを駆使すれば、よりパスを減らす事ができます。塗りの下側にある、表示されないパスなどはこの方法で消してください。

無駄なグラデーションを使わない。

グラデーションもかなりの描画処理を必要とします。小さいところや、単色でもまかなえる部分はグラデーションを取り払いましょう。どうしても必要な場合は、ビットマップと十分な検討をしてください。

ビットマップ

適切なサイズで

ビットマップはその性質上、拡大すると画質が乱れます。だからといって、「大は小を兼ねる」と大きく書き出して取り込むような事をしてしまうと、ファイルサイズが大変です。最適なサイズで書き出しましょう。

適切な形式で

画像にはJPG,GIF,PNGなどなど色んな形式があります。その都度に合わせた形式で書き出してください。具体的には・・・
・色数が少なく、簡単な図形的なものであれば容量が少ないGIFで。
・写真などの色数が多いデータはJPGで。
・アルファ（透明）が必要な場合は、PNGで。
となりますが、ここで注目！
最後のPNGですが、イラレ・フォトショで作ると、PNG-24で書き出さなければ透明部分のアンチエイリアスが効かないため、やむを得ずPNG-24で書き出します。
が！！ファイヤーワークスにてPNG-8で書き出すと、なんとアンチエイリアスが効くじゃないですか！これで、容量かなり抑えれます。
イラレやフォトショで作ってしまっていても、個別にファイヤーワークスに持っていって書き出すくらいの価値はあります。

とまあ、少ないですがこんな所じゃないでしょうか。

ちなみに、上記の特性のいいとこ取りな方法もあることはあります。
たとえば、ベクターデータで作っておいて編集の容易さを確保しつつ、表示する際にはActionSctiptで
cacheAsBitmap = true;
を設定することにより、ベクターデータをビットマップデータとして扱う事もできます。
ただ、cacheAsBitmapは拡大・縮小・回転の際に再描画されてしまうため、それらの動きをする要素には使用禁止です！！余計重くなります。
なので、BitmapData.draw()などでムービークリップ自体を一旦ビットマップに描画してしまう、などの扱いがいいかと思います。

こちらの詳しいやり方は、機会・要望があれば書いてみようかと思います。

本日は、ひとまずこれまで！
またよろしくお願いいたします～～