phi16です。Amebient Advent Calendar 7日目、今回は延々と描画の話をする回です。

食器とかビルはまぁいいとして、あの世界にある見えるモノそれぞれについて、書きます。今回はシェーダ系100%のお話です。

( 続きもあります: Amebientの世界描画2 )

Render Queue

まず水がテーマの一部である点で半透明的物体は必須です。描画順が最悪になることはわかりきっていたので最初から管理は徹底していました。

Overlay+1: Overlay (OverlayGrab)
Transparent: Font
Transparent-519: DropDisplay
Transparent-520: InputBoard
Transparent-525: Air, DropAir
Transparent-527: DropRain
Transparent-528: Thunder
Transparent-529: FallRain (RainGrab)
Transparent-530: Surface
Transparent-534: Bubble
Transparent-535: Ocean
Transparent-536: Underwater (SurfaceGrab)
Transparent-540: Skybox

最終的にはこんな形になりました (メモに書いてあった)。これはいろんな制約条件から導かれた結論です。

depthのある物体で空を覆わないと元来のSkybox (Transparent-500) が上書きしてしまうので、その前に空を書き終えなければいけない
AlphaTest (Transparent-550) よりも後に半透明系の描画を開始しなければいけない
その他相互関連
- 空 (Skybox) は全てに映るので当然最初
- 海面 (Ocean) は水中 (Underwater) より後に描画しないと ZTest Off によって上書きされる
- 海面 (Ocean) は泡 (Bubble) より先に描画しないと泡が消える
- 食器の水面 (Surface) は雨粒 (FallRain, DropRain) を通過させてはいけないので ZWrite On にして先に描画
- 食器の水面 (Surface) を見るときは原則として海 (Ocean, Underwater, Bubble) を見ていないので GrabPass を共通化して良い
- 降雨 (FallRain) は海や水面を屈折させるので新たに GrabPass が必要
- 雷 (Thunder) が落ちる瞬間ははっきり見せたいので降雨 (FallRain) よりも後
- リズム用の雨 (DropRain) は雷 (Thunder) より重要なのでさらに後
- 加算合成系 (Air, DropAir, InputBoard, DropDisplay) は最後にする
- 視界へのエフェクト (Overlay) は全ての描画の最後

これでも解ききれなかった制約がいくつかあります。

海中でも食器の水面が見える
- 水が張っているのがわかりやすいという機能的側面で解釈することにしました。
水中から雷が見えすぎる
- 描画順ではどうにもならないんですが直接計算してしまえばまぁ…？
水の張ったバケツに入っても水中っぽくない
- これをやるには「視点がどこかの水中」であることを調べなきゃいけないんですが厳しい。
水の張ったバケツに入ると雨が見えない
- 描画順では無理、判定するのも厳しい。

まぁ、許容範囲というところです。

では各々の解説をします…。機械系 (Font, DropDisplay, InputBoard) と水面 (Surface) はそれぞれ別の日に書くことにします。

Hierarchyはこんな感じ。動的制御が多く入ってるDropRainとDropAirはMechaに属していて、それ以外はEnvironmentです。まぁ別に何が正解というわけではない。

えー、では… 簡単そうなものから順にいきます。

Overlay

雷に合わせて暗くする・画面を揺らす
respawn時の暗転
ポスプロの代行

を行います。

雷が鳴るまでの時間・鳴ってからの時間を ThunderTime として受け取り、それに従ってGrabTextureを拾うUVをいい感じに揺らします。雷の強さというのが一応あって、定期的に鳴る雷は世界遷移の雷よりちょっと弱いです (あと海だともっと弱くなります)。float2(cos(a), sin(a)) * exp(-r*3) * exp(-t*4) * 0.03 みたいな感じらしいです (aとrは乱数、tは経過時間)、移動量がexp付きのランダムになってるとなんだか「揺れ」って感じがするんですよね。あとは時間に関する指数関数的減衰ね。ちなみにちゃんとGrabTextureのアス比は合わせてます。あと暗さの方は単純な指数関数的減衰ですね、はい。

