2014年08月08日

うにばな講座みたいなもの番外編（高速化（最適化）について3　モバイル系-翻訳）

こんばんわです

季節がらまたも台風が西日本方面からちかづいているとか

今年は大きめの『大自然のおしおき』が押しよせているようですが

被害が出ないよう気を引き締めないといけませんね

そんな業務連絡

さてようやくお仕事のほう一段落しましたがまだ膝に受けた傷が癒えておりません

長いこと記事も更新していないためかるく翻訳ネタでリハビリをしようと思います。

今回はUnite2013のUnityのモバイルゲームの最適化に関するペーパーを PDFのリンクだけだとさみしいので簡単に訳してみました

情報としてはちょっと古めかもしれませんが、これからUnityでゲーム制作を初める方は参考にどうぞ。

｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜

□Optimizing Unity Games for Mobile Platforms

｜

Angelo Theodorou
Software Engineer
Unite 2013, 28th-30th August

malideveloper.arm.com-downloads-Unite_2013-Optimizing_Unity_Games_for_Mobile_Platforms.pdf

｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜

□Mali_GPUについて

□予備知識

■ドローコールとは何ですか？

基本となるAPI（例えばOpenGL ESの）の関数を呼び出すと、画面上に何かを描画することです

■フラグメントとは何ですか？

一度描画候補に上がったピクセルは表示されてもされなくても（例えば、上書きされる廃棄されるなど）スクリーン全体に描画されます

■不透明と透明レンダリングキューの違いは何ですか？

最初のキューではオブジェクトはデプステストにしたがって手前から奥に向かって最小限のオーバードローでレンダリングされます

透明なものはその後に正確さを維持しつつ奥から手前に向かってレンダリングされます

■バッチ処理とは何を意味するのでしょうか？

全体のデータセットの中から似たようなインスタンスグループを1回のドローコールで呼び出しするための処理です

■なぜモバイルプラットフォームは異なっているのですか？

即時レンダリング（フォワードレンダリング）と遅延レンダリング（ディファードレンダリング）の差です

□なぜモバイルプラットフォームが異なっているのでしょう？

■デスクトッププラットフォーム

即時モード：グラフィックスコマンドがすぐに実行される

GPUと専用ビデオメモリ（> 100 GB /秒）の間で利用可能な帯域幅で膨大な量のデータ転送ができる電力消費や発熱に厳しい制限がない

■モバイルプラットフォーム

遅延モード：グラフィックスコマンドはドライバによって収集された後で実行される
タイルベース：メモリに書き込まれる前に、小さなオンチップバッファでレンダリングされる
帯域幅が大幅に減少し（?5GB /秒）データ転送に大きなパワーを必要とする
メモリが統一され、CPUとGPUの間で共有されている

□ユニティプロ

■プロバージョンのみの最適化機能：

Profiler （プロファイラ )
Level of Detail ( LOD)
Occlusion Culling (オクルージョンカリング)
Light Probes (ライトプローブ)
Static Batching (静的バッチ処理)

□OpenGL ES3.0

■Unity4.2、Androidの4.3と Mali-T6xxで利用可能

■変換フィードバック

データ再利用のためのバッファオブジェクトに頂点シェーダー出力を書き込むことができる

■ETC2とEACテクスチャ圧縮フォーマット

RGBAのためのサポート（ETC2）および1/2チャンネルのテクスチャ（EAC）

■オクルージョンクエリ

可視性を決定するために描かれたサンプルの数を照会できる

オクルージョンクエリとは： http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter06.html
■ジオメトリインスタンシング

同じオブジェクトで独自プロパティを持つ多量のインスタンス

■Primitive restart, Uniform Buffer Objects, Pixel Buffer Objects,
Fences, FP/3D/depth textures, Multiple Render Targets, …

□ボトルネックを特定する

■CPU

ドローコール(描画呼び出し)が多すぎる
複雑なスクリプトや物理演算

■頂点処理

頂点数が多すぎる
頂点ごとの計算が多すぎる

■フラグメント処理

多すぎるフラグメント処理は、オーバードローにつながる
フラグメントごとの多すぎる計算

■帯域幅

解像度が大きく非圧縮なテクスチャ
高解像度なフレームバッファ

□CPU バウンド

■ドローコール(描画呼び出し)が多すぎる

静的バッチ（Unityプロのみ）
ダイナミックバッチ処理（自動）
錐台カリング（自動）
オクルージョンカリング（Unityプロのみ）

■複雑なスクリプト

コンポーネントのキャッシング
オブジェクトのプール
GUIコールの削減
OnBecomeVisible（）/ OnBecomeInvisible（）
時間指定ではなく、フレームごと更新のコルーチン

■複雑な物理計算

一つのメッシュコライダの代わりに複数のコライダーを組み合わせる
“Fixed Timestep”の時間間隔を増加（TimeManager）

□ 頂点バウンド

■頂点数の多すぎるジオメトリ

