What's New In 1.2.4
エンティティフィルター
高速エンティティフィルタがついに登場しました。それに伴い、エンティティイテレータの動作方法が大幅にリファクタリングされました。
- 有効なエンティティスロットと空きエンティティスロットの両方のメタデータは、二重リンクリストに基づいています。 これは、すべての操作が最適であることを意味します:create/destroyはO(1)で、
Frame.GetAllEntityTypeXYZ()
はO(a)が保証されます。ここで、「a」はそのエンティティタイプの有効インスタンスの数です(以前はすべてのスロットが有効なものを検索していました)。 Frame.FrameFilters
は、エンティティタイプグループを表現するためのオプションを提供します(ドキュメントは こちらです)。エンティティイテレータで使用されるのと同じ最適なトラバーサル実装を使用します。Frame.GetAllComponentXYZ()
は廃止され、バッファ割り当て(プール)を含むわずかに異なるAPIを使用するので、Entity Filtersを使用することをお勧めします。
また、フィルターは単一コンポーネントの反復子よりも多くを表現できます。 事前に構築されたコンポーネントにデフォルトのものを追加しました:
CharacterController3D
, DynamicBody3D
, DynamicBody2D
, NavMeshAgent
, Animator
, Prefab
.
たとえば、すべての2D物理ボディを確認する場合:
C#
public override void Update(Frame f) {
var iterator = f.Filters.DynamicBody2D(true);
while (iterator.Next()) {
Entity* entity = iterator.Current;
FPVector2 pos = iterator.Transform2D->Position;
if (iterator.Any.Transform2DVertical != null) {
var offset = iterator.Any.Transform2DVertical->Position;
}
}
}
もちろん、DSLで独自のフィルターを作成することもできます。
C#
filter MyEntities {
has Transform3D;
has DynamicBody3D;
not Prefab;
any {
PoisonArea;
EnemyTrigger;
}
}
ナビゲーション
経路探索には2つの重要な改善点があります。ついに、インポートされたUnity NavMeshの三角形を修正することができました。以前は時々不正確な境界線が生成されていました。問題を調査して、1つの頂点が別の三角形のエッジにちょうど重なっている三角形を検出し、三角形を分割する必要がありました。

次に、生のA*パス(ファネリング)を後処理し、選択したウェイポイントの視覚的品質を大幅に向上させます。このため、エージェントは頂点だけでなく三角形を横断します。下のピンクのパスは、選択した三角形の中心を通る生のパスです。緑のパスは、最終的なファンネルパスです。つまり、これは最適化された見通し線チェックアルゴリズムです。

他の重要な変更点
NavMesh.LineOfSight
は、任意で、最初にヒットした境界線の交点を生成します。NavMesh.FindClosestTriangle
は、navmesh内の最も近い有効な位置のターゲット検索の周りにグリッドを実行します。これは、NavMeshAgentConfig.FindValidTargetCellRangeを介してnavmeshエージェントターゲットを設定するときに自動的に有効化できます。QuantumEditorSettings.DrawNavMesh
は、シーンビューにギズモとして実行時にnavmeshをレンダリングします。- エージェント設定で
BreakingOnWaypoint
を無効にできるようになりました。
NavMeshリージョン
NavMeshリージョンは、実行時に確定的にオンとオフを切り替えることができるnavmeshの事前定義された領域(三角形と境界のグループ)です。破壊された建物で歩行のためのスペースを開放したり、壁で通路を遮断して通行不能にしたい場合があります。スクリーンショットのピンク色の領域は、その領域が有効であり、その上を歩くことができることを意味します。


ナビゲーションマニュアルには、ワークフローを説明す章があります:ナビゲーションシステム-Navmeshリージョンの設定。
Navmeshマルチスレッド
SimulationConfig.NavMeshAgent.IsMultithreaded
を切り替えて、エージェント、そのステアリングおよび回避計算によってトリガーされるパス検索のマルチスレッド最適化を取得します。
これを EnabledCallbacks
と組み合わせて使用するのは危険です。これらは異なるスレッドから呼び出されるため、コールバック中に変更できるのは自身のエンティティのみです。フレームや他のエンティティは変更できません!

新しいエージェントの回避(実験的)
これは興味深いトピックであり、特定のゲームとその要件を微調整できる機能の良い例です。元の(1.2.3まで)回避は、単純に影響を与えるシステムであり、非常に優れたパフォーマンスを発揮しますが、最良の視覚的結果が得られない場合があります。現時点では多くのゲームにとって最良の選択かもしれません。しかし、予備の計算能力が少しあれば、それを使って回避品質を上げることも可能です。
私たちは、Velocity Obstacles
で動作する手法を使用しています。現在ではすべての主要ゲームで何らかの形で実装されているものです。

