しゅみぷろ読者になるしゅみぷろプログラミングとかこの広告は、90日以上更新していないブログに表示しています。まとめ(2日目)UnityはじめにUnite2日目で自分が聴講したものについてまとめます。個人的に興味深かった講演については後日もっと深く掘り下げようと思っています。今回は大雑把にどんなことをお話しされていたか等を残しておきます。講演の資料はこちらからDLできます。雪の世界を表現するためのグラフィックス処理についての講演でした。素晴らしい講演でした。参考になる部分が多く、グラフィックス勉強中の身としては大変ありがたいものを聞かせてもらったなぁと。内容もわかりやすく、Twitterでも評判がかなり良いようでした。描画設計マルチプラットフォームなので性能の劣る方を基準に設計したそうです(Vita基準)。カラースペースはガンマ。Vitaがリニアに対応していなかったためです。Deferredは処理負荷やVRAMが心配ということでForwardRenderingを採用。ライティングは基本的にEnlightenを採用。リアルタイムのライトはエフェクトなどの用途でしか使わないようにしたそうです。Mipmapは基本的にOFF(視点が大幅に変わることが少なく、レベル変動が少ないため)。シェーダーはUnity5のStanderdを改良していく形で、PassはForwardのみ。シェーダーはテンプレートを用意してGUIで自動生成する仕組みを作ったそうです。「カメラでレイヤー分けして任意のRendererを描画する」場合に、レイヤー分けが必要になり、描画以外の目的で使用する場合に扱いづらいので、ReplacedShaderを活用。普通のシェーダーとReplace用のシェーダーを作り、Replace用シェーダーはReplaceしたいシェーダーのSubShaderを全て書いておき、必要な時にカメラで描画する内容をReplaceするようにしたそうです。Replaceシェーダー(あるいはShaderの基本項目)に関してはこちらで紹介しています。雪面凹み歩くと雪面が凹むアレの表現方法です。fetch)でテクスチャを参照し、凹ませるべき部分の頂点を弄ると、おおまかにこんな感じ。PS4の場合はTessellationShaderで雪面のジオメトリを細分化し、よりリアルに雪の凹みを表現しています。Field:被写界深度)パーティクル降雪を表現するパーティクルで、画面に近い雪がぼやけて見えるのを再現するために作成したもので、単純にtex2Dlodで読み取るMipmapのレベルを逆方向にしただけです。RendererMergeシーンの最適化で行った処理で、特定条件下(同一マテリアルを適用できる等)のオブジェクトのMeshを結合してしまうという最適化です。エディタ拡張で特定条件下のMesh群をMesh.CombineMeshesで結合します。enabledがtrueになってしまい、設定できないため、Sceneに埋め込まれたMeshを一旦FBXで出力し、出力したFBXを再度prefabとしてインポートし、設定を変更したようです。消費も多くなることが問題です。この問題を解決するために生み出されたのが頂点ライトマップだそうです。頂点ライトマップでは、ライトマップの色を頂点カラーで保持しておくことで、シェーダーからライトマップテクスチャを使わなくてもいいようにする技術です。頂点のUV座標(MainTextureではなくライトマップ用のUV)から利用するライトマップのカラーを抜き出し、それを頂点カラーに設定するといったようなフローで行われているのかなーと。GIFT”見応えのある素晴らしい映像作品でしたね!こちらで公開されています。Unityでここまで出来るのかと、正直圧倒されました。AlembicAlembicなるデータフォーマットを初めて聞きました。大量の球の描画、どうやってるのかなぁとすごく気になっていたんですが、こんなこともできるんですね。Alembicは時間(インデックス)におけるジオメトリの情報を保持する感じっぽいです。ImporterAlembicをUnityで利用するためのツールで、ジオメトリにUnityで作成したMaterialを適用する形でAssetが完成します。CapturerGameビューの描画内容をキャプチャしてファイル出力します。よってデータのインポートと絵の出力を行ったようです。大波エフェクト波のジオメトリとアニメーションを作成し、AlembicPointCacheなる、おそらくインデックスにおける頂点位置のみを保存したもの(?)を用意し、ポイント情報はテクスチャに格納しておきます。大量の球はPseudo-Instancing(擬似インスタンシング)で効率的に描画するようにします。頂点シェーダーでポイント情報のテクスチャから球の位置を決定し、描画させます。Pseudo-Instancingでメッシュをできるだけ詰め込むために、球は頂点数をできる限り削減したICO球が使われていたように思います。これをそのままレンダリングすると、球は角ばって見えてしまうので、Smoothingなるピクセルシェーダーのトリックで綺麗な球に見せているらしいです。~2D機能のあれやこれや~新しく追加予定の2D機能のプレビューです。こんなことまで出来るのようになるのかと驚きました。タイルマップに関しては本当に驚愕で、本当に最高にクールな講演でした。9スライスSpriteRendererによるタイリングが強化されました。引き延ばすだけでスプライトがいい感じにタイルするようになったようです。グリッド機能Isometricなどの配置にも対応しているタイル配置用グリッドです。Isometricツール等でこういったグリッドが使えますが、それよりもかなり便利そうな印象。Swizzleによってグリッドの軸方向を変更できるようです。タイルパレットタイル配置用のパレットで、ここにタイル用のSpriteを登録し、色味などを変更したりできるようです。このパレットに登録されたタイルをグリッドで分割されたSceneにぽんぽんと配置していく感じでステージなどを構成できます。登録するタイルはスプライトのアニメーションにも対応しています。プログラマブルタイル詳細はわかりませんが、タイルにスクリプトを追加できるようです。デモでは、壁や進行方向を自動算出していい感じにタイルを配置するスクリプトを用いていたようです。これはすごく嬉しいですね!マルチシーン編集の使い方Unityのシーンおさらい複数シーンがロード可能ロードされたシーンはメモリ上に展開されるUnity5.3まではシーンは1つのみEdit可能Unity5.3から複数シーンのEditが可能になった必要に応じてロード・アンロードが可能に。実行時にシーンを扱うクラスができた。Applicationクラスを使わない。メリットとしてはシーンを細かい複数の単位として使うことができるランタイムで複数のシーンを効率的にロード・アンロードする仕組みによっており汎用性あるシーンの構築が可能になる。複数人のシーン編集によるコンフリクトを避けることができる(デザイナー用・アーティスト用などのようにシーンを分けておくことで回避できる)。Activeなシーンはヒエラルキーに太字で表示されるようになります。MultiScene実装に伴う拡張Lightingライトのベイクは複数シーン一斉にできるようになっている。NavMesh複数のシーンでNavMeshを適用できる。新しいAPISceneManager(Application....にかわるAPI)を利用して必要なタイミングで必要なシーンをロードしたりアンロードしたりすることが可能になりました。特定のコンポーネントやゲームオブジェクトを含むシーンがあればそれを全て(あるいは条件を設けて)ロードするなども可能です。シーンの利用ですが、DontDestroyOnLoadを使うより、あるシーンを作ってその中にマネージャークラス等をぶっ込んで、それをゲーム開始時や必要な時にロードするといった使い方もできます。例外的にこれらのクラスが不要なシーンなどができてもアンロードすることで消し去れます。supportシーンAのオブジェクトがシーンBのオブジェクトを参照するというのは、Editorではきないけどランタイムではできる(実行時に取得するだけでいい)らしいです。Editor上では静的なデータなので、2つのシーンが同時にロードされているとは限らないためです。Unityとアセットツールで学ぶ「絵づくり」の基礎(ライト、シェーダー、イメージエフェクト)とても充実した内容の講演でした。このあたりをサクッと勉強しておきたかった内容なので、個人的に大変ありがたかったです。「作為(チーティング)」とは観客におかしいと気付かせない程度に、実際のモチベーションに意図的に細工を加えることコーネルボックスを通じてGI(グローバルイルミなーション)を知るtsubakit1.hateblo.jpコーネルボックスはGI研究のために使われていたもので、もともとはRaytraceの出力と実際の写真を比較するために使われていたそうです。色は各電磁波がマテリアルに当たりディフーズ反射を行う際に、波長ごとにフィルタリングされます。光にその波長が含まれなければその色は現れることはないようです(たとえマテリアルがその色を含んでいても)。色は塗るものではなく光によって現れるものであるという感覚が大切です。光は足し算で混色されるので、補色を合成すると白の光(全ての波長が含まれる光)になります。光の加法混色は補色関係などを考慮するようにします。各ライトの減衰率にも注意が必要でDirectional:減衰なしPoint:減衰中Area:減衰大となっていて、物理法則に最も近いのはAreaライトだそうです。GI:ベイク用のライトのライトマップの精度を設定するEnvironmentLighting:アンビエント光の設定ができる。Occlusion)を追加するといったことが必要になります。GICPUパワーに依存デスクトップ・コンソール向きエリアライトが使用できない物理ベースシェーダー(PBS)物理的に正しいシェーダーのことです(入射光以上の明るさを物体が反射することはありえない、エネルギー保存則が破綻しない)。光のシャープさが維持され、全ての光線が散乱せずに反射するで表現されます。サンプルは上のリンクから。)はてなブログをはじめよう!es_programさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。