不要な頂点を削除する
不要なハードエッジとUVシームを削除する
LODを利用するLODGroupで切り替え（Unityプロのみ）
カリング錐台（自動）
オクルージョンカリング（Unityプロのみ）

■頂点ごとの計算が多すぎる

Unityシェーダのモバイル版を使用

□頂点バウンド LOD

Unite_2013-Optimizing_Unity_Games_for_Mobile_Platforms_15

■LODグループを使用することでオブジェクト細部を必要としない時に頂点数を制限することが出来ます(オブジェクトが非常に遠くにあったり小さかったりする場合)

ジオメトリオブジェクトが非常に遠くに表示される場合はビルボード(板ポリゴン)で置き換えることが出来ます

□フラグメントバウンド

■オーバードロー

スクリーンに描画するときおなじピクセルに何回も書き込みしない
オブジェクトを手前から奥に向かって描画するより奥から手前に向かって描画するほうがオーバードローは少ない、デプステストがもたらす恩恵
シーン内でのトランスペアレンシー(透過)の量を制限します（パーティクルに注意しましょう）
Unityには、ピクセルあたりのオーバードローの量を表示するためにレンダリングモードがある

■多すぎるフラグメント(ピクセル描画)計算

データを出来る限りベイクする（ライトマップ、ライトプローブなど）
ピクセル単位のライトの数が含まれている
リアルタイムの影を制限（ハイエンドのモバイルデバイスのみ、Unity4プロ）
フルスクリーンのポストプロセッシングを避けるようにする
Unityシェーダのモバイル版を使用

□フラグメントバウンド - オーバードロー

■レンダリングモードを使用してオーバードローの量を確認する

□帯域幅バウンド

■テクスチャ圧縮の使用

OpenGL ES3.0とOpenGL ES2.0、ETC2、EACと、ETC1

ASTCはまもなくUnityでサポートされる新しいクロノス規格です

■MIPマップの利用

多くのメモリが必要だが画質は向上（より少ないエイリアシングアーティファクト）
メモリ帯域幅の最適化（小さいマップからサンプリングしたとき）

■ディテールの減少にも対応できる16ビットテクスチャの使用

■トライリニアフィルタと異方性フィルタリングの適切な使用

□帯域幅バウンド - ミップマップ

■レンダリングモードを使用してミップマップ・レベルをチェックします

｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜

プロファイリングツール

□ユニティ・プロファイラー

■詳細なフレーム単位のパフォーマンスデータを提供します

■プロファイラーは次の特定のデータを提供します

CPU使用率
レンダリング
GPUの使用方法
メモリ
物理計算
オーディオ

■モバイルデバイス上のコンテンツの実行をプロファイルすることができます

■Unityプロでのみ使用可能

□ユニティプロファイラ - CPU使用率

■これはレンダリング、スクリプト、物理演算、ガベージコレクションなどにおけるCPU使用率を示しています
■どのように時間消費されたかについての詳細な情報を示しています
■スクリプトで発生したすべての関数コールに対しディーププロファイルのデータを追加し有効にすることができます
■Profiler.BeginSample（）とProfiler.EndSample（）で特定ブロックにコードを記述することでマニュアルで追跡が可能になります

□ユニティプロファイラレンダリング

■レンダリングサブシステムに関する統計

ドローコール
三角メッシュ
頂点

下部ペインのエディタウィンドウは、レンダリングの統計と同様のデータを示している

□ユニティプロファイラメモリ

■使用/確保されたメモリをより高いレベルで閲覧できます

Unityのネイティブの割り当て
ガベージコレクトされたMonoが管理する割り当て
グラフィックスとオーディオの合計使用されるメモリの推定
プロファイラ・データ自身の使用メモリ

■アセット/オブジェクトが使用するメモリも参照できます

テクスチャ
メッシュ
マテリアル
アニメーションクリップ
オーディオクリップ

■ユニティ4.1以降の新しい詳細な内訳

□ユニティプロファイラ - GPUの使用方法

■CPUのプロファイラと同様の内訳を示しています

不透明なオブジェクトのレンダリング
透明なオブジェクトのレンダリング
影
ディファードシェーディングパス
ポストプロセッシング

※モバイル・プラットフォーム上ではまだ利用できません

□ARM Streamlineのパフォーマンスアナライザ

□サンプルアプリケーションの概要

■7種類のシーンで構成

ジオメトリ（高い頂点数、錐台カリング）
LOD（LODGroupを通じてLODレベルを使用）
パーティクル（透明レンダリング）
テクスチャ（ミップマッピングと圧縮）
オーバードロー（アルファブレンディングとアルファテスト）
ライト（頂点およびピクセルライティング）
アトラス（テクスチャアトラス）

■それらのほとんどはプレハブとInstantiate()に基づいています

すべてのインスタンスが最初に一度に作成され、ディアクテイブされる
アクティブなインスタンスの数は、目標のFPS値を維持するために適応することができる
位置決めは、スクリーン空間で行われカメラのアスペクト比に基づいている