respawnの暗転はUdon制御のパラメータを乗算しているだけです。Amebientはある高さまで落ちると以後respawnが確定するようなマップになっている¹ので「段々フェードアウトする」をするのが比較的容易です。これだけならシェーダだけでも良かったんですが、フェードインをする為にはUdon制御が必要でした。

respawnにフェードが入ってるのは、まぁ「見える世界を連続にする為」です。急激な変化は基本的に嬉しくありません (それを期待しない限りは)。加えてAmebientだと水中だったので「段々何も見えなくなる」のはとても自然なんですよね。逆に空の世界だと段々白くなっていくとかが自然なのかしら。
それはそうと、あのフェードアウトは「死」の印象を持っている部分もあると思います。それによって飛び込みの「仮想上の重み」みたいなのが現れてる気がするのです、水中だとゆっくりになりますし…。ちょっぴり悲しいけど穏やかな死です。Amebientの雰囲気に合っていると思ってます。

ポスプロについては… 最初は普通にPostProcessingStackV2のVignettingとChromaticAberrationを使っていました。でもどうやらPimaxだとこの影響が強すぎるっぽいのですね…。特に左目右目での位置による効果の差が大きいと言えます。
それを確認して、これらについては自前実装をすることにしました。#if defined(USING_STEREO_MATRICES) で分岐を取って、VR上だとこれらの効果を掛けないことにしています。写真には載って欲しいんだけど視界には邪魔なこと、そこそこあるんですよね…。

Amebientのバグ修正をしました: 第一関節の無いアバターの指をコンソールが認識しない点・VRの視界で色収差が過剰なことがある点　よろしくおねがいします pic.twitter.com/XqCmyOxmuf
— phi16 (@phi16_) July 30, 2020

公開のタイミングからはちょっと遅れてしまいましたが、対応出来てよかったとは思います。…本当にどうしようもないデバイス依存ケースではなくて良かった…。スクリーンショットをお願いして撮って頂いたリリーヤマユリさんに感謝です。ちなみに自前でPimaxの視界シミュレータを書いたりもした。

左目と右目で分岐していい感じに表示するやつ。パラメータは正直わからんかったので眼で調節しました。これで初めてどうなってるか知ることが出来た。検証環境、だいじです。

Air

このふわふわ浮いてるやつです。

空間の奥行きと恒常的変化と湿度感の強調が主な役割で、加えて風の強さを表してたりもします。世界遷移するときに急激に速くなったりしてるんですよ。

実装は…65536頂点のメッシュをいい感じにシェーダでパーティクルにしています。よく言うアレです。ただ色々細かいことはしていますね…。

メッシュはエディタ拡張製で、boundsが予め巨大化されてる (カリング防止)
ソフトパーティクル (壁から唐突に現れないようにいい感じにする) の実装
- 海に対しても似たように振る舞う
- あとカメラに近すぎてもフェードアウト
ランダムサイズ (rand)・ランダム移動 (noise)
微妙に上下方向にグラデーションが入ってる (立体感が出る)
一定範囲で繰り返しにすることで「常に自分の周囲に表示」を行う (無限に出てくるようにする)
- 半分は(20,10,20)、もう半分は(40,20,40)で繰り返すことで自分周辺の密度を上昇
- ついでに遠景系のほうが浮上速度が速い

動かすのに使っている時間のパラメータは_TimeではなくUdon制御で、後から速度を変えたりしやすくなっています。ただ世界遷移時の急激な速度上昇はこれではなくTransitTimeっていうパラメータを使っていて、これは世界遷移が始まる瞬間に値が不連続変化します。これはどういうことかというと世界遷移が始まる瞬間、粒の位置が変わるということなんですが、多分気づいてる人は誰も居ない (私も気づいてない)。

終わる時だと気づくかもしれないな、と思ったのでデフォルト値が「遷移終了の時間」になってたりします。

パーティクルの作り方についてはそういえばソースを公開していたので観たい人は読んでください。Airのソースから色々抜いて上下の移動方向変えただけなので。

