更新履歴0.18.x
0.18.89
内部的 続き 物理的処理の内部的試行
シェーダ版の挙動がC#版に近づきました。
ただし、完全移植ではないので、同じ挙動でもなければ、パフォーマンスの単純比較もできません。
なお、どちらの版でも問題点は残っています。
より具体的には、衝突での想定外の貫通/落下が解消し、不要な跳ね上がりなど、不自然な挙動が解消できるかどうかという段階です。
このような課題が解消できるかどうかにより、全体的な段階を進められるかどうかが決まるものと思います。
全体からするとまだ初期段階です。
余談 VRoid SDK 0.1.3が出たようです。今回Virtueldで対応したい機能や、関連する修正はなさそうですが、無理がなければ今後更新しようと思います。
VRoid SDK 0.1.3同梱UniVRMは0.89.0のようです。VRM 1.0対応などが今後の予定であるようです。
0.18.86
内部的 続き 物理的処理の内部的試行
シェーダ版で、目下の課題の修正が進みました。
その周辺でのもう1つの課題があり、これについては想定通りでない現象を回避する設定に気づきました。
疑問のある回避方法であるので、これがどのようにして起きているか見ていく予定です。
回避設定でのシェーダ版挙動はまだC#版挙動には届きませんが、前進がありました。
水面下のとても小さな範囲に多くの時間を要していますが、今しばらく継続が必要なテーマであるようです。
0.18.79
Entities 1.0.0-pre.44が公開されたようです。
Entities 1.0.0-pre.15に引き続きpreの段階です。移行には課題があるため、メインプロジェクト外で内部的に試行して、様子を見ていくことになると思います。
内部的 続き 物理的処理の内部的試行
前進していますが、引き続き課題解決を試行しています。
0.18.73
内部的 続き 物理的処理の内部的試行
誤りの修正が進み、シェーダ版とC#版の双方に前進がありました。
シェーダ版はまだ挙動が不十分で、C#にも不自然な要素が残っています。
C#版でも課題があります。そのため、シェーダ版は完全移植ということではなく、試行錯誤の結果、一旦不要とみられるものを除いて、必要とする要素を取り出して移植するようにし、挙動の違いを見ています。完全移植ではないので、純粋な意味でのパフォーマンス比較はできません。言語的制約のあるシェーダ版の代わりにC#で先行し、シェーダ版を移植ベースの作業に簡略化できる側面があります。C#ではビルドの反復が遅くなりがちで、シェーダ版ではコンパイルエラーの原因が分かりづらいという、一長一短の関係にあります。
シェーダ版では
開発環境のもとで要素数に対する余裕が感じられます。
少ない要素の処理を効率化するための処理方法の変形についての検討は、C#版よりも厄介である点は今回も体感しています。
シェーダ版ではGPU非同期実行からリードバックが必要である特性上、それ以前のGPU処理が溜まっている場合には、結果の取得までの時間が伸びることになります。そのため予想通り、以下のようなことが言えそうです。
少しパフォーマンスを評価しづらい
実践上のさまざまな処理負荷をかけた場合、スムーズに結果を取得できる流れ(スケジューリング)を作り出せるか未知数
まだ長い工程の途中と考えられますが、一連の試行についてまとまった結果を得られることを目指したいと思います。
0.18.66
内部的 続き 物理的処理の内部的試行
GPU(シェーダ)版の試行として、C#版からシェーダ版へ移植を進めています。
まだ基本的な段階の挙動で問題があるため、誤りを探して修正する工程を続けています。
その中で、理由の特定に苦労した不自然な挙動が1つ解決しました。それはエイリアス(複数の参照が同じものを指す)に関するものでした。この部分は試行錯誤の結果としてそのような記述になっていて、それでもC#側では想定の動作をしていました。しかし、シェーダ(HLSL)側では、想定外の結果となっていたようです。
問題の絞り込みとして、「複製を作って処理、結果を統合」にしたところ挙動が改善したため、明示的にエイリアスを回避する記述に変更しました。
これにより前進が望めそうです。
ただし、今回の焦点の1つになっている、処理速度について、メリットが得られるかまだ定かではありません。相応の負荷がかかることは確認でき、どれほど効果的に処理できるか次第になりそうです。
0.18.54
続き 物理的処理の内部的試行
追加の試行として、GPUでの処理を試しています。
CPUとGPUでは実行環境の要件にまで遡って大きく異なることから、より環境依存度が大きいとは思います。
この案がうまくいくかまだ断定はできませんが、手元の環境でスムーズなパフォーマンスを得られないと物事を前進させにくいため、この方法で成果があれば、その条件下で調整することも視野に入れています。
決定論問題に大きな影響があります。
また、GPUからCPUへのリードバック負荷に関する懸念もあります。
今回の場合、計算量があって演算結果は小さいので、一括処理をうまくスケジューリングできれば、問題ない可能性もあります。リードバックAPIでのバグの話題が検索にヒットし、いつどこまで適正な結果を得られるかには不安もあります。
なお、処理負荷を見るには、必要な一連の処理をある程度まとめて移植する必要があります。
何度かこのような作業はしていますが、コンパイル内容が複雑化しない範囲では、シェーダのコンパイルは機敏で、反復が速いことは嬉しい点です。
一方でC#と比べるとシェーダ言語では、素朴なC言語風の言語仕様による制限、IDE作業上の制限があります。
移植上の記述エラーの修正、定義順序の制約による実装の調整、仕様上適合しにくい箇所では処理可能な置き換え方法の検討が必要です。
このため、作業時間を要しています。
数年前の当初、ECS(Entities)でのGPUリソースとの連携がサポートされる可能性、ECSベースでのVisual Scriptingの計画などで、何か環境を変えてくれると期待させるものがありました。しかし、まだEntitiesは、AnimationやKinematicaなどを含まない、基礎部分のみでこれから1.0が正式になるところです。
全面的なEntitiesというよりは、GameObject併用路線に落ちつているようにも見ます。一方で、そのつなぎ部分(Hybrid)のサポートは少なくとも1.0の段階では減らされる予定です。何かが計画変更されたかどうか、あるいはどれほど実現されるか不明な段階にあります。
そういった段階であるため、まだ遠いと見られるものに関しては、独自の試行もやむを得ないようです。
0.18.41
続き 物理的処理の内部的試行
キャラクター用の物理挙動の置き換え版を試行しています。以下のような状態で、試行初期と比べれば、ずいぶんそれらしくはなりました。まだ初期段階であるため、試行はその基礎部分です。
物理挙動が整っていない場合は、すぐに暴れたり、飛び散ったり、物体同士が重なり合ったりするものなので、そのような状態をある程度、抑えることができたようです。
演算精度: 気になる挙動の要因が演算精度にある可能性を減らすため、自前処理/数学型の範囲内で、通常の単精度浮動小数点に加えて、倍精度浮動小数点での条件コンパイルを可能にするなどしました。
倍精度浮動小数点への切り替えでの負荷上昇は多くないように見えるため、処理内容はCPUキャッシュサイズに対してコンパクトであり、ジョブスケジューリング/演算負荷/反復回数が主要な課題であるように見えます。
処理負荷: 小さいとは言えないですが、なんとか利用できる範囲にあるようです。
ただし、一般的な物理処理と同様に、衝突の可能性が多くなる場合や、安定のために反復回数を増やす必要が出ると、大幅に遅くなる可能性があります。
摩擦: 滑り続ける問題を抑えることへの試行が続いています。
ただし、これは現行公開版でも似たような状況があるため、この部分では導入を見送る理由とはならなそうです。
挙動: まだ実践的な描画ではなく、単純な図形での挙動確認のため、実践的なキャラクター表示の場合に不自然な物理挙動に対してどの程度不自然さを感じるか、今後体感してみる必要はあります。
特性: これまでの試行と異なる試行のため、特徴的な性質/調整項目を含んでいます。
これを活かせるかどうかは、処理負荷や挙動の状態次第といったところです。
段階的に試行段階を進めようと考えています。以前の手法や、既存の挙動と組み合わせたり改善したりといったところも、見てみたいところです。しかし、すぐにまとまった状態にはならないため、段階を経る必要があります。
0.18.31
続き 物理的処理の内部的試行
処理負荷の調整をしてきました。
アルゴリズム上、処理の反復が多く必要であるため、基本的には次のような調整で効果が高いようです。
一時用の動的メモリ確保にて、より負荷の低い方法を選択する。
可能ならばなるべくジョブを統合して、スケジュールするジョブの総数を減らす。
ただし、並列性を損なわないようにする必要があります。
挙動の良し悪しが以下のどちらか、もしくは両方であるのか、断定し難い点は続いています。
アルゴリズム上の限界
物理の処理では解析的に解けない場合に、反復処理で収束させていきます。収束の良し悪しはアルゴリズムにもよりますが、理論的に収束は早いが複雑で演算量が多くて実装が難しいものと、単純だが収束が悪いものがあります。アルゴリズムによる精度と計算量の違い、数値計算上の誤差、並列化の難易度など、たくさんの要素が絡み合い、多くの選択肢が存在しています。
処理の誤りによるもの
公開版の手法と比べて処理負荷と挙動を考慮して上回れば導入できますが、いずれにしてもさまざまな準備が必要であるため、まだ決着させることはできないようです。
準備を進める予定です。
検討 より新しいUnity上での水システム
フォーラムの様子では開発が進行しているように見え、機能もそれなりに充実しているように見えます。しかし、いまのところ何度か行った手元の試行では、視覚的な挙動を見られる状態にできたことがないため、現状では乗り換えに価するか判断できない段階です。
検討 現時点でプレリリース版であるEntities 1.0はUnity 2022がLTSとなるころに正式化する計画であろうと思います。
その前後に Entities 1.0対応が可能か、本格的に試行を進める必要がありますが、そこでは大きな調整が必要であろうと思います。
ほかの検討要素も含め、影響が大きいため次のどちらの方法が選択肢となるか難しいところです。
なるべく公開版を土台として、移行させていく
新たな土台に、公開版の内容を統合していく(当面公開版とは別として)
両方の試行を進めた結果、段階的に両者の区別がなくなっていくという可能性もあります。
0.18.23
続き 物理的処理の内部的試行
処理負荷の改善の試行として、細かな最適化を試行していました。
命令レベルでの検討のため、何が最適であるかはCPU毎に違います。そのため、特定の手法が常に改善につながるとは限りません。
見たところでは、BurstCompile対象のC#コードのうち特にUnity.mathematicsの型でない部分ではAVX/AVX2(が有効な場合でも)特化したアセンブリになるわけではなさそうです。どれが最速であるかは単純に見分けはつきませんが、前後を考慮して処理方法を変えると部分的には改善する場合もありそうです。
この視点では、Aspectの中にある処理やUnity.mathematicsの一部処理も置き換え対象にすることも考慮に入ってきます。 処理速度以外にも演算精度/決定論などにかかわる可能性もあり、プロジェクトの内容によっては、まるごと処理を置き換える開発者もいるのでしょう。
とはいえここまでの試行範囲では効果は小さいようであるため、処理負荷の改善としては別の方法を進める必要がありそうです。
0.18.16
続き 物理的処理の内部的試行
基礎段階の確認では、より狙いの挙動に近づいたように見えます。ただし、安定した結果を得る設定では処理負荷が高く、アルゴリズムや最適化での大幅な改善が必要です。
まだ導入に至るかどうか確実ではなさそうです。演算量が多く、ここではまだ踏み込んでいない決定論ではない浮動小数点演算を、桁違いに遅い決定論ありの代替処理に置き換えるような余裕が見えないことも感じられます。
理想的 ハードウェア規格の何かの事情が変わって、決定論が簡単に得られるようになること→仮に起きてもすぐに普及するわけではない。
現実的 同一アーキテクチャのみでの決定論に限定する→対戦可能相手の限定→特定方法?
0.18.7
続き 物理的処理の内部的試行
想定に近い挙動が見えてきました。
ただし、まだ以下のような必要なことがあるため、一進一退する可能性はあります。
まだ汎用的な処理が不足している
処理速度などの改善が必要
実践的な状態でない部分もある
0.18.5
続き 物理的処理の内部的試行
修正と改善により、想定する挙動に一歩近づきました。
まだまだ基礎段階のため、活用できる状態になるか不明です。これまでの類似の試行の中ではもっとも、細かい処理に踏み込んでいます。課題が見つかった場合に再調整しやすい方法ですが、安定性や処理性能を引き出すことには難しさを伴います。
0.18.0
マイナーバージョンを引き上げました。
そこで少し状況を整理しておきます。
パッケージ規模での中期的作業想定(順不同)
Discord GameSDKで予定される多くの機能廃止に対するオンライン関連の見直し(大きな変更)。
UniVRMの更新。ただし、VRoidSDKの進展次第。
VRoidSDKの進展次第の対応。
今後リリースの可能性があるEntities 1.0対応への検討(大きな変更)。
Unity 2022以降への更新試行。ただし、Entities 1.0に対応した場合のみ。
これらはすぐに着手できる内容ではないため、続行中の内部的試行を続けます。
内部的試行について、作業テーマが切り替わるか、統合/保留の結論が出るまで継続したい考えです。
このため、いましばらく表面的変化が少ない状況が続きます。