□ジオメトリシーン

■高い頂点数のポリゴンオブジェクトがたくさん頂点単位を強調

可視オブジェクトの量または目標のFPS値を設定することができます

レンダリングに多くの時間が費やされている（緑で描画の部分）
表示オブジェクトの数が増えた部分

■カメラを回転し移動することでカリング錐台の動作状態を確認できる（オクルージョンカリングが働いていない）

ほとんどのオブジェクトはカメラビューの外に存在して錐台カリングの効果が出ている
オブジェクトのほとんどは手前のオブジェクトに隠れているが(処理負荷が上がっている)オクルージョンカリングが有効になっていない

Unite_2013-Optimizing_Unity_Games_for_Mobile_Platforms_29

□LODシーン

■3つの異なるレベルのLODGroup

■三角メッシュと頂点がLODレベルで切り替えられ、ドローコールが錐台カリングに影響を受けている

□パーティクルシーン

■すべてのレンダリングは、「透明キュー」で行われます
■完全なジオメトリバッチがなされている場合（パーティクルエミッタごとに1回のドローコール）

□テクスチャシーン

■MIPマップを使用した圧縮テクスチャ（右）はメモリ消費が少なく圧縮されていないもの（左）より良く見える

右：様々な形式で圧縮+トライリニアフィルタリング+MIPマップ

左：非圧縮+バイリニアフィルタリング

□オーバードローシーン

■アルファブレンドされた四角メッシュが透明キューにレンダリングされオペーク(不透明)キュー内でアルファテストが実行される、両方同じパフォーマンス

Unite_2013-Optimizing_Unity_Games_for_Mobile_Platforms_33

□ライトシーン

■ピクセル単位のライティングがライトごとにドローコールされる（フォワードレンダリング）

■頂点ごとのライティングはオブジェクト単位のジオメトリパスで実行されるライティング情報は頂点の属性

■MeshRenderer.Renderは、ms(ミリ秒)あたり5倍のピクセル単位のライティングを実行する（ライトごとに1つのパス）

□アトラスシーン

■非テクスチャアトラスのレンダリング

各インスタンスは、独自にテクスチャを持っている
同じ材料の複数のインスタンスが同じテクスチャを共有する場合
マテリアルごとに一度のドローコール（複数のインスタンスの場合）

■アトラスレンダリングでマテリアルUVを変更

各インスタンスは、同じテクスチャアトラスを共有
UV座標はmainTextureScaleとmainTextureOffsetを使用して変更される
独自のマテリアルがインスタンスに割り付けられるとインスタンス描画の関係は崩れる
インスタンスごとに1つのドローコール

■アトラスレンダリングでメッシュのUVを変更

各インスタンスは、同じテクスチャアトラスを共有
UV座標は、インスタンスのメッシュにアクセスして変更されます
一度のドローコールですべてのインスタンスを描画（マテリアルは一つだけ）

左から

:アトラスなしテクスチャ

60 FPS
50 draw calls, 374 batched
21 materials
:アトラスとマテリアルUV

40 FPS
408 draw calls, 0 batched
395 materials
マテリアルにバッチが働いていない

:アトラスとメッシュUV

60 FPS
35 draw calls, 374 batched
21 materials
マテリアルにバッチが効いていて、ドローコールが少ない

:参照リンク

Practical Guide to Optimization for Mobiles (Unity Manual)
Optimizing Graphics Performance (Unity Manual)
Profiler (Unity Manual)

ShadowGun: Optimizing for Mobile Sample Level (Unity Blog)
“Fast Mobile Shaders” talk at SIGGRAPH 2011 (Unity Blog)
Introducing the new Memory Profiler (Unity Blog)
Unity 4.2 has arrived (Unity Blog)

http://malideveloper.arm.com/
OpenGL ES 3.0 Developer Resources (Mali Developer Center)
ASTC Texture Compression: ARM Pushes the Envelope in Graphics Technology (ARM Blogs)

【編集後記】

ということで久しぶりにブログ更新すると疲れましたえらく疲れました

次回は前回予告したとおりスクリーンスペース系のイメージエフェクト解説をする予定なのですが

久しぶりに以前書いたコードを見なおしたらキタナクて解説とか出来なそうなのでいまリライトしている最中です

なので気長に一週間ほど待っていただきたいほんものの（ｒｙ

いまのところ予定では次の2種類のエフェクトから徐々に進めていくつもりです

■SSDO (Screen Space Directional Occlusion)

スクリーンスペースベースのリアルタイムグローバルイルミネーション

■SSLR (Screen Space Local Reflections)

スクリーンスペースベースのリアルタイム反射モデル

