v3.0.0b1
ベータだけどとりあえず出した。
🦀についてはQiitaの記事を参照 qiita.com
動機
🦀は雑に言うと「ベイクする機能」+「ランタイムで動かす機能」という構成で v1は「Unityのライトマッパー」+「U#」という感じで、 v2でベイク側をリファクタして「Unity or Bakery」 + 「U#」にした。
ランタイムはU#オンリーだったんだけど、こっちも
というような気持ちは前からあって、VCCとU#1.0でようやくPackageとしての開発環境が整った、という感じ。
概要
Kanikamaを複数のモジュールに分割して、モジュールの一部をユーザーが自前のものを使えるようにした。
- Kanikama.Core: Unityでライトマッパーで遊ぶ時あると便利な細かい実装が入っているところ。これ自体にビジネスロジックはない。Utilityとかにリネームするかも。
- Kanikama.GI.Baking: UnityでPrecomputedRadianceTransferをやるためにライトマップを沢山焼いてTexture2DArrayを作るBakingPipelineの"実装"。
- Kanikama.GI.Runtime: BakingPipelineが生成したアセットをランタイムで動かすための"実装"(通常のC#、Built-in/URPが使える)。
- Kanikama.GI.Bakery: BakingPipelineのBakery版。Pipelineはほぼコピペ。
- Kanikama.GI.Udon: GI.RuntimeのU#版の実装。VRC SDK、U#に依存する。
という感じになっている。
v2までの🦀ではBaking/Runtimeがくっつていたけど、ここを頑張って分離した。 結果として、ランタイム側の実装(Kanikama.GI.RuntimeやKanikama.GI.Udon)はライトマッパーやBakingPipelineのことを気にしなくてよくなったし、 BakingPipelineの開発中はU#のことを気にしなくてよくなった。
User Custom なんとかって?
User Custom BakingPipeline / Runtime
「動かないQuadライトの(例えばLTCで計算した)スペキュラーに対して、シャドウイングをしたい」みたいな状況になったとする。
こういうときに、シーンを真っ暗にして、白色のQuadライトを直接光だけでベイクしたライトマップがあれば、影がないときのirradianceはLambertの計算(LTCのdiffuseのときのやつ)があるので、
(影あり)/(影なし)
を遮蔽の近似として使えるんでは、みたいなことが思いつくわけだけど、
こういうときに、ライトマップのベイクやらなんやらを自前のBakingPipelineとして実装したくなる、というか自分はなったことがあり、そのときに🦀のコードが使えなくて悲しい気持ちになったので、
今回は使いまわせる部分は使いまわせるような設計にした。
自前のアセットを作ったら、ランタイムの実装も勿論自前である。がんばって!
User Custom Kanikama Pipeline
Baking PipelineまではKanikamaを使うけど、ランタイムの実装は自前のものを使うよ、というケース。 Kanikamaはもともと可能な限り汎用的に使えるように設計してきたつもりだけど、汎用性とパフォーマンスの板挟みになるケースがちょいちょいあって、割と頭を抱えることが多かった。
例えば、Kanikamaではモニターの色をシェーダーに配る時にCameraでレンダリングした後にReadPixels/GetPixelsを使ってC#側にColor[]
を持っていったあとにシェーダーに配っているけど、
これはモニターの枚数がわからないからやっているだけであって、モニターが1枚ならシェーダーでRenderTextureをmipmap指定して読みこんだ方が速いし、この形ならshaderだけでGIが実装できる(例えば、clusterでも動く)。
v3では開き直ることにして、Kanikamaが提供するランタイムの実装は"ひとつの実装例"という立て付けにして、不満がある場合はランタイムの実装だけ分離できるようにしたので自分でやってね、という感じにした。
余談だけど、
Kanikama.GI.RuntimeとKanikama.GI.Udonではモニターの実装が違っていて、前者ではTexture2D.GetRawTextureData
を使っているのでU#よりも速くなってたりする。
User Custom (Udon) Light Source
ランタイムもKanikamaに乗っかるけど、自前の光源を追加で使いたいよ、というときはコンポーネントレベルで実装を加えられるようにした。 U#も抽象クラスをサポートしたので、こういうことができて良い。
所感
実装はシンプルになったけど、使う側からすると複雑さが増したんでは、という感じがする。やっていることが複雑なので、もうエンジニア向け(というか自分が使う用)のライブラリということでもいいかな~という気持ちに・・・