欢迎阅读VRChat的8月28日开发者更新。
今日推荐世界是u/mamemoyasys创作的《VRC Volleyball》。
公告
Bigscreen Beyond 2e: VRChat版 + 第10年VRC+赠送活动
你看到标题里的感叹号了吗！我们将会给一位幸运的X/Twitter用户赠送Bigscreen Beyond 2e：VRChat版（含10年VRC+订阅里所有内含内容）！
请务必阅读完整的活动规则和资格要求详见此处。
你可以通过转推原始帖文此处参与此赠送活动。
Unity Cloth限制
你知道VRChat支持Unity Cloth吗？
如果已经知道，那这部分是专门为你准备的。
你知道Cloth组件会影响大量顶点，会带来明显的性能损耗吗？这种损耗在加载时、设备形象缩放时甚至运行时都可能出现。某些情况下这种损耗可能是平方级增长！
为了限制这种性能影响，我们已开始为Cloth组件可影响的顶点数量设置硬性上限，超过该上限的部分将在服务器处理过程中移除。
目前的限制值专注于防止崩溃——你应当不会发现该限制影响了有价值的设备形象，因为过去类似问题会导致你的设备直接崩溃。
注意以下情况不会导致服务器处理失败——仅会移除Cloth组件。
根据我们的分析数据，使用Cloth的设备中，受影响顶点数的中位数约为1700。作为参考，Very Poor等级的下限制为200。虽然PhysBones是VRChat设备形象设计的主流，但只有不到3%的设备使用了Unity Cloth。
从现实角度出发，设置更低的硬性上限能有效减少性能极差的设备形象。因此我们正在考虑进一步将上限降低到2000左右。
然而，我们也明白这会破坏部分设备形象的正常功能，且并非所有场景都能找到直观替代方案。
在许多但非所有情况下，PhysicsBones可以替代Cloth组件的功能。不过目前VRChat中尚无Cloth物理功能的替代方案，而且你问的内容（包括第三方资产如Magica Cloth的支持）暂时不会得到补强。
好奇的是，在2000个顶点之上（或之下）是否存在必须使用Unity Cloth的独特场景？
如果你支持通过降低硬性上限来避免崩溃，同时减少设备加载和缩放时出现明显卡顿的情况，我们非常希望听到你的想法！
Steam Audio测试版更新
谨记提醒：我们仍在通过Steam分支steam-audio-beta（在Steam客户端中）测试Steam Audio功能！所有用户均可通过Steam一次性选择加入该测试计划，具体相关资讯和补丁注意事项请查看Discord。
上周五我们发布了包含多项错误修复和新HRTF的重磅更新。HRTF（Head-Related Transfer Function, 头部相关传递函数）是模拟声音如何根据声音位置与聆听者的关系、以及聆听者的头/躯干/耳朵形状等因素变化的函数。
在VRChat等游戏中，HRTF允许你比普通立体声更精准地辨别声源位置——比如分辨声音是来自上方/下方、前方/后方，或者距离远近的程度。
目前尚无适合所有人的“标准统一”HRTF方案，因此你需要根据个人体验进行主观判断。我们希望寻找一个尽可能让大多数用户感到舒适的平衡点。
任何关于当前音频效果的反馈都很受用，这能帮助我们找到让大多数用户获得良好体验的基准设定。
在反馈前，我们建议你使用新版构建至少若干小时。新HRTF模型需要有一定时间让大脑适应！
你可以到专属的Steam Audio公开测试版Canny专区提交反馈！该专区不仅限于错误报告。
虚拟形象市场新模块！
虚拟形象市场新增了“最新作品”模块！
该模块已对所有用户开放数周，但近期我们优化了其运行效率并使界面略更流畅。
如果你希望了解虚拟形象市场的最新内容，现在可以访问“玩家探索”标签页并查看“最新作品”模块！
顺便一提，如果你是玩家创作者，现在正是加入创作的最好时机！
VR自动抓握功能更新
正如我们在2025年7月创作者路线图更新中首次分享的那样，我们正在更新Pickup组件以支持所有输入类型下的自动抓取功能！也就是说，世界创作者可以制作出不依赖持续按握按钮就能保持在手中的抓取物。该功能适用于所有平台——无论是PC、VR设备还是移动端！此前大多数VR游戏控制器和手势追踪（Hand Tracking）都无法实现这一功能。
操作非常简单：抓取一次即可保持，再次抓取即释放。扫码查看演示：
该更新不会改变现有抓取行为，但等我们更新SDK并让创作者刷新他们的作品世界后，你就能看到具有“更强抓握感”的新式抓取功能了。
2FA验证随机失败问题？我们已修复！
部分用户近期遇到了一个麻烦的死循环：你输入了有效的2FA验证码，却被反复提示验证失败。该问题影响了VRChat客户端、VRChat网站以及所有使用我们API的第三方应用的登录流程。
此问题在过去的约3周内逐渐显现。我们已于周一搞清楚了问题根源并着手修复，2FA验证失败率立即回归正常水平。
在绝大多数情况下，你无需任何操作，若问题仍持续存在，尝试注销并重新登录即可解决。
具体原因说明
加密流程概述
*
我们的正常登录流程大致如下：
客户端向/api/1/auth/user提交用户名和密码
服务器回应包含Set-Cookie: auth=authcookie_b7f9961e-e6b0-46cf-9869-fce1d22b93c4; ...头信息（若需要则提示下一步进行2FA验证）
用户从验证器应用中获取TOTP代码并输入客户端，客户端将该代码和当前auth cookie提交至/api/1/auth/twofactorauth/totp/verify
这一周起始，我们发现第三步提交时偶尔会缺失预期的auth cookie，或者提交的是过期的auth cookie（尽管我们已在第二步发送了新cookie），导致有效的2FA代码被错误拒绝。
缓存与此有何关联？
- 我们通过Cloudflare代理API流量至服务器。
- 为降低服务器出站流量费用，我们长期采用Cloudflare规则强制缓存响应，通过auth cookie进行重新验证——每段缓存响应的验证密钥取决于auth cookie。
- 该机制确保用户永远不会看到他人数据，缓存响应在返回前都会强制重新验证，避免发送过期数据的同时节省带宽。
近期Cloudflare对其缓存系统进行修改升级后，这一规则在auth cookie传输的边缘案例中开始表现异常。其实际症状表现为：当我们向客户端发送新auth cookie后，客户端下一次请求中已缺失该cookie，有时会出现旧的（过期的）auth cookie，这就导致2FA验证失败。
修复方式
我们已在所有API端点上停用了该强制缓存规则，仅保留若干特定规则。
这一修改并未提升API服务器负载，用户整体体验应无变化（除了现时可用的2FA验证功能）。
关于测试的说明
这在过往开发者更新中已被提及，再次提醒大家：我们正在进行测试。
测试哪些内容？视情况而定！
有时我们会明确说明测试内容，除非我们认为额外信息可能影响测试结果。
当测试某项功能时，你可能会发现体验跟朋友略有不同。虽然我们会尽量在测试特别显眼的功能时提前告知社区，但遇到差异完全不必惊慌！
安全提示
近期一款常用于资产提取（甚至有好心用户出于备份设备形象之目的也会用到）的第三方工具遭遇了数据泄露，用户名和密码信息已外泄。
在开始制作新项目时，请务必先做好备份方案。版本控制系统、云端存储甚至是简单的本地存档都能帮你避免重大损失！
最重要的是，永远不要将账号凭据输入不可信工具！
结语
本次开发者更新到此结束！我们将于9月11日回归。