この画像のモデルの配置がカオスなところが現在の心境を表しているような気が(´・ω・`)

ということで

「この次はモアベターよ」

こういうネタが通じる年代が見に来ているのか疑問だけれど（小森のおばちゃんネタではないです）

2014年06月19日

近況的更新

こんにちは　お久しぶりです

仕事のほうが２本ほど同時進行中で　しかも締め切りが同時期という拷問にあっています。
あー前世のカルマですわこれ　前世で世界滅亡させた記憶とかあるし。。　

それはさておき

そのうち一本が　日本全国のご当地美少女的な企画なんですが　最近の流行なのか
水面下で同じような内容のタイトルがたっくさん動いているみたいです

アニメでも『まどか☆マギカ』がオリジナル魔法少女でおっきなヒットを当てたので
魔法少女モノ（オリジナル）の企画が大量に立っているとかで　これから回転寿司のように魔法少女アニメの
ローテーションが始まるとかなんとか。　そんな柳の下のどじょう

うなぎに続いて　どじょうも絶滅危惧指定されそな勢いです。　　加減を知らない民族ですね日本人は

ご当地美少女ものは企画の性質上　最低でも県の数と同じ４７キャラはデザインしないといけないわけなんですが　
その。。なんていうか

『何にもない』がある　県てあるじゃないですか　

いまあなたの頭のなかに思い浮かんだそれ　その県とかです

なんていうか　続けているとそこのアイデアが無くなってきてですね　

すっごく　苦しい。

企画サイドから生まれてこの方聞いたこともないような　ご当地名産品のアイデアを指定されたりだけど
その地方民以外わけわからんと思うのですが。それってゲームとしてどうなの？

そんなわけで　もうしばらくしたら復活予定
だがこの記事を書いている間にも　　追加で１１キャラやってくれという連絡が。。もう　死んじゃうって

Unity記事をお待ちの方はUnityはあんまりさわれていないので　とりあえず　うちのブログをRSS登録
でもして気長にお待ちいただければと思います。

いちおう今後の予定は　
『スクリーンスペース系エフェクトの作例』　『コンピュートシェーダその２』
になっています　この記事書いて的希望があればコメントしていただければ
出来る限り記事にしていきますです

それでは　また

　　

2014年03月18日

うにばな(シェーダへ配列データの転送マルチUVなど) その2

■その他の方法

■方法１．

Data transfer to Vertex Program in Cg- how to pass an Array of floats

<shader >

shaderに値を設定:
myarray0
myarray1
myarray2..

<script >
配列名＋数字を文字列変換してシェーダにセットします:
for (i=0; i<?; i++) {
Shader.SetFloat("myarray"+i.ToString(), mycodearray[]);
}

”配列名＋数字”を文字列に変換してシェーダに転送する方法ですが配列の要素が少なければこのようなやり方でも良いと思います。

シェーダ側では switch() ステートメントで切り分ければいいのかな？

<Example>

switch(i)
{
    case 0:
        return myarray0; 
    case 1:
        return myarray1; 
    case 2:
        return myarray2; 
    default:
}

■方法2.

GL命令を使用した描画はDLLにmaterialIDを渡してC++で処理をすれば、Unityのスクリプトの10倍程度速いという

stack overflowのスレッドを見かけたことがありました例によって場所がわからなく。。

スクリーン全体を描画するような処理の場合はネイティブなDLLプラグインを書くと良いかもしれません。

今回はシェーダで作業用の配列データを扱う話ですので、そこまで大きなデータは必要なさそうなので割愛させてもらいます。

興味のある方はリンクを載せておきますので参考にしてみて下さい。

Efficiently capturing rendered images- - Unity Answers

OpenGL Context from Plugin - Unity Answers

qoncept.jp-download-seminar_unity_20110716.pdf

Unity - Low-level Native Plugin Interface

【後記】

頂点にデータを付加した方法は初期テーブルとして使用する場合には有効ですがテクスチャを使用した方法に比べると

シェーダは頂点を一度に１つしか処理できないので、ほかの配列要素にアクセスすることが出来ませんたとえばClothのような

相互に作用する計算をすることができないので、そうした場合はテクスチャにデータを焼きこんだほうが捗るということです。

あくまでいまのところこうした方法が良いのではないかという話なのでこの記事にとらわれる必要はありません。

ゲームエンジンのような頻繁にバージョンが変わるものは、すぐに情報が古くなってしまいますからその時にあわせて

最適な方法を探っていってください。

2014年03月18日

うにばな(シェーダへ配列データの転送　マルチUVなど)　その１

マルチUVの検索ワードが多めだったので今回は予定を変更してUnityのマルチUVと配列の転送についてのおはなしをします。

コード全体を書いている時間がなかったので解説だけなのですが、記事の作成におもいのほか時間がかかってしまいまして

コード書いたほうが楽だったじゃないのという企画倒れな面もありましたがなんとかまとめてみました。

頂点データにデータを付加する方法
データをテクスチャに変換する方法
ストラクチャーバッファなどを使用する方法（DX11）※ DX11を使用する方法は以前記事にしましたので参照して下さい
その他

現在のところUnityはテクスチャUV0，UV1 2つまでメッシュデータに含むことができますがUV2がライトマップ用に予約されていてそれ以上のマルチUVの値を

通常では送ることが出来ません。シェーダ配列のサポートは未定ということらしいですフォーラムで最初の要望から数年たってますからあきらめムードのような感じに。。。

■頂点データに配列データを付加する方法

Meshの構造体の未使用データ部分にUV値を書き込んでシェーダ側で対応させることで２つ以上のマルチUVを実現することは出来ます。

もちろんシェーダで使用する様々なデータを付加できますので Mesh.colors(頂点カラー)、Mesh.tangents(タンジェント)あたりが必要なければ

float4型のデータであればColor型でもVector型でも8888＝３２ビットのデータとして扱うことが出来ます。

ただしメッシュデータの最大頂点数は65,536までですので全体データ数はそれを超えることは出来ません。

もちろん頂点データの構造体をメッシュ表示をさせるかわりにデータテーブルとしてGPGPU計算に使用することも出来ます。

□配列データのエンコード・デコード

データ長が8ビットにおさまらない場合にはエンコードしてパックする必要があります。以下にサンプルのコードを載せておきます。

■floatをカラーデータ（RGB)にエンコード

float3 pack(float f) {

　　　　　 float b = floor(f / (256 * 256));

　　　　　 float g = floor((f - b * 256 * 256) / 256);

 　　　　　float r = floor(f % 256);

 　　　　　return float3(r, g, b);

■カラーデータ（RGB)をfloatにデコード

float  unpack(float3 color)  { return color.r + color.g * 256 + color.b * 256 * 256; }

※効率よくデータをパックしたい場合はビット演算子｛>>　、<<｝をつかいます。boolフラグなど1ビットで表現できるものはデータ量が減らせます。

以下にエンコードとデコードのサンプルを載せておきます

http://forum.unity3d.com/threads/95687-Passing-Arrays-to-Shader

＜Example1＞

inline float4 EncodeFloatRGBA( float v )

{

float4 kEncodeMul = float4(1.0, 255.0, 65025.0, 160581375.0);

float kEncodeBit = 1.0/255.0;

float4 enc = kEncodeMul * v;

enc = frac (enc);

enc -= enc.yzww * kEncodeBit;

return enc;

}

inline float DecodeFloatRGBA( float4 enc )

{

float4 kDecodeDot = float4(1.0, 1/255.0, 1/65025.0, 1/160581375.0);

return dot( enc, kDecodeDot );

}

＜Example２＞

// Float to Color in Unity Shader
float4 F2C(float Value)
{
float4 color;
int c1 = 255;
int c2 = 255 * 255;
int c3 = 255 * 255 * 255;
int full = (int)(Value * c3);
int B = (full / c2); full -= B * c2;
int G = (full / c1); full -= G * c1;
int R = full;
color = float4(R / 255.0f, G / 255.0f, B / 255.0f, 1.0f);
return color;
}

// Color from RenderTexture to Float
float C2F(Vector3 Color)
{
int c1 = 255;
int c2 = 255 * 255;
int c3 = 255 * 255 * 255;
return (Color.x * 255 + Color.y * 255 * c1 + Color.z * 255 * c2) / c3;
}

□テクスチャデータに配列データを変換する方法

http://forum.unity3d.com/threads/178682-Passing-Arrays-to-shaders

<意訳>

これは本当に適切であるかどうかは知りませんが、これが配列を渡す簡単な方法です

1.配列サイズに新しいRenderTextureを設定します。

2.GL.LoadPixelMatrixを使用して、quadの束（各quad= 1ピクセル）をレンダリングします。

3.各ピクセルごとにをフロート値をRGBAカラーに符号化します。ルックアップテーブルを作成しておくとより速度があがるかもしれませんまたは別のフレームで事前計算をします。

camera.renderを呼び出します。

4.RenderTextureにすべてのクワッドピクセルをblitします。

5.RenderTextureをデバイスに転送します。

デバイスにテクスチャレンダリングするには最良の方法ではありませんが、それは下位互換性を考慮するとsetPixelよりもはるかに高速だと思います。

Unityのフォーラムのほうに配列データを転送するための有効な方法として挙げられていたレスなのですが、いまのところ

この方法が最も有効そうな感じがしますので今回はこれを参考に説明してみます。

■スクリプト側

テクスチャデータの配列参照を端的にいうと頂点データにインデックスをつけてテクスチャ化した配列テーブルを参照させる方法です。

インデックスはさきほどのデータをメッシュデータに追加するやり方でどれか一つデータを利用して頂点番号インデックスを入れ込みます。

インデックスを登録するデータはUV２でもよいのですがすでに作成されているデータとの兼ね合いも考えて、あまり使用されていない頂点カラーあたりを使用すると良いかも

しれません。

インデックスに利用したデータを使用したい場合はテクスチャの方にデータとして焼き込んでそちらからデータを参照すれば良いのでとくにデメリットはないのでは。

1.まずテクスチャからデータを取得するときにUV計算のための頂点データのインデックスの登録をします。

２バイトのデータ長があれば65,536までの数値が表現できますので頂点データ数はカバーできそうです、ここでは頂点カラーRGBA のうちRGを使用した場合を考えてみます。

前項でやったように頂点インデックスをエンコードします。

この方法だとテクスチャメモリが許す限り配列が格納できますので、かなりアドバンテージがあるのではないでしょうか。

□RenderTextureの生成とオプション指定

RenderTextureを作成するときにデータをいれたテクスチャにカラー補間がかからないようにする必要があります。

次のようにオプションを指定してください

RenderTexture renderTexture = RenderTexture.GetTemporary( width, height );

※以下の2行を追加します

renderTexture.filterMode = FilterMode.Point;
renderTexture.wrapMode = TextureWrapMode.Clamp;

RenderTexture.active = renderTexture;

□FilterMode

Point - テクスチャのピクセル補間をしない

Bilinear -バイリニア補間（平均化サンプリング）

Trilinear -トライリニア補間テクスチャサンプル平均とミップマップレベルによるブレンド。

□TextureWrapMode

Repeat -テクスチャタイリング時にタイリングの継ぎ目を補間

Clamp ? タイリングの継ぎ目を補間しない.

FilterModeはPointを選択します隣接するピクセルでカラー補間をすると値が正確になりません。
WrapModeはClampを選択します Wrapはテクスチャタイリング時にタイリングの境目を補完するオプションですがこれも補間なし。

□GLを使用したテクスチャへの描画（ Unity Script Reference-GL.html ）

material.SetPass( 0 ); シェーダパスの指定

GL.PushMatrix(); マトリクスを更新する前に上書きを避けるために現在のカメラのビューマトリクスを退避させます

GL.LoadPixelMatrix( 0, width, height, 0 );

使用するマトリクスの指定＜ LoadOrtho:正射影行列 LoadPixelMatrix:ピクセル行列 LoadProjectionMatrix:プロジェクション行列＞

GL.Begin( GL.QUADS); GLの描画を開始

for( int i=0; i {

GL.Color( new Color( □, □, □, □) ); 描画カラーの指定

GL.Vertex3(□,□,□); ピクセル４角型の頂点を指定する左まわり座標で記述しないとカメラに向かって裏面になるので描画されない

GL.Vertex3(□,□,□);

}

GL.End(); GLの描画を終了

GL.PopMatrix(); 退避させたカメラビューマトリクスを元にもどします

□RenderTexture から２DTextureへの変換

RenderTexture から２DTextureへの変換でよくサンプルになっている方法にGraphics.Blitを使用する場合と Texture2D.ReadPixelsを

使用した場合が挙げられているのですが、ケースによって選択したほうがよさそうなので 2種類のサンプルコードを載せておきます

1.Graphics.Blit を使用する例

Graphics.DrawTexture on RenderTexture not working...- - Unity Answers

using UnityEngine;

using System.Collections;

public class Test : MonoBehaviour

{

public Texture2D texture; //初期化テクスチャ.

public Texture2D stampTexture; //Graphics.DrawtextureでRenderTextureに変換するためのテクスチャ.

public float posX = 256f; //DrawTexture で使用するテスト用座標.

public float posY = 256f; //DrawTexture で使用するテスト用座標.

RenderTexture rt; //RenderTexture を bufferとして定義

void Start ()

{

rt = new RenderTexture (512, 512, 32); // 512x512 pixels サイズのRenderTextureで初期化します

renderer.material.SetTexture ("_MainTex", rt); //RenderTexure をシェーダのメインテクスチャとして設定

Graphics.Blit (texture, rt); //Blit命令でtextureをRenderTextureに焼き付けます

}

void Update ()

{

RenderTexture.active = rt; //RenderTextureを activeに設定 DrawTexture命令が書込できるようにします

GL.PushMatrix (); //プロジェクション行列とモデルビュー行列をスタック（退避）させます。

GL.LoadPixelMatrix (0, 512, 512, 0); // ピクセル描画用マトリックスのセットアップ.

//stampTexture をRenderTexture 座標（posX 、 posY）に配置

Graphics.DrawTexture (new Rect (posX - stampTexture.width / 2, (rt.height - posY) - stampTexture.height / 2, stampTexture.width, stampTexture.height), stampTexture);

GL.PopMatrix (); //プロジェクション行列とモデルビュー行列をスタックから呼び戻します。

RenderTexture.active = null; //RenderTextureを描画できないように.

}

メインカメラでレンダリング作業をしてはいけませんのでレンダーテクスチャ用のメインカメラのクローンを作成します。

以下のコードを参考にしてください

if (!shaderCamera)

{

shaderCamera = new GameObject("ShaderCamera", typeof(Camera));

shaderCamera.camera.enabled = false;

shaderCamera.hideFlags = HideFlags.HideAndDontSave;

}

Camera cam = shaderCamera.camera;

cam.CopyFrom(camera); // MainCameraからプロパティコピー

cam.backgroundColor = new Color(0, 0, 0, 0);

cam.clearFlags = CameraClearFlags.SolidColor;

cam.targetTexture = buffer; // buffer＝RenderTextureの指定

2.Texture2D.ReadPixels を使用する例

”GL2TextureExample2.cs” Rendering GL to a Texture2D immediately in Unity4

を参考にTexture2D.ReadPixels を使用した場合を考えます。

GetPixels of RenderTexture - Unity Answers

// Initialize and render

RenderTexture rt = new RenderTexture(width, height, 24);

activeCamera.targetTexture = rt;

activeCamera.Render();

RenderTexture.active = rt;

Texture2D newTexture = new Texture2D( width, height );

newTexture.ReadPixels( new Rect( 0, 0, width, height ), 0, 0 );

bool applyMipsmaps = false;

newTexture.Apply( applyMipsmaps );

bool highQuality = true;

newTexture.Compress( highQuality );

// Clean up

activeCamera.targetTexture = null;

RenderTexture.active = null; // RenderTextreをオフにする

DestroyImmediate(rt);

□Texture2D.ReadPixels（Rect( 0, 0, width, height ), 配置ピクセル座標ｘ, ｙ、ミップマップの再計算（bool値））

スクリーンからテクスチャにキャプチャする命令ミップマップ再計算フラグは無視してもよいです。

□Texture2D.Apply (ミップマップの生成を行うかの指定（bool値）、テクスチャをGPUにつづけて転送しない（bool値））

最後に呼び出してGPU側にテクスチャを更新ミップマップの生成をfalseにすれば省メモリになります変換速度もあがるはず。

テクスチャの解像度を階乗 8,16・・・256・・・と指定しないとGPUに転送したときテクスチャサイズが変換されてから再転送されるため遅延が発生します。

ハードウェアとライブラリのバージョンによるため必ず起きるものではなくバージョンの高いライブラリでは問題ないとか。。

矩形テクスチャで縦横比が違う場合も古いライブラリでは1:1に変換する手順が入るばあいがあり

□Texture2D.Compress(highQuality: bool値)

テクスチャ圧縮オプション。 highQualityをセットすると圧縮がかからないためテクスチャの変換速度が向上します。

※テクスチャの圧縮はハードウェアでサポートされていない場合は無視されます。

■ シェーダ側

■テクスチャフェッチ（テクスチャ参照)

http://forum.unity3d.com/threads/63231-How-to-use-vertex-texture-fetch

Shader "tex2Dlod" {

Properties {

_MainTex ("Base (RGB)", 2D) = "white" {}

}

SubShader {

Tags { "RenderType"="Opaque" }

LOD 200

CGPROGRAM

#pragma target 3.0

#pragma surface surf BlinnPhong vertex:vert

#pragma glsl

struct Input {

float2 uv_MainTex;

};

void vert (inout appdata_full v) {

#if !defined(SHADER_API_OPENGL)

float4 tex = tex2Dlod (_MainTex, float4(v.texcoord.xy,0,0));

v.vertex.y += tex.r * 2.0;

#endif

}

ENDCG

}

FallBack "Diffuse"

}

□ tex2Dlod (_MainTex, float4( (float2)テクスチャUV,0,LOD値＜0~7 ０で最大解像度＞ ));

以前にも説明しましたが頂点シェーダ（vertexシェーダ）でテクスチャフェッチする場合には頂点データの計算がされていないため

LOD値が確定していませんそのため tex2Dlodを使用して強制的にLOD値を割り付ける必要があります。

ピクセルシェーダ（fragmentシェーダ）ではふつうにtex2d()を使用すればいいです。

tex2Dlod はglの命令なので #pragma glsl を記述するかまたは以下のように書いてください

#if !defined(SHADER_API_OPENGL)

float4 tex = tex2Dlod (_MainTex, float4(v.texcoord.xy,0,0));

v.vertex.y += tex.r * 2.0;

#endif

□UV値の計算

UV値は1をテクスチャサイズで割って求めます V方向（uv.y)は0.5を掛けてテクスチャの中央あたりをサンプルするように

このサンプルではテクスチャサイズが u方向に配列サイズ分のピクセル数 v方向に1ピクセルのテクスチャをイメージしています。

uint idx = color.r*255+color.g*255*255; //頂点インデックスのデコード

float2 uv = 1.0 / TextureSize;
uv.y *= 0.5;
float4 texCoord = float4( ( float )idx * uv.x, uv.y, 0, 1 );

※DX10以降(シェーダモデル４）では SV_で始まるシステム値セマンティックスを使用することができて (uint)SV_VertexID が

Mesh頂点の順番に対応しているようなので頂点シェーダ内でUV値の計算をすることが出来るようです。

セマンティクス (DirectX HLSL)

＜Example＞

vert2f vert(appdata_full v , uint id : SV_VertexID)
{
vert2f o;

float2 uv = 1.0 / TextureSize;
uv.y *= 0.5;
float4 texCoord = float4((float) id * uv.x, uv.y, 0, 1 );

赤字の部分がuint型の頂点インデックスIDで代用
}

GLでサポートされていれば便利そうなのですがシェーダの後方互換を保つためであれば、いまはあまり使わないほうがいいのかもとも思います。

ちなみに SV_で始まるシステム値セマンティクス「SV_POSITION は POSITION と同じ値が入っているのはなぜていうかSV_って何？」という質問に

ユニテイの開発者Aras氏「よくわからないけど DX11以降と互換を取るためじゃないかな？」ということで皆よくはわかってないらしい。ちょっと安心？

□テクスチャフェッチでループを使用する時の注意

テクスチャフェッチにループを使用する場合HLSLではfor ステートメントを記述する場合コンパイル方法を制御するパラメーターとして

［loop］または［unroll］を指定することが出来ます。

Unityのシェーダで予約語あつかいで記述出来ないようですがシェーダを移植する際などに留意する点として書いておきます。＜コンピュートシェーダでは有効みたい＞

※Unityではコンパイルが自動最適化されているため［loop］［unroll］2通りの最適化コンパイルをして実行速度が速いほうを選択しているそうです。

[unroll]

for ( i=1;i{

Statement Block;

}

この２つのオプションはコンパイル後のコード記述のされかたが違います.

［loop］指定時はコンパイル後にアセンブラコードでループがそのまま記述されますメモリサイズは抑えられますが実行速度はやや低速となります。

［unroll］指定時はループ内のコードがループ回数分記述されますメモリサイズは大きくなりますが実行速度は高速になります。

このオプションは通常は省略可能ですがループ内でテクスチャフェッチ（テクスチャを参照）する場合は［unroll］を強制すると動作が安定するということです

ちなみにHLSLシェーダでは、ほぼC言語の命令セットとおなじ命令がサポートされているためループにwhileステートメントも使用できますが

この場合シェーダが最適化されませんので実行速度は低下する場合があります。

シェーダの実行速度は条件によるのですが、 最適化された計算時間 [unroll]指定時がPCが100として [loop]ではモバイルで200 xbox360で160 程度に遅延

という参考数値の記述がありました。

シェーダ内でループをするときには、なるべくforステートメントを使用するほうが良いかもしれません。

□テクスチャ化したデータの書き出し

一度データ化したデータはテクスチャリソースとして書き出してしまえばデータ生成の初期化手順を省けますのでデータがだいたいフィックスした段階で

アセットデータから読み出すかたちでシェーダにセットすると良いかと思います。

以下のUnityコミュニティWikiのスクリプトを参考にしてみてください。※Application.CaptureScreenshot を使うやりかたもあるとかないとか

Unity Script Reference-Texture2D.EncodeToPNG.html

ExportNormalmap - Unify Community Wiki

□ExportNormalmap.js

@MenuItem ("Assets/Export Normalmap...")

 static function ExportNormalmap () {
	var tex = Selection.activeObject as Texture2D;
	if (tex == null) {
		EditorUtility.DisplayDialog("No texture selected", "Please select a texture.", "Cancel");
		return;
	}   // Force the texture to be readable so that we can access its pixels
	var texPath = AssetDatabase.GetAssetPath(tex);
	var texImport : TextureImporter = AssetImporter.GetAtPath(texPath);
	if (!texImport.isReadable) {
		texImport.isReadable = true;
		AssetDatabase.ImportAsset(texPath, ImportAssetOptions.ForceUpdate);
	}   var bytes = tex.EncodeToPNG();
	var path = EditorUtility.SaveFilePanel("Save Texture", "", tex.name+"_normal.png", "png");
	if (path != "") {
		System.IO.File.WriteAllBytes(path, bytes);
		AssetDatabase.Refresh(); // In case it was saved to the Assets folder
	}
}

■追記　2014　12.18

文字数制限で入らなかった部分を同時期にアップしたのですが、あまり閲覧されていないようなのでリンクしておきます。

うにばな(シェーダへ配列データの転送マルチUVなど) その2

うにばな(シェーダへ配列データの転送マルチUVなど) その3

うにばな　(シェーダへ配列データの転送) その４　JsonでMayaからUnityへ

□Optimizing Unity Games for Mobile Platforms

ちなみに SV_で始まるシステム値セマンティクス「SV_POSITION は POSITION と同じ値が入っているのはなぜ ていうかSV_って何？」という質問に

ユニテイの開発者Aras氏「よくわからないけど DX11以降と互換を取るためじゃないかな？」 ということで皆よくはわかってないらしい。ちょっと安心？

□ExportNormalmap.js

ちなみに SV_で始まるシステム値セマンティクス「SV_POSITION は POSITION と同じ値が入っているのはなぜていうかSV_って何？」という質問に

ユニテイの開発者Aras氏「よくわからないけど DX11以降と互換を取るためじゃないかな？」ということで皆よくはわかってないらしい。ちょっと安心？