Bubble

役割は水中におけるAirです。海中だと空気はこういう形をとるということで、加えて少しだけ音の説得力をもたらしていますね (でも本来はもっと激しく振動するんだと思う)。

実装もほぼ同じですが、繰り返し単位は (40,40,40) と (30,30,30) を使っているようです。あと大きな違いは勿論見た目です。

reflectionが入ってます。泡ってそういうものかなと思ったので。UVからローカル法線を擬似的に計算((uv.x,uv.y,-sqrt(1-dot(uv,uv))))して、パーティクルを生成する際のnormal, tangent, binormalを用いてワールド法線を算出しています。

まぁ、こんな近くではフェードアウトするようになってるんですけどね…。中心からの距離dに対してpow(d,3)でalpha載ってるし、ほぼリングみたいなもんになってます。多少立体感はあるかな。

DropAir

これは楽器から出てきた空気粒のこと。

役割は演奏と世界変化の因果を結ぶモノです。楽器を鳴らすと空気が生まれ、それが空に浮かんでいく。それによって空模様はどんどん悪くなっていく。そんな気持ち。

直接的に示すよりは雰囲気で持って行きたかった。気づいたらめっちゃパーティクル出てる、くらいの認識を意図しています。それまではきっとAirと混ざって区別できない。

えー、このパーティクル群はCustomRenderTextureで位置制御されてます。WaterServerというUdonが要請することで、衝突位置に新たなパーティクルが発生。各点はcurl noiseと適当な力場…最初は+Z方向、段々+Y方向に強まる力、に従って動いていきます。

急に生えてくるのは先の意図と反するので、出現後8秒程は大きさが0になっていて段々大きくなり、逆に50秒以降段々小さくなっていきます (どうせ遠いので)。

あとそういえばFanAirという名前でファンが回ってるときにもパーティクルが飛ぶんですが、まぁ同じ仕組みなので特筆することは無いかな？あっちはファンの付近だとちょっと加速するようになってますね。ちなみにMaterialは分かれてます。この子たちの元となるメッシュは1024頂点ですね。

風にいい感じに乗ってる感じにするためにそこそこの調節時間が掛かったんだけどあんまりそういうのは解説には書けないのよね。まぁ。

FallRain

リズムを持たない雨です。

役割は恒常的変化と、雨の強さによる空気感ですかね…。最初は穏やか、段々強くなっていって、世界遷移の時にはめちゃくちゃ激しくなります。

指定された強さに応じて量が変わる
世界遷移の時だけ色が付く
床(または海)に到達すると波紋になる

床に到達したかどうかは予めBakeされた空から見た建物の高さマップを使っています。これのことですよ。

青成分が距離を表しています。これによって距離が判定でき、そして赤と緑成分の表す法線方向²によって「傾いた床」に対しても正しく波紋を出すことが出来ています。

現在地点が床より上なら「水滴」としてメッシュを構成 (軸固定ビルボード・疑似法線)、床より下なら「波紋」として構成 (床と法線が一致するQuad) しています。

あと波紋が床の大きさをはみ出るのはなんか違うと思ったのでここではソフトパーティクルの逆をやっています³。床のあるところにしか表示させない。

微妙にフェードアウトしているのが見えますね。

あとは… 前と同じ繰り返し方法で「自分の周り」に描画していると自分が建物の中に居る時にほぼ屋根に遮られてしまうということが起き、奥の雨がほぼ見えなくなってしまいます。そこでFallRainの半分は建物周辺専用、それ以外は建物周辺以外専用として扱われ、前者は自分の位置に追従せず、後者は自分の位置に追従しつつ建物周辺では描画されません。これによって密度がほぼ一定な感じになります。

そしてシェーディングの話。原則としてそんなに主張しないことを願っていて、それは世界遷移のときの衝撃を持ち上げる効果にもなります。空間に溶け込んでいた物が「現れる」。

だから色味は持たなくて、やるのは弱い屈折くらい。ただそれだけだと本当に溶けちゃうので、色を1.3倍してます。それでちょっと明るく見える。

