8月28日 VRChat開発者アップデート翻訳 および今後のClothへの所感
概要
8月28日にVRChat開発者から今後のアップデートおよびキャンペーンに関する告知があったため、その翻訳と所感（お気持ち）です。
目玉は一部のClothが使えなくなる（VRChat側から制限される）というところです。
出ました。Unity5, Unity2017, Unity2019, Avatar Scaling Updateと昔から続きに続く、Unity or VRChat による実装ミスの数々。最初から実装しなきゃいいじゃん
追記：この記事は走り書きなので粗いです。
（翻訳だけは超丁寧にしているつもりですが、所感《お気持ち》に関してはかなり雑です）
先に私の感想を３行で述べると
・なんでそんな安直な答えに行き着いたんだ（怒りポイント+1）
・このやり方を許せるなら他のヤツも制限出来るやんけ（怒P+2）
・書き方や説明が少数のユーザー相手だからって適当。不誠実（怒P+3）って感じです。
まず、私のスタンスとしては
・サーバーや個人の負荷回避の為にハードリミットを設けることには賛成。（過去にVRAM上限500などを設けている為）
・ただし、そのやり方や加減は慎重に吟味すべき。
（今回のClothを頂点だけで評価するのは乱暴すぎる）
・テキトーな大義名分や、いい加減な指標で制限を課すのは反対。
（一度通したら何でも出来るようになるから）
といった具合です。
では、その内容を見ていきます。
以下全文翻訳の後に長々と書きます。
=================
開発者アップデート—2025年8月28日
8月28日のデベロッパーアップデートへようこそ。
本日のフィーチャー・ワールドは、mamemoyasys さんの「VRC Volleyball」です。
お知らせ（Announcements）
Bigscreen Beyond 2e: VRChat Edition + 10 Years of VRC+ Giveaway
その長ったらしい名前のとおりです！ Bigscreen Beyond 2e: VRChat Edition と VRC+ 10年分 を、X（Twitter）のラッキーな1名にプレゼントします！
応募のルールと参加資格の全文はこちらをご覧ください。応募は、元の投稿をRTすることで参加できます。
Unity Clothの制限（Unity Cloth Limits）
VRChatがUnity Clothをサポートしているのはご存じでしたか？
もしご存じなら、このパートはあなた向けです。
多数の頂点に影響するClothコンポーネントは、大きなパフォーマンスコストを伴う可能性があります。これはロード時、アバターのスケーリング時、そしてランタイム中にも発生します。そのコストの一部は二乗で増加します！ 😱
このパフォーマンスへの影響を抑えるために、私たちはサーバー処理段階でClothコンポーネントが影響できる頂点数にハードリミットを設け、上限超過時には当該コンポーネントを削除する措置の導入を開始しました。
当面の上限はクラッシュ誘発（クラッシャー）防止に主眼を置いています——つまり、今回の変更で意味のある量のコンテンツが影響を受けることはないはずで、というのも、この方法で処理されるようなものは、従来はあなたをクラッシュさせていたからです。
なお、このケースではServer Processing（サーバー処理）自体は失敗しません——Clothコンポーネントが取り除かれるだけです。
私たちのアナリティクスによれば、Clothを使用している（少数の）アバターの影響頂点数の中央値は約1,700です。参考までに、Very Poorの上限は200です。また、PhysBonesはVRChatアバター作成の定番ですが、Unity Clothを使っているアバターは全体の3%未満です。
現実的には、より低いハードリミットを設けることで、非常にパフォーマンスの悪いアバターを避けるのに役立つでしょう。そこで、最大約2,000にさらに制限する案を考えました。
しかしながら、これにより一定量のコンテンツが動かなくなることは理解していますし、常に明快な代替手段を提示できるわけでもありません。
多くの（ただしすべてではない）ケースで、PhysBonesを用いて機能を置き換えることは可能ですが、VRChatには現在、布物理の代替は存在しません。そして、念のため先に言っておくと、当面それを追加するリソースもありません。はい、Magica Clothのようなサードパーティ資産のサポートも含めて、です。
そこで、ここでのエッジケースをよりよく理解するため、直接お聞きするのがよいと考えました。2,000（あるいはそれ以上／以下）の影響頂点数を必要とするUnity Clothの使用事例はありますか？ クラッシャー回避だけでなく、ロードやスケーリング時に激しいガクつきを引き起こすアバターを減らすために、ハードリミットの引き下げに賛成ですか？
ぜひお知らせください！
Steam Audio ベータの更新（Steam Audio Beta Updates）
定期のお知らせです。私たちは引き続き、Steamの steam-audio-beta ブランチを通じてSteam Audioをテストしています！ 誰でもオプトインでき、詳細やパッチノートはDiscordをご確認ください。
先週の金曜日、多くのバグ修正と新しいHRTFを含む大規模アップデートをリリースしました。HRTF（Head-Related Transfer Function） とは、リスナーとの相対位置や、リスナーの頭部／胴体／耳の形状などの要素に基づいて、音がどのように変化するかをモデル化する関数のことです。
これにより、VRChatのような多くのゲームでは、単純なステレオ音声よりも音の発生位置を正確に把握できるようになります——上か下か、前か後ろか、そしてどれくらい離れているかを（大抵は）判断できます。
ただし、誰にでも完璧に合う「普遍的」なHRTFは存在しません。したがって、ある程度の主観が絡みます。私たちは可能な限り多くの人にとって心地よい落としどころを探っています。
いまの音の聞こえ方についていただくあらゆるフィードバックが助けになります。多くの人にとって良好に聞こえる平均点を見つけるための必要な情報になるかもしれません。
フィードバックの前に、新ビルドを数時間は使用することを推奨します。新しいHRTFモデルに脳が順応するのに時間がかかる場合があるためです！
ご意見は、専用の Steam Audio Canny Board にお寄せください！ このボードはバグ報告に限定されません。
New Avatar Marketplace Row!（アバターマーケットに「New」行）
アバターマーケットに新しい行（項目）ができました……その名も New です！
この機能はここ数週間、全ユーザーに提供されていましたが、最近、最適化のための調整を行い、少しキビキビ動くようにしました。
アバターマーケットで利用可能な最新コンテンツを見たい場合は、Avatars → Explore タブにアクセスして “New” 行をチェックしてください！
……それと、アバタークリエイターの皆さん、今こそ飛び込むのにこれ以上ないタイミングですよ！
VR向けAutoHold更新（AutoHold for VR Update）
7月のCreators Roadmapアップデートで最初に共有したとおり、Pickupコンポーネント を更新し、すべての入力タイプでAutoHold をサポートします！ これによりワールドクリエイターは、「掴む（Grab）」ボタンを押しっぱなしにしなくても手に留まるピックアップを作れるようになります。PC・VR・モバイルのすべてのプラットフォームで機能します！ これは以前は、多くのVRゲームコントローラーやハンドトラッキングでは不可能でした。
やり方はとても簡単です：一度掴むと保持、もう一度掴むと解放。 下のデモで実際の挙動をご覧ください。
既存のピックアップの挙動は変わりませんが、SDKをリリースし、クリエイターが自分のワールドを更新した後には、新しい「ねばつき」のあるピックアップを見かけるようになるでしょう。
2要素認証（2FA）がランダムに失敗？ 修正しました！（2FA Verification Failing Randomly? We Fixed It!）
有効な2FAコードを入力しているのに、何度も「無効」だと言われるという、イライラするループに遭遇した方がいました。この問題は、VRChatアプリ、VRChatウェブサイト、そして当社APIを使用するサードパーティアプリでのログインに影響しました。
この問題はここ約3週間、徐々に忍び寄るように発生していました。私たちは今週の月曜日に何が起きているかをついに突き止め、修正しました。これにより2FA失敗は即座に通常レベルに低下しました。
ほとんどのケースでは何もする必要はありませんが、もしこの問題がまだ発生しているなら、一度ログアウトしてから再ログインしてみてください。
何が起きていたのか？（What Happened?）
上流プロバイダーのキャッシュシステムで進行中の変更が、私たちが長年使用してきた「すべてをauthクッキーでキャッシュ＆再検証する」キャッシュルールと悪い相互作用を起こしました。
場合によっては、クライアントが2FA検証の際に新しいauthクッキーを送らない、あるいは古い（失効／無効化された）クッキーを送ってしまうことがあり、そのせいで完全に有効な2FAコードが拒否されていました。
私たちは月曜日に該当のキャッシュルールを無効化し、2FA検証失敗は即座に解消しました。影響は、2FA検証APIリクエストの約8%（ユーザーの約**5%**に相当）でした。数時間後に2FAを通過できたユーザーもいれば、修正が展開されるまで一時的にアカウントに入れなかったユーザーもいます。
もっと深掘りしたい（I want to go DEEPER）
OK、いいでしょう。
通常のログインフローは次のようになります：
クライアントが /api/1/auth/user にユーザー名／パスワードを送信する。
サーバーは Set-Cookie: auth=authcookie_b7f9961e-e6b0-46cf-9869-fce1d22b93c4;... のようなヘッダーで応答し（必要なら）次のステップが2FA検証であることを示す。
ユーザーは認証アプリからTOTPコードを取得し、クライアントに入力。クライアントは現在のauthクッキーを含めて /api/1/auth/twofactorauth/totp/verify にコードを送信する。
私たちは、ステップ3が期待される auth クッキーなしで届く、あるいはステップ2で送ったばかりの新しいものではなく、古い／失効した auth クッキーとともに届く、という断続的なケースを観測し始めました。
サーバー側から見ると、これはあなたが認証されていないように見えるため、エラーを返します。
キャッシュがどう関係するの？（What’s Caching Have to Do With It?）
私たちはCloudflareを経由してAPIトラフィックをサーバープロバイダーにプロキシしています。
サーバープロバイダーの送信（egress）料金を削減するため、私たちは長らく、レスポンスを強制的にキャッシュしつつ全リクエストで再検証するCloudflareルールを用い、キャッシュキーはauthクッキー（ほか複数のヘッダーやクッキー値）で可変にしています。
これにより、ユーザーが他人のデータを見ることは決してなく、キャッシュされたレスポンスは必ず再検証されたうえで返送されます。レスポンス本体が変わっていないときには帯域を節約しつつ、古いデータを送らないことができます。
しかし最近、Cloudflareがキャッシュシステムの変更を展開し始めたことで、このルールが**auth クッキー伝送まわり**のエッジケースで不正動作するようになりました。
実際の症状としては、Set-Cookie で新しい auth クッキーをクライアントに送った直後の次のリクエストで、その同じ auth クッキーが含まれない、代わりに古いもの、もしくは何もない状態になり、結果として2FAが拒否されてしまう、というものでした。
どのように直したか（How We Fixed It）
私たちはAPIエンドポイント全体で、強制レスポンスキャッシュのルールを無効化し、ごく限定的なルールのみを残しました。
これによりAPIサーバー負荷は増えておらず、ユーザーの皆さんが目にする挙動の違いもないはずです（2FAが再び動くことを除いて）。
テストに際しての注意（A Note on Tests）
過去のデベロッパーアップデートでも触れてきましたが、私たちはテストを行っています。
何のテストか？ 場合によります！
テスト内容について、非常にオープンにすることもあれば、そうでないこともあります。というのも、その情報がテスト結果に影響しうると判断する場合があるからです。
私たちが何かをテストしていると、あなたの体験が友人のものと少し違って見えることがあるかもしれません。とても目立つものをテストしている場合にはコミュニティへお知らせするよう努めますが、何かが違って見えても慌てないでください！
セキュリティに関する注意（A Note on Security）
アセットのリッピングにしばしば使われる（そして、アバターのバックアップをしようとする善意のユーザーによって使われることもある）サードパーティツールが、最近侵害を受け、ユーザー名とパスワードが漏洩しました。
プロジェクトに取り組む際は、アップロード前に適切なバックアップを取ってください。バージョン管理、クラウドストレージ、あるいは単純なアーカイブでも、重大な頭痛の種を避けられます！
そして何よりも、信頼できないツールにアカウント認証情報を入力しないでください！
最後に（Conclusion）
今回のデベロッパーアップデートは以上です！ 次回は9月11日に戻ってきます！
=======================
本題
ここで終わりじゃないよ。
何が変わるのか
サーバー処理段階で、Clothの影響頂点数にハード上限を設定。超過時はClothコンポーネントが取り除かれる。（アバター表示とかイジってもダメ）
目的はクラッシュ／スタッターの抑制。まずはクラッシャー対策寄りの上限から始める
現状、Clothアバターは３％未満、影響頂点の中央値は1700との説明。
代替のCloth物理演算は当面リソースの不足によって提供予定はなし。
では早速読んでみましょう。
To limit this performance impact, we have begun adding hard limits to how many vertices a cloth component can affect before being removed by our server-processing step.
このパフォーマンスへの影響を抑えるために、私たちはサーバー処理段階でClothコンポーネントが影響できる頂点数にハードリミットを設け、上限超過時には当該コンポーネントを削除する措置の導入を開始しました。
アプデの文言だけ読むと、
we have begun adding（導入を開始した） と記載しており、
重さ対策のハードリミットは現在段階的に適用中というのが見て取れる。
これが we will begin adding（導入する予定）という記載だったら良かったのだが、ハードリミット機能を作るのは確定（実行中）だろう。
So to better understand the edge cases here, we figured we’d just ask directly. Are there any use-cases for Unity Cloth that require more than 2000 (or less/more) affected vertices? Would you be in favor of a reduced hard limit to avoid not just crashers, but also reduce the amount of avatars causing hard stutters on loading and scaling further?
そこで、ここでのエッジケースをよりよく理解するため、直接お聞きするのがよいと考えました。2,000（あるいはそれ以上／以下）の影響頂点数を必要とするUnity Clothの使用事例はありますか？ クラッシャー回避だけでなく、ロードやスケーリング時に激しいガクつきを引き起こすアバターを減らすために、ハードリミットの引き下げに賛成ですか？
「Clothに関しては2000頂点でどう？ 意見募集してるね！」という段階。
Xに数多いる有識者の間では確定事項ではないので騒ぐまでもないそうだ。
私個人は、このタイミングで聞いてくる時点で半ば既定路線だろうと思った。
なぜなら過去にも行われたご意見募集フェーズにおいて、ユーザー（少数の有識者）による意見が通ったことは少ない。
なのでClothの上限設定はほぼ確定事項だろうと思って見ている。
コイツ頭おかしいなと思ったならタブを閉じよう。
また、今回のリリースではCloth利用者が少数派（3%）であることをわざわざ書き、過去に読まれたはずの情報（後述）に一切触れられていないことから不信感を覚えた。
また、ここでの違和感は、設定超過ー制限というスイッチの重さ。
安易なチェッカーで既存のセキュリティとは違い、棲み分け（表示 or 非表示）ではなく切り落とすという設計に舵を切っている点にある。
カメラやUIと違い
「これ古いからもう廃止するね！ 新しいもの用意したから次からコレ使ってね！」
という話ではありません。
代替手段が無いのは分かりきっていることなので。
技術的論点について（頂点数だけで語れるのか問題）
次に記事に寄せられたコメントの中から、負荷に関する話を一部抜粋。
たまにロングスカートを表現するのに Cloth コンポーネントを使います。これだと、シンプルなスカートでも頂点はだいたい1500。布の重なりとか入れるとさらに増えるので、頂点数2000の上限はちょっとキツいかな、という印象です。
初期化で数十ミリ秒くらい重くなるケースがあるのは理解しています。ただ、同じくらいの頂点数でもメッシュの形次第でパフォーマンスはけっこう変わるんですよね。だから「頂点数だけ」で制限するのが本当に適切なのかは、正直ちょっと疑問です。
もし制限を入れるなら、次の点を考えてもらえると助かります。
・負荷が二乗で増えるのが問題なら、頂点数の計算や上限は「アバター全体」じゃなくて「コンポーネントごと」にしてほしい。
・上限を超えていても、明示的に「Show Avatar」を使ったときはそのコンポーネントを有効化できるようにしてほしい（今のカメラコンポーネントみたいな挙動）
私は Cloth を使ったアイテムを制作しています。
Cloth は PhysBone では再現できない表現を可能にする、非常に重要なコンポーネントだと考えています。
今回の「頂点数2000上限」には懸念があります。
この上限をアバター単位で課すのか、コンポーネント単位で課すのかで意味が大きく変わります。
アバター単位での上限設定には反対です。Cloth で実現できる表現の幅を大きく狭めてしまうからです。
一方で、コンポーネント単位での上限なら賛成です。
その根拠は NVIDIA PhysX SDK の記述にあります。
NVIDIA PhysX SDK「Performance Tips」より。
Cloth シミュレーションの実行時間は、クロス粒子数とソルバー周波数にほぼ線形に比例して伸びる。粒子数を増やした高解像度メッシュをシミュレーションしたり、伸び剛性や衝突処理の忠実度を高めるためにソルバー周波数を上げたりすると、1フレームのシミュレーション時間は長くなる。さらに、GPU ソルバーでは3000粒子未満あたりで性能低下が見られる（次節参照）。おおまかな目安として、粒子数2000・ソルバー周波数300Hzの Cloth インスタンスを12個程度なら、ゲームの一部としてリアルタイムにシミュレーションできます。
重要なのは、Cloth の頂点数だけではなく、コンポーネント全体の設定値です。
頂点数だけを制限しても本質的な性能改善にはつながらず、むしろ表現力を削いでしまいます。
私見としては、
コンポーネントあたり最大3000頂点までは許容してよいと思います。
実際に性能へ強く効くのは Self-Collision と Solver Frequency の値です。
特に Self-Collision と高すぎる Solver Frequency の組み合わせは計算資源を大きく消費し、クラッシュの主因になります。
具体策として、
Self-Collisionは計算コストを数倍に引き上げるため、有効化の制限を設ける。
Solver Frequencyは NVIDIA の推奨範囲である 120–300に収め、上限300、実運用では約180を推奨。
この2点を絞って制限すれば、性能は大きく改善するはずです。
加えて、Cloth コンポーネントの正しい使い方のドキュメントが不足しています。
少なくとも私が所属する日本のコミュニティでは、次のような問題が起きています。
経験豊富なクリエイターは先達から直接学び、正しく設定できる。
一方で、その他のユーザーは情報が乏しく、誤った設定に陥りがち。
公式の Cloth 関連ドキュメントが整備されれば、この状況は改善すると考えています。
既存のシールド（安全）ランクを活用するのも有効な対策です。
たとえばシールドを最大にした場合は、衣装（Cloth）を自動で無効化する、といった挙動です。シールドを最大まで使う場面は、そもそもリソースに余裕がない状況でしょうから、理にかなっています。
また、これまで VRChat は Clothコンポーネントに十分な配慮をしてこなかったように見えます（例：アバターランクの基準が更新されていない）
リソースが限られているのは理解していますが、1点だけ要望があります。
Cloth 使用時に限って Skinned Mesh Renderer の「Update Offscreen」を有効化できるようにしてください。
これは以前は可能でしたが、ある時点で無効化されました。
しかし Cloth は視界内にあるときしか計算しないため、キャラクターが視界外に出て戻ってきた際に不自然に加速し、動きが崩れて滑らかさが損なわれます。ここが直れば、Cloth の見た目はもっと自然で美しくなるはずです。
適切な制約のもとであれば性能劣化も起こしません。ぜひ解放してほしいです。
久しぶりに VRChat から Cloth コンポーネントへの言及があったのは嬉しく思います。
Q. Unity Cloth で、影響頂点が 2000（あるいはそれ以下/以上）を超える必要があるユースケースはある？
ある。Canny のチケットにいくつか載ってるだろ。まともなツールが来るまでは、ここはどうにもならない。
Q. クラッシャー対策だけじゃなく、ロード時やスケール時のガチなスタッターを減らすために、ハード上限をもっと下げるのはアリ？
その二つを一緒くたにするな。「クラッシャー歓迎！」なんて言うわけないだろ。スタッターは、お前らがスケーリングを雑に実装したせいで起きてる。コンポーネントを延々と再初期化する“お粗末な”Cloth スケーリングを入れる前は、そんな問題はなかった（フレームごとの負荷とは別の話だ）
Cloth コンポーネントがちゃんとしてて、もう少し賢く使える代物なら、コンポーネントごとに 2000 coeffs（＝影響頂点）が妥協点として妥当かもな。
そもそも Magica Cloth や Obi Cloth を入れてくれってずっと言ってきたのはそのためだ（Cloth ライブラリを差し替える前から、ずっとだ）。NVCloth は基本“線形”にスケールする。なのに「二次的に増える」って結論にどうやって至ったのか、説明してほしい。ボトルネックはロードだけど、リアルタイム用途としてはまだ十分速いだろ。
現状なら、俺は Obi Cloth 推しだ。Cloth Proxy があるから、低解像メッシュでシムして、その結果で高解像メッシュをスキンできる。これがここでの理想的な落としどころだ。
PhysBones を Cloth の代替にとか、笑わせるな。あれは揺れ物ボーンとしてはそこそこ、変な入力にも多少は反応するが、それ以上でも以下でもない。衝突判定が貧弱なのが特に致命的。
それに、もしお前らがまたいつもの安易な逃げ道で、この自分たちで招いた窮地から抜けようとするなら、2000 coeffs でも足りない。代わりに、こういう選択肢があるだろ：
・Clothシミュをセーフティ設定（シールド）に入れる（最初から扱ってないのはなぜだ？）
・パフォーマンス設定に最大ソルバー・レートを追加（できればレート倍率も）
・最大coeffs（影響頂点）の上限設定をパフォーマンス設定に追加（理想はトグル付き）
・スケール変更でCloth をリフレッシュするのをやめる。
・Burst ベースかCompute ベースのCloth シミュを実装。
Cloth Proxyを実装できるなら、コンポーネントあたり ~2000 coeffs でも正当化できるし、もっと低くできるかもしれない。今は一次メッシュを直接シムせざるを得ず、必要以上に高解像になりがちだ。またコンポーネントをぶった切る以外に、何を提示できる？
どうせ「今はそれを入れるリソースがない」って言うんだろ。サードパーティ資産のサポート込みで、ね。
ゼロから自作？ それは時間がかかるのは分かる。だが既存ソリューションの統合は別だ。中堅〜シニアのツール／エンジンエンジニアが一人いれば、パッケージを精査して統合するのにせいぜい一週間前後で済む。
alareis 氏のコメントの翻訳より
ちなみに発端（顕在化した主たる理由）はVRC開発がスケーリング機能を雑に実装したところにあるのは事実です。
スケール変更時に毎フレームごと（HMDによって異なるがValve indexの場合最大144回など）無駄に初期化されることがカクつきの増幅の原因になっています。
まあ相性問題は前提として
「"原因がClothにある"ということも正しい」としよう。
問題はその対処法。
なぜなら重さの主たる要因は頂点数に殆ど起因していない。
それは過去のCanny（後述）にも記載している。
基礎負荷は頂点数とSolver Frequencyにあるので頂点数を制限するのは、間違ってはいない。
しかし、モデルの頂点数（ポリゴン）はUnityで増やせない、つまり上限がある。
Unity上でメッシュを複製し続ければ頂点数は無限に増やせるが、撮影ガチ勢か、荒らしでもない限りメッシュ複製ギミックなんてそうそう使わないし、リッチな衣装に見せかける為の複製にも限度がある。
当然オシャレを楽しみたい一般プレイヤーはこんなことわざわざしないだろう。つまり頂点数は基本的に有限です。
そしてこれを制限するのはディティールや見た目に一番影響を与えるので、モデラーやオシャレを楽しみたいユーザーに最も効率よくダメージを与えられる。
それに対してSolver Frequency
Solver Frequencyには上限がない。
デフォルト120と入力してあるが12000でも20010911でも。
（Unityが扱える数字にも上限が存在するから無限ではないが）
いうて、こっちもそんなアホみたいな数字を入力する人は見たことがないし、明らかに周りから『重い！』とツッコまれるはずなので、そのアバターを使わないだろう。
他にもClothが重くなる原因として
Self-CollisionやContinuous Collisionなど他にも多くの要因がある。
Continuous Collisionを入れると計算数が約２倍になり、
Self-Collisionがいわゆる"二乗に比例して負荷が伸びる"原因になる。
負荷を低減できる要素はUnityの外などにも沢山ありますが、最適化すれば頂点数というユーザビリティに最も大きな影響を与える部分は大きな問題にはならないということ。
これは既に多くの人が公式へコメントを寄せています。
なんでお前キレてんの？（結局確定してないんでしょ？）
VRChat公式は長い間Clothについて放置を続けてきました。ぶっちゃけそれは構わん。
Cannyには
「バグなくなったからし、バグあり時代の基準変えようよ！」
「実際の計測データはこんな感じで Solverとかを基準に入れよう！」
といった意見が投稿され、Tracked（確認済）の表記も付きました。
これには一部Cloth有識者が歓喜。次の音沙汰は暫く先になるけどね。
そして、今回の発表。
「Performance Rankの見直しでClothの地位が向上か！？」と思いきや、
「やあ、今回はハードリミットの話だ。（君たちのCannyは４年ほど放置したけど忘れてくれや）」
……まさかの頂点制限の匂わせかい。
『Solverを基準に追加しようとかそういう話じゃないんかい』
『VRCahtの雑なスケーリング機能実装の皺寄せがこっちに来るんかい』実装当時ですらガッカリしたのにさあ！という具合である。
VRChatくんClothに対する理解度低すぎるよ……。
どっから説明すれば良いんだ……。
と思いきや、
多数の頂点に影響するClothコンポーネントは、大きなパフォーマンスコストを伴う可能性があります。これはロード時、アバターのスケーリング時、そしてランタイム中にも発生します。そのコストの一部は二乗で増加します！😱
……いやらしい書き方してますね。
多分、彼らはClothのことをある程度解ってます。
そう、Clothは全体が重いとかではなく、一部のコストが二乗で比例するということを彼らは理解しているんです。
その上で頂点数を制限するって言っています。
『実は、自分たちが過去にやってしまった実装が原因で○○を計測することが出来なくてその機能は作れないんです』
『契約の関係でここの機能に変更を加えることが出来なくて……』
みたいな、技術的・政治的な事情があるなら、正直に話してくれれば一技術者として納得もいく。（まあリソースがないって何度か述べてるし、単純にダルいんだろう）
過去にーー
『電子レンジの位置を動かしたら、サーバーの調子良くなったわ！！』みたいなことを書いていた会社です。今更何が出てきても驚かんわ。
Looking at our analytics, of the few avatars that use Cloth, their median affected vertex count is about 1700. For reference, the Very Poor limit is 200. And while PhysBones are a staple of VRChat avatar creation, less than 3% of avatars use Unity Cloth at all.
私たちのアナリティクスによれば、Clothを使用している少数のアバターの影響頂点数の中央値は約1,700です。参考までに、Very Poorの上限は200です。また、PhysBonesはVRChatアバター作成の定番ですが、Unity Clothを使っているアバターは全体の3%未満です。
1700が中央値であるというのは非常に興味深い。
しかし、なぜVeryPoor上限が200であることを述べたのか。
VeryPoorをかなり超過している＝重い という印象操作にも思える。
先のCannyにあった通り、一部の有識者たちの中では、頂点数200でVeryPoorになること自体が大分バカげているのだが……しかし。
なぜ わざわざ 少数派で あることを 強弁 したんだ。
『とりあえず重いって文句が来る』
『開発にも有識者いねえッピ』
『つか使用者３％もいねえよ』
『少数派なんざの為に考えるコスト掛けるのアホくさｗ』
『セーフティ（シールド）でON/OFF出来るようにするのもダルちゃんｗ』
『もう頂点数制限でいいンゴねえｗ』
……という非常にやる気のない姿勢が透けてる気がするんだが。イジメかな
以上が私のキレポイント。
別にClothが悪者扱いされるのは慣れてるからいい。
アプデの度に膨大な修正作業に追われたのもいい。
軽量化は個人の好き好みだし、一生VeryPoor扱いされてるのもいい
だが、いい加減な指標で制限かけられるのはな……。
今後どうなると思う？（マジで私の妄想込み）
まあ、今回のCloth頂点上限設定を強行したとして、問題の解決には繋がらないだろうことは容易に想像できます。
Unity5やUnity2017時代に辛酸を舐めさせられてClothを恨んでいる人たちも去年のレイオフで消えてなければ開発の中にいるでしょうし、
そのうちCloth丸ごと削除されるかもしれませんね。
（彼らはPhysboneがClothの代替になると考えているのかもしれません）最初から実装するな。
この記事がClothの遺書となるかは不明。
今後の実装次第ですが、過去のCloth記事は消す予定です。
2000頂点以内なら、どんな努力もどうでもいいみたいですし、
技術的正当性や、それに対する弁解や理解を語りかけるでもなく、過去に技術者たちが寄せた意見も既読無視した上でこの方針を示していますからね。
懸念としては
クラッシャーの原因である。
使ってる人間も少数である。
だから（いい加減な基準でも）ハード制限を設けてしまえ。
というVRChatの姿勢が今後も許されるなら、
『Shaderのテッセレーションとかaudio source爆盛りとかをやめさせろよ。今の荒らしアバターの主要手段がコレだろうが。パーティクルライブ？ ワールドでやれよ』
『そもそもポリゴン何十万も使ってるやつとかMaterial Slots100個とかもハードリミットでよくない？ 外部拡張カメラ？ デフォルトのカメラ機能で十分でしょ？』
『州政府が特定の問題で刺して来る？ ライト仕込めなくしたら解決じゃね？ ライト使ってるアバターなんてほぼ荒らしじゃん』
……という私の妄想です。
まあ、一つでも言い出したらキリが無いけど、
「今回は自分に関係無いから他人事」というならそれで良いでしょう。
影響を受ける３%とやらにあなたのフレンドが入っていないことを祈ればOKです。
ちなみに日本人におけるゲイの割合は1.59%／レズビアン1.01%／トランスジェンダーの割合は1％だそうです。（電通 LGBTQ＋調査2023より）（レインボーフラッグのキャンペーンを実施したVRChatにこれを言うのは嫌味な話です）
このノートを読んで思うところがあった方は、
下記URLからデベロッパー（正確に言うとコミュニティ部門）へコメントを残すことが出来ます（9月10日まで）
https://ask.vrchat.com/t/developer-update-28-august-2025/46531
So to better understand the edge cases here, we figured we’d just ask directly. Are there any use-cases for Unity Cloth that require more than 2000 (or less/more) affected vertices?
そこで、ここでのエッジケースをよりよく理解するため、直接お聞きするのがよいと考えました。2,000（あるいはそれ以上／以下）の影響頂点数を必要とするUnity Clothの使用事例はありますか？
むしろ
— NoeNoe (@NoeVRC) September 1, 2025
Clothをきれいに使ってる例があったら、askのコメントで紹介すると助かるかも
『私はこちらの衣装を使ってます（参考URLなど）』
『私が使っている○○はxxなので△△制限されると使えなくなっちゃいます！』
とか、そんな感じのでいいみたい（？）です。
Google翻訳も最近は優秀になってきましたし、ChatGPTを使えば、より正確な翻訳も可能です。
とにかくClothは影が薄いという致命的な問題があり、今回かなりセンシティブな書き方をしましたが、
一部の人が技術的な正論を言うより、
『３％と言って切り捨てる人たちの中に困る人がこれだけいるんだよ！』
ということをVRC開発に伝えるのが肝要だと思います。
First they came for the socialists, and I did not speak out—Because I was not a socialist.
Then they came for the trade unionists, and I did not speak out—Because I was not a trade unionist.
Then they came for the Jews, and I did not speak out—Because I was not a Jew.
Then they came for me—and there was no one left to speak for me.
彼らが社会主義者を連れ去ったとき、私は声をあげなかった——私は社会主義者ではなかったから。
彼らが労働組合員を連れ去ったとき、私は声をあげなかった——私は労働組合員ではなかったから。
彼らがユダヤ人を連れ去ったとき、私は声をあげなかった——私はユダヤ人ではなかったから。
そして彼らが私を連れ去ったとき、私のために声をあげる者は誰一人残っていなかった。
余談ですが、Clothの負荷に関する有用なデータを調べてVRChat等へ提供してくださったエスニヤ先生は、VRChatが言うところの少数派であったために、現在はResoniteで持ち前の航空力学や物理学の知識を用いて鉄道システムの敷設をされています。惜しい人をなくしました。
最後のオチが特に思いつかないので、血のにじむ努力を重ねに重ね、頂点数2,000を超えても軽い——そんな夢のようなCloth衣装を作ってしまった人たちへ。
''" "ﾞ" ﾞ" ﾞ"'' ＿＿＿＿＿
ﾞ" "''" "ﾞ" ﾞ"/::ヽ＿＿＿＿ ヽﾞ"
ﾞ" ﾞ" " ﾞ"'' ﾞ" |ヽ/:: ヽﾞ''"
ﾞ" ﾞ'" "ﾞ" ﾞ" .|:: |::: R.I.P | ﾞ "
ﾞ" ﾞ ﾞ" ﾞ"'' |:: l: LACHEXIA |
" ﾞ" "ﾞ" ﾞ"|: :|: | ''ﾞ"
ﾞ " ﾞ" ﾞ""'"Wv,＿|:: l .|､wW"ﾞ"
ﾞ " ﾞ"''" ".wWWlヽ::'ヽ|:::::::＿＿＿__:.|::＼W/ ﾞ"ﾞ''"
"'' ﾞ"''"ﾞ" V/Wヽ`―――――――――lV/W "'
ﾞ""' ﾞ"''" "ﾞ"WW''―――――――wwww' ﾞ"ﾞ''"
コメント
1通りすがりですが失礼。
ご自身でClothの衣装を作られているというのは存じている。それには多大なる苦労や苦難があったことだろう。私も過去Clothの衣装をVRChatにて使っていて、貫通対策で苦心した経験がある。であるが故に、それを作り上げる苦労は想像するに容易いとも感じる。
だが結局のところ最初に書かれていた不満の3行だけが、ここに至る迄の貴方の言葉の総括であり他は余剰なものだとしか、どうしても思えない。
それだけの熱意があるのなら、是非VRChat運営陣へ籍を置いて改善点などを提示又は開発に携わってみてはどうかと思う。きっと良いものが出来上がると思う。
実際の布のような数少ない表現方法の維持のために、是非頑張って貰いたいと思う。
私自身、数少ないClothを時折なびかせて楽しんでいるので、そこまでの熱意がおありなのならば、ととても勿体なく思ってしまう。
是非、解決策などの指南を皆に広めて貰いたい。
表現の方法は、幾つあっても良いのだから。