これは改善する予定です。
回避の品質
None
:すべての回避が無効Low
:レガシー回避システムを使用(ベストパフォーマンス)Medium
:回避を達成するために最小数の候補が計算されるGood
:合理的な数の候補が最良の効率で計算されるHigh
:衝突のない候補の最大数が生成される(実験的、高CPUコスト)
エージェントをNavmeshにクランプ
物理なしでnavmeshエージェントを使用する場合(UsePhysics
がオフの場合)、回避はnavmeshの外側に移動する可能性があります。これを防ぐには、Clamp Agent To Navmesh
を有効にします。これにより、物理で行われるように、エージェントがnavmeshに戻ります。
Clamp Agent Radius Threshold
は、検証チェックを微調整します。この値より小さい半径(NavMesh.MinAgentRadiusを引く)を持つエージェントは、わずかに効率の悪い計算を使用します。半径が小さいエージェントがまだ外に出ている場合は、これを増やして修正を難しくします。Clamp Agent Correction
は、各ティックに適用される補正の割合です。これを増やすと、発生する可能性のあるジッターのコストの境界によってエージェントがより強く反発されます。
既知の問題点
エージェントは、ウェイポイントの近くで互いに詰まったりブロックしたりする可能性があります。これは、実際には回避ソリューションの排他的な問題ではありませんが、対策が必要です。
ブロックを緩和するには、Reduce Avoidance At Waypoints
を調整してみてください。これにより、エージェントはウェイポイントに近づくと回避をさらに無視するようになります。その後、お互いに浸透しますが、ブロックするよりも良いでしょう。
物理
リリースノートで述べたように、このアップデートではいくつかの新しい機能がQuantumの物理エンジンに追加されています。
それらのいくつかは、3Dキャストの「LinecastOptions.FirstHitOnly」や静的2D Polygonsのエッジ衝突の切り替えなどの単純な最適化オプションです。以下は、最も興味深い追加に関する説明です。
摩擦と反発の組み合わせ機能
SDK 1.2.4より前の物理ソルバーには、摩擦と反発を計算するためのハードコードされた関数がありました。これで、両方の機能のいくつかの結合機能から選択できます。
- Legacy:古い動作を保持します。
- Max:2つの素材の間の最大値。
- Min:最小値。
- Multiply:2つの値の積。
- Average:2つの素材間の平均値。
これは素材ごとに選択されますが、2つのアセットの結合機能が異なる場合に使用される摩擦値はどのくらいですか?
Legacy = 0、Max = 1、Min = 2、Average = 3、Multiply = 4の順序で最小値を使用して優先順位を決定します。これにより、Legacyは他の機能よりも優先される動作になります(素材のひとつがそれを使用している場合)。
Unity Terrain ExporterとMesh Collider
Unity MeshColliderとTerrainをQuantum静的3D三角形にエクスポートすることがついに可能になりました。それらは、マップが読み込まれるたびに3D物理ブロードフェーズの初期化に注入される「triangle soup」としてマップアセット内に保存されます。

すべての狭位相衝突チェック、シェイプオーバーラップ、および三角形に対するレイキャスト機能が実装されたため、静的メッシュが意図したとおりに機能するはずです。

KCC
メッシュに加えて、新しいkinematicキャラクターコントローラー(KCC)を追加して、3Dキャラクターの制御を支援しました。完全なターンキーソリューションとして、またはカスタムシステムの一部としてより生のコンポーネントとして使用できる柔軟性があります。
主な機能は次のとおりです:
- ティックごとに単一の高速円オーバーラップを使用して,表面,地面などを見つけます。
- 高度な構成が可能(以下の構成アセットを参照)。
- Frame.CharacterController3D.ComputeRawMovement(entity、velocity、callbacks)関数は、表面法線、接線移動ベクトル、貫通補正、移動タイプ(落下、傾斜、地面など)および接地状態を含む構造体を返します。
- Frame.CharacterController3D.Move(entity、velocity、callbacks)は、任意でターンキーソリューションとして使用できます(内部的には上記の関数を使用します)。
- 同様に、KCCコンポーネント自体には単純な固定状態ベースのジャンプに使用できるジャンプ機能があります。
- CharacterController3D.Init(CharacterController3DConfig config = null)を使用する必要があります(任意の構成パラメーターを使用すると、異なる動作のKCCを使用できます)。
KCC構成アセットのスクリーンショットは次のとおりです:

動作している様子の動画:

3D物理性能
3D物理エンジンの機能の完成に近づいているため、パフォーマンスのためにコードの最適化を開始しました。エンジンのほとんどの部分はまだ最適化されていないコードを使用していますが、最近の変更により、一部ではすでに高速になっています。
- FPQuaternionに関連するすべての関数のインライン化(FPVector3へのFPQuaternion乗算は、プロファイリングテストの主要なボトルネックでした)およびFPVector3から一部。
- 物理的な更新関数を介した補助エンティティ構造内のいくつかの再利用可能な値のティックごとのキャッシュ(これにより、同じティックの更新中に値が必要になるたびに再計算が回避されます)。
全体として、3D物理エンジンのパフォーマンスは引き続き大幅に向上し、SDK 1.2.4 R1またはR2をリリースするときに完全にインライン化されたバージョンになる予定です。
もうひとつの利点は、FPQuaternionおよびFPVector3を使用するコードも、ほとんどの操作がこれらの数学構造体でインライン化されるため、より高速に実行されることです。
Back to top