元々「波紋」というのは水の記号化だと思うので、それに相応しい主張度になったのでは、と思っています。この世界では抽象がそこそこ実在を持っているんです。空気もそうね。
よく言うように水滴は現実世界では縦長ではありません。見えているのは速度を持った水滴の抽象です。そしてそれをそのまま作ることは、この世界では合法だと思うのです。

一応水滴の終端速度とか調べたんだけどまぁ無視していいか、ということにしたのよね。

Thunder

今見ると正直もっと頑張りたかったなと思う。

雷が落ちることになったので雷を作らなきゃいけませんでした。だから役割は在ることです。

これの制作の話は実は日記 0706 で少し解説をしていて、付随情報とかも色々載ってるのでまぁいいんじゃないかな…と思ったけど、少し書きます。

まずある点からある点へ落ちる雷。私はよくあるフラクタル地形の作り方をベースに考えました。

現在の線群の各中心点を、その線の移動方向と垂直な向きに適当にずらす。この時線分の長さを移動量に乗算しているので段々移動が落ち着いていき、ランダムっぽい曲線になります。多分もうちょっとこれには調節の余地があって、分岐点は中心よりも天に近いほうが良かったのかもしれない…？わからないけど。

これをいくらか繰り返してメインの雷が出来ます。そして加えていくつか、メインの雷とその周辺のどこかの点を結ぶ雷を作ります。同じ方法です。そしてそれが終わったらそれらのどこから…という感じ。データの格納は0番地から順番に行っているのでランダムの範囲を広げるだけで「メインの雷」「サブの雷」の選択を同時に行えます。

ちなみに内部バッファ (の可視化) がこれです。DropAirのCustomRenderTextureと共通です。

雷が出現する32拍後 (または32拍前) に更新されるのがよく見るとわかります。雷の形は完成するまでいくらか時間が掛かるので、絶対に安全になるように半周期ずらして計算を開始しています。

近くで見るとこんな感じ。ただのカプセルのビルボードの集合体です。交差点が光りすぎないようにしなきゃいけないので好き勝手な色出せないんですよね…。そこそこ色を高めに出力しているのでBloomの影響でちょっと光った感じにはなってます。でも本来はもっと大きなメッシュにして自前で光らせるべきだったんでしょうね…。

世界遷移のときの雷は建物に一番近い電柱に落ちるようになっていますが、周期的に降ってくるやつはランダムにどこかに落ちます。衝撃的であってほしいときはその効果を持ち上げるために近く強く。それ以外はゆるく存在させたいので、逆に一番近くの電柱には絶対に落ちません。

常に同じところに落ちるとあまりにも予想出来すぎるわけですが、見た目的に中央付近の電柱に一番落ちそうだと思ったので、7割の確率でここに落ちるようになってます。他は一様です。

この辺の解釈は…難しいですよね…。完全に筋が通っているわけではないです。

ただ、あの鉄塔を中心に雲が渦巻いているという事実がまずあるはずで、そうすると鉄塔の特異性が推測されるところ。何故鉄塔に雷が落ちないのかというと「落としても距離が短くて面白くないから」なんですけど、意味としては「鉄塔から離れるように電子群が降っていく」のだとは思っています。そして電柱に当たって、電線を伝う。本来ならそんなことは起きないとは思うんですが、線は繋がっているので、まぁ許されないこともないと思う。現実の機械をそのまま使っているわけではないのですから。

私達の起動した機械の信号はあの因果の線を伝って鉄塔に届き、そして各ビルに届いて、鐘を鳴らし始めます。そういうことになっています。

続く

ここまではアレです。おまけです。

Amebientの世界描画2

Amebientの世界描画2 https://t.co/Ba8vnEe4kZ
— phi16 (@phi16_) December 6, 2020

そうしてもらった ↩
このモニタはabsした結果を表示しているものです ↩
厳密にはgroundDepthを使ってるのでちょっと違うけど本質は同じ ↩