パフォーマンス、証跡つきで
これは Weft ソルバーの、計測済みで実機を公開した数値であり、宣伝文句ではありません。どの値も、1 台の特定のマシン上で製品コードに対して実際に Stopwatch を回して得たもので、その内容をここにそのまま載せています。私たちが調べたかぎり、これほど実機を公開しプラットフォーム別に区切ったベンチマークを出している競合はありません。ですから数値だけでなく、公開していること自体もひとつの要点として受け取ってください。
計測したマシン。 Intel Core i9-14900KF、物理コア 24、論理プロセッサ 32、RAM 64 GB、Windows 11 Pro (build 26200)、Unity 6000.3.9f1、Burst 1.8.29。計測日 2026-07-12。
Weft のコスト、平たく言うと
購入者が実際に尋ねる 4 つの場面を、上で公開したマシンでのコストと、90 fps の VR フレーム(11.11 ms)に占める割合として示します。これは製品ビルド(IL2CPP)の数値であり、シーンの計画に使うべき正直な数字です。
| シーン | Weft ソルバーのコスト | 90 fps VR フレームに占める割合 |
|---|---|---|
| ヒーローアバター 1 体(ヘアーと衣装) | ~0.6 ms | ~5% |
| アバター 8 体の部屋、全員静止 | ~2.8 ms | ~25% |
| アバター 8 体の部屋、1 体に手が触れている | ~4 ms (p95) | ~35%, 0 dropped frames measured |
| 1 万頂点の衣装が生成される瞬間 | ~4.5 ms one-time (with Bake Topology) | budget once per avatar join, not per frame |
知っておくべき正直な注意点がいくつかあります。これは公開済みの 1 台のデスクトップマシンでの計測で、あなた自身のマシンでは異なります。オンデバイス(Quest、モバイル)の性能はまだ計測していません。「触れられた部屋」の行は「静止した部屋」の行より軽い計測方法で測っているため、フレーム単位で直接は比較できません。完全な公開表と測定方法はこのページの下部にあり、この表はその上に載せた平易な要約です。
望みどおりにスケールします
各アバターはそれぞれ独立したワールドをステップするので、アバターを増やしてもコストはほぼ線形にしか増えません。急な段差はありません。製品リリースビルド(バイオレット)は、どの点でもエディターの上限(ピンク)を下回っています。
上の数値は各アバターを 1 体ずつ順番に解いたもので、正直な最悪ケースです。Weft はその代わりに重ねて解けます。静止した 8 体の群れはおよそ 2 倍の速さで走り、誰かが触れているアバターでさえ、いまは残りと重なって走ります。詳しい数値は下にあります。
静止した群れをまとめて解く
静止した 8 体の部屋を 1 体ずつではなくまとめて解くと、コストはおよそ半分になります。
このラングの各リグは、ヘアーグループ 1 つ(35 ストランド、210 パーティクル)と 3,000 頂点の衣装 1 点で、1 体あたりおよそ 3,210 個のシミュレーション点、8 リグ全体で 25,680 個です。
Weft は、誰も触れていなければ、複数のアバターを 1 体ずつではなく同時に解けます。下の表は、ページの他の部分と同じマシン・同じ日常的な環境で、まさにそれを計測したものです。
計測 2026-07-12 / 2026-07-13。
この表の数値はすべて、誰も触れていない静止した群れのものです。誰かがアバターをつかんだり突いたりしても、Weft はそのために処理を止めるのではなく、群れと一緒に解くようになったので、アバターに触れてもフレームが詰まることはありません(まれな 1 つの例外を除いて)。触れられているときの数値は次のセクションにあり、別の方法で計測しているので、この表とセルごとに比べないでください。
| リグ | Sequential ms | 並行 ms、バッチ off | 並行 ms、バッチ on | 高速化、バッチ off | 高速化、バッチ on |
|---|---|---|---|---|---|
| 1 | 0.7027 | 0.5866 | 0.5986 | 1.1979x | 1.1739x |
| 2 | 1.4632 | 0.9016 | 0.8819 | 1.6229x | 1.6592x |
| 4 | 2.9021 | 1.6309 | 1.6059 | 1.7794x | 1.8072x |
| 8 | 5.7515 | 2.8688 | 2.8261 | 2.0049x | 2.0351x |
かみ砕いて言うと、静止した群れは 1 体でおよそ 1.2 倍、8 体で 2 倍を少し超える速さになり、バッチのオンオフで実質的な差はありません。静止した群れが大きいほど、同時に解ける利点が大きくなります。
Sequential の列は、同じ群れを 1 体ずつ解いたもので、同じ方法で計測しているので、高速化の比較は同じ土俵どうしです。これはページ前半の素のマルチアバターの数値とは別もので、そちらは少し違う方法で計測しているため、両者を同一視しないでください。
2 つの高速化の列(バッチのオンとオフ)は、互いに計測ノイズの範囲内に収まるので、同じ結果として扱ってください。
実際のスマートフォンやヘッドセットでの数値は、まだここにありません。待っていた作業は完了し、両方の端末も手元にありますが、まだ計測していないだけです。計測を行い次第、掲載します。
実際にアバターに手を触れているとき
部屋の全アバターが同時につかまれ、突かれ、押されていても、およそ 4 ms です。
このラングのすべてのワールドは、衣装とヘアーの両方に握られたグラブがあり、さらに最初のフレームから実際に交差するコライダーが本物の突き衝撃を全アバターに与えています。
ここまでの表は静止した群れでした。この表はその逆で、どのアバターも最初のフレームからつかまれ、突かれ、押されています。プレイヤーの手が実際にアバターに触れているとき、シーンがどれだけのコストになるかを示します。
計測 2026-07-13。
| アバター | 標準 ms | p95 ms | p99 ms | 90 fps 超のフレーム |
|---|---|---|---|---|
| 1 | 0.8043 | 1.4329 | 1.6742 | 0 |
| 2 | 1.1817 | 1.4355 | 1.4836 | 0 |
| 4 | 2.0224 | 2.5007 | 2.6737 | 0 |
| 8 | 3.5850 | 3.9533 | 4.0940 | 0 |
8 体のアバターを同時に触れていても、1 フレームも予算を超えませんでした。これは平均ではなく 1 台のマシンでの 1 回の計測なので、約束ではなく良い兆しと捉えてください。より忙しいシーンはより多くのコストがかかります。
p95 と p99 は平均ではなく最悪ケースの目安です。20 回に 1 回だけ、100 回に 1 回だけ、これより遅いフレームが出るという意味です。最後の列は「ヒッチ」の数、つまり 90 fps のヘッドセットが与える 11.11 ms より遅く、目に見えてフレームを落とすほど遅かったフレームの数です。
1 つ注意点があります。これは上の静止の表とは少し違う方法で計測しています(同じソルバーの処理を、まわりの描画なしで)。ですから 2 つの表を数値どうしで比べないでください。
アバターが加わるときの 1 回きりのコストと、その解決策
以下の各段は、アバターの生成時に 1 回だけ計測した「一からの World Build」で、毎フレームのコストではありません。
ここまではすべて毎フレーム払うコストです。これは、アバターが現れた瞬間に組み立てる 1 回きりのコストで、セッション途中でプレイヤーがシーンに入ってくるような場面です。毎フレームではなく 1 回だけ起こります。ここでは、その正直なつまずきと、Weft が出荷している解決策の両方を示します。
計測 2026-07-13。
| ストランド | ビルド ms |
|---|---|
| 35 | 0.0956 |
| 70 | 0.1847 |
| 140 | 0.3708 |
| 200 | 0.5938 |
ヘアー
| 頂点 | ビルド ms |
|---|---|
| 3,000 | 23.0921 |
| 4,875 | 47.2207 |
| 7,200 | 95.5325 |
| 10,000 | 193.8801 |
メッシュ衣装
| リグ | ビルド ms |
|---|---|
| 1 | 23.0552 |
| 2 | 46.0327 |
| 4 | 92.5230 |
| 8 | 189.2070 |
マルチアバター
ヘアーの組み立ては軽いです。コストがかかるのは衣装のメッシュで、現実的な 1 万頂点の衣装は一から組み立てるとおよそ 194 ms かかり、アバターが現れた瞬間にすべてが重なると数フレーム分の本物のつまずきになります。これは焼き込み(ベイク)なしの正直な数値です。解決策は下記を参照してください。
トポロジーのベイク、出荷済みの解決策
ワンクリックで、1 万頂点の段の一からの構築を ~198 ms から ~4.5 ms へ短縮できます。roughly 44x 高速です。
衣装のインスペクターにある「Bake Topology」ボタンは、衣装を組み立てる際の高コストな部分(どの頂点がどうつながるか)を 1 度だけ保存済みアセットに焼き込みます。アバターが加わるたびに一から導き出す代わりに、それを読み込みます。ヒンジなしのメッシュ段では、1 万頂点の段で ~198 ms から ~4.5 ms へ、roughly 44x に短縮されます。ヒンジ有効の衣装でも、同じ段で ~500 ms から ~55 ms へ、roughly 9 to 10x という大きな効果が見られます。ポーズやスケール、チューニングの変更ではベイクは無効になりません。メッシュそのものやトポロジー設定への本物の変更があったときだけ無効になり、結果は焼き込みなしのビルドとバイト単位で同一であることが証明されています。
古くなった、または一致しないベイクは決して使われません。Weft は黙って一からの構築にフォールバックするので、ベイクが誤った、あるいは壊れた結果を出荷することは決してありません。
アロケーションはゼロ、しかもゲートです
Weft の解法は定常状態において、ヘアー、メッシュクロス、マルチアバターのいずれでも、1 フレームあたりマネージドバイトをゼロしか確保しません。これは願望ではなく、許容差なしで正確にゼロバイトの差分を要求する厳格なテストゲートです。差分がゼロでなければビルドは大きな音を立てて失敗します。黙って見逃されることは決してありません。
ラング表の全文
すべてのラング、両方の列、そして正確なメモリフットプリント。ソルバーステップ時間の中央値をミリ秒で示します。割合は 90 fps のラインです。
ヘアー ストランドの群れ、1 ストランドあたり 6 パーティクル。
200 ストランドでも安く、0.5 ミリ秒未満です。
| ストランド | パーティクル | エディター ms | ビルド ms | 90 fps | メモリ |
|---|---|---|---|---|---|
| 35 | 210 | 0.1262 | 0.1078 | 1.14% | 9,520 B |
| 70 | 420 | 0.2652 | 0.2388 | 2.39% | 19,040 B |
| 140 | 840 | 0.4644 | 0.3746 | 4.18% | 38,080 B |
| 200 | 1,200 | 0.4922 | 0.3792 | 4.43% | 54,400 B |
パーティクルあたりのバイト数はラング表全体で一定です。ラングごとの上乗せがない、固定のパーティクル単位構造体ならまさにこうなります。
メッシュ衣装 フラットなグリッド、1 クアッドあたり 2 三角形。
現実的な 1 万頂点の衣装でも、およそ 1.3 ミリ秒です。
| 頂点 | パーティクル | エディター ms | ビルド ms | 90 fps | メモリ |
|---|---|---|---|---|---|
| 3,000 | 3,000 | 0.6794 | 0.5186 | 6.12% | 373,536 B |
| 4,875 | 4,875 | 0.8379 | 0.6218 | 7.54% | 610,656 B |
| 7,200 | 7,200 | 1.0314 | 0.7760 | 9.28% | 905,376 B |
| 10,000 | 10,000 | 1.2947 | 0.9183 | 11.65% | 1,260,896 B |
パーティクルあたりのバイト数はラング表を進むごとにわずかに上がります。これはラングごとの固定の上乗せではなく、グリッドが大きくなるほど頂点あたりのベンド(ヒンジ)拘束の密度が少し増えるためです。
マルチアバター 各リグはヘアーグループ 1 つと衣装 1 点です。
8 体のフルアバターを 1 体ずつ解くとおよそ 6.5 ミリ秒、これは静止した群れや触れられた群れが実際には全額を払わない、正直な最悪ケースです。
| リグ | パーティクル | エディター ms | ビルド ms | 90 fps | メモリ |
|---|---|---|---|---|---|
| 1 | 3,210 | 0.8076 | 0.6086 | 7.27% | 383,056 B |
| 2 | 6,420 | 1.5975 | 1.2395 | 14.38% | 766,112 B |
| 4 | 12,840 | 3.2479 | 2.4832 | 29.23% | 1,532,224 B |
| 8 | 25,680 | 6.4776 | 5.0928 | 58.30% | 3,064,448 B |
コストはリグ数にほぼ線形にスケールします。各リグはリグ間で共有せず独立したワールドをステップするからです。1 リグは上のどのバジェット行でも 10% を余裕をもって下回ります。
参考フレームバジェット: 60 fps 16.67 ms, 72 fps 13.89 ms, 90 fps 11.11 ms, 120 fps 8.33 ms. 90 fps のラインが主要な PCVR バジェットです。
どう計測したか
計測方法こそが差別化要因なので、何ひとつ隠していません。読んだうえで、上の数値をどれだけ信頼するかはご自身で判断してください。
本物の Stopwatch、それだけ
どの値も、Unity の EditMode バッチモード実行で、ソルバー自身の Step 呼び出しを Stopwatch で挟んで得たものです。レンダリングも入力もシーンロードもありません。純粋なソルバーステップのみで、これはコストテスト一式ですでに使っている流儀と同じです。
中央値の中央値
各ラングは捨てるウォームアップ 5 ステップ、続いて計測 20 ステップを走らせ、公開している数値はそのウィンドウを独立に 5 回走らせた中央値です。中央値は、スケジューラの単発の遅延を平均値よりうまく受け流します。
メモリは計測ではなく計算
メモリの列は、コンパイル済みの構造体サイズに実際のパーティクル数と拘束数を掛けてそのまま出しています。ですから実行ごとのノイズがなく、構造上まさに正確です。IL2CPP ビルドは 12 のラングすべてで、エディターとバイト単位で同一のメモリを出しました。
あえて、ふつうのマシンで
これらは、ふつうのバックグラウンドアプリ(録画または配信、ブラウザ、チャットまたはボイス)を開いた日常の作業マシンで計測しました。密閉したラボ機ではありません。これは意図的です。実際の購入者のマシンとはこういうものだからです。バックグラウンドの CPU 負荷はウィンドウ全体で平均およそ 4 〜 5 パーセントで、以前のアイドル実行は比較用に保存してあります。
遅いほうの数値を公開します
エディター列は Mono の下でマネージドのつなぎコードを走らせ、コレクションの安全性チェックを有効にしたままです。これはリリースビルドが取り除くオーバーヘッドです。ビルド列は同じウィンドウで実際に走らせた Windows x64 の IL2CPP リリースプレイヤーで、12 のラングのどれもが、エディターの対照より単に同等なのではなく速く出ました。フレームバジェットの割合はあえて遅いほうのエディター列を使っています。ですからそれは製品ビルドが上回るだけの、控えめな上限です。
DOTS の速さ、Entities の税なし
Weft は Burst、C# Job System、Collections、Mathematics という DOTS の土台の上に作られていますが、ECS は使わず Entities 依存も持ちません。Entities のプロジェクト構成を採り入れずに、DOTS 級のソルバー性能が得られます。
パフォーマンス品質と端末クラスのプリセット
Weft は、シミュレーションレート、サブステップ数、イテレーション数、そして上記のスケジューラ設定を、1 つの名前付きティアにまとめる購入者向けのプリセットメニューを備えています。ティアを選ぶことは、それらの項目を自分で手動設定するのとまったく同じであり、他には何も変わりません。
両方のメニューは Unity のメニューバーの Weft / Performance Profile にあります。
パフォーマンス品質ティア
| ティア | シミュレーションレート | サブステップ | イテレーション | スケジューリング | バッチスケジュール |
|---|---|---|---|---|---|
| Performance | 60 Hz | 2 | 2 | Concurrent | On |
| Balanced | 60 Hz | 4 | 4 | Auto | Off |
| Cinematic | 60 Hz | 6 | 6 | Auto | Off |
| Crowd | 60 Hz | 4 | 4 | Auto | Off |
端末クラスティア
| ティア | シミュレーションレート | サブステップ | イテレーション | スケジューリング | バッチスケジュール |
|---|---|---|---|---|---|
| Desktop | 60 Hz | 4 | 4 | Auto | Off |
| Quest-class mobile XR | 45 Hz | 3 | 3 | Concurrent | On |
両方の表のすべての値は暫定です。特に Quest クラスのモバイル XR の行は、実機計測を待つ正直な出発点であり、目分量で仕上げた最終値ではありません。
Crowd はスリープをオンにする唯一のティアです。落ち着いた衣装は完全にアイドル状態になり、フレームあたりのコストがほぼゼロになりますが、その代わり出荷時デフォルトより少し目覚めが遅くなります。
どのプリセットも自己衝突には決して手を触れません。無効にすると見た目の挙動が変わるため、これはコンポーネントごとに自分で意図して設定する手動のつまみのままです。
Weft が動く場所
Weft は、あなた自身の Unity アプリケーションやゲーム向けの Unity パッケージです。取り込んで、あなた自身のビルド(PC、PC VR、またはあなたのプロジェクトがすでに出しているスタンドアロンのプラットフォーム)を対象にすれば、ネイティブパッケージと同じように組み込めます。これがサポート範囲のすべてで、意図してそうしています。
ライブのソーシャルやアバターのサンドボックスは、ユーザーのアップロードを、カスタムのソルバーコードを入口で取り除く形で読み込みます。信頼できないアップロードを他人のクライアント上で安全に走らせるためにそうしているのであり、これはこの作り方をしたあらゆるネイティブソルバーに当てはまります。Weft も同じです。ですからそれらのプラットフォームは、ここでの欠陥ではなく、その仕組みの性質として範囲外です。
スタンドアロンの Quest クラス XR
Weft をスタンドアロンのヘッドセットでまだ計測していません。コードは対応するチップで動くので可能性はありますが、可能性と計測は別ものです。ヘッドセットとスマートフォンはいま手元にあり、実際に計測を行い次第、数値をここに掲載します。それまでは、実際に取っていない数値は公開しません。
決定性
Weft のリプレイが厳密に一致するのは、同じビルドを同じプラットフォームで走らせたときだけです。異なるプラットフォーム間でビット単位まで一致させることは、今はできません。
その約束は「同じビルド、同じプラットフォーム、そして同じ設定」です。記録の後にシミュレーションレート、サブステップ数、イテレーション数、あるいは剛性を変更すると、その記録のビット単位のリプレイが崩れます。これは他のビルドやプラットフォームの詳細を変えた場合と同じです。
シミュレーションレートは正直なスループットのつまみでもあります。出荷時デフォルトの 60 Hz の代わりに半分の頻度、30 Hz で走らせると、ソルバーが刻む回数が半分になる分、実時間 1 秒あたりのソルバー処理時間もおよそ半分になります。