Cubism3でFaceRigデータをつくるとトラブル続出するという噂を聞いて
表示周りではどんな問題が残っているのか、Aviutlのプラグインを作るのにあたって用意したRendererテストモデルを使って調べてみた。
モデルの形状とそのテスト目的
A:マスクのカリング
マスクを作成するときに前のArtMeshのかリング形状を参照してしまうバグをチェックできる。
B:キーロストによるマスキング
こんな感じのキーが無いパラメータ領域で表示が消えるArtMeshをマスクに割り当ててるときに最終の計算結果を参照してマスク生成してしまう。(エディタ的には適正だけどリファレンス的にはバグ
C:テクスチャの切り替え
マスク生成のときにテクスチャの切り替えを忘れていると表示が乱れる
D:描画順ソート項目のチェック
ややこしいことにRenderOrderとDrawOrderという項目があり間違えると双方変化する
正しいと1番だけ変化する
パーツフォルダのグループ化で内部のソート番号はフォルダの値を見るのに
正しくない方の値はArtMesh描画順を見ているために問題が発生する
E:複数のキーロスト
キーロストの複数版
F:半透明マスク
アルファ値で生成するのが正しいマスク生成なのだけど、
ステンシルバッファでマスクしていると真ん中の重なった部分がわからなくなる。
不透明度を0にしてそこのテストもしておきたい(忘れてた
G:マスクの非出力
出力時に非表示になっているとマスクの指定番号が-1になって
対策をしていないと不正アクセスでアプリが死ぬ
H:背景に対する描画各種
背景に対して、通常(不透明度操作)、通常、加算、乗算の描画を行う。
アルファ値が0の背景に描画すると加算、乗算は描画先の透明度を引き継ぐので消えてなくなることになる。
なんかしらのバッファを介していると起こる。
I:色合成、加算乗算
加算乗算での透明度の計算方式を確認する。
上の段が通常描画で下の段が加算や乗算。
グラデーションの進み方が一致するのが正しい表示。
間違ってると黒背景内や白背景内でズレる。
FaceRigでテストしてみる
ちょっと解像度の低いGifですがいろいろ問題が確認できますね。
-1,Aマスクのカリングは間違っているようです。
-2,Hどこかでバッファは経由してるみたいですね
-3,Iあと加算合成に問題があるようです
FaceRigのCubism3はもともとCubismNativeComponents(Github)を参考にして作成したと言われていて
1,3の問題は4/20のコミットの時点はCNCでも残っていていました。現在の最新コミットではなおっています。
本当にCNCから作成している場合は更新を適用したらいろいろ治りそうですね
4/20の時点ではCのテクスチャでも問題が起きたはずなのでここだけ直されてる形ですね。
2の問題はもともとバッファを経由するシステムみたいでどうしようもないみたいです
Cubism2.1コンバート(同2018/06/21テスト)
Cubism2.1にモデルを加工して突っ込んでみました。
-1,D描画順グループが解除されていますがCubism3の機能なので仕方ありません。
-2,Fマスクはステンシルバッファを使用しているみたいです。
-3,G存在しないマスクはマスクの情報自体が削除扱いになってクリッピングが解除されるようです。
Cubism2.1ではレンダリング部分までSDKに含まれて内部が見えないため
こちらは特性としてしょうがないところもあります。
まず目につくのは2のステンシルバッファを使用している点でしょうか
薄いマスクを掛けたいときはこの機能がつかえません。
余談ですがCubism2.1Editorでこのモデルを見るとIの色合いのところは加算がずれます。
Cubism3モデルがめちゃくちゃ大きくなる問題について
出力時にPixelsPerUnitという値を設定しますが、FaceRigはこの値を考慮せず、もともとの頂点情報で描画しているみたいです。
詳しくはLive2D SDKマニュアルのこのあたりを参照
トラブル回避
マスク時の前カリング設定問題
マスク指定のときに前のカリング設定をもらってきてしまう問題
描画順をコントロールすることで直前に好きなArtMeshを持ってこれるので
余計な設定を引き継ぐ前に当たり判定などを差し込んで設定を意図的に持っていってもらう回避方法がある。
よくわからないときはカリング自体を使わないのが一番安全
加算の色合いがおかしい問題
明るめのところから更に加算時には難しいですが
アルファ値で代用できるケースもあります。
ペイントソフトで乗算の色合いと透明度の色合いを並べて変色させて適用させます。
これもよくわからないときは加算を使わないのが一番安全
反応あったら追記とかするかも