VRChat currently assumes that all synchronized positions exist in a single global coordinate space. This approach works well for small and medium-sized worlds, but becomes a significant limitation for large-scale environments such as flight simulators, space simulations, vehicle worlds, and open-world experiences where players can travel far from the world origin. As synchronized objects and players move farther away from (0,0,0), floating-point precision gradually decreases due to inherent limitations of standard floating-point representation. This leads to visible jitter, unstable rendering, reduced spatial accuracy, and degraded VR comfort, especially in fast-moving environments. In VR, these issues become noticeable much earlier than on traditional flat-screen applications. Existing Demand and Workarounds The need for large-scale coordinate management is already demonstrated by existing world implementations. Several world developers have created custom systems that apply local coordinate offsets, player relocalization, or proxy-based movement systems in order to mitigate precision issues at large distances. These approaches often rely on re-parenting players, manipulating seat or attachment systems, or building custom synchronization layers on top of VRChat’s networking model. While these solutions demonstrate clear demand for improved large-scale spatial handling, they are inherently complex, fragile, and costly to maintain. They require per-player tracking, custom smoothing logic, edge-case handling for interactions with existing VRChat systems, and careful synchronization management. Even then, they remain partial workarounds rather than robust, general-purpose solutions. The fact that multiple independent world creators have converged on similar workarounds indicates a real and recurring need that is not currently addressed at the platform level. Proposed Solution Introduce a client-side Global Sync Offset that is applied uniformly to all synchronized spatial data. The offset exists only on the local client and does not modify any networked or server-stored data. VRChat’s networking model remains unchanged and continues to operate in a single consistent global coordinate space. Conceptually: Incoming synchronized positions: LocalPosition = NetworkPosition - Offset Outgoing synchronized positions: NetworkPosition = LocalPosition + Offset This ensures that all relative distances between objects and players remain identical, while allowing each client to maintain numerical stability by keeping relevant geometry closer to a local origin. The offset is applied strictly as a final transformation step after simulation and interpolation, but before rendering. Benefits Enables proper floating-origin systems for Udon worlds Improves stability for large-scale and high-speed environments Reduces floating-point precision issues far from the world origin Eliminates the need for complex per-player synchronization workarounds Preserves all existing networking assumptions and relative spatial consistency Requires no changes to server-side synchronization logic Important Note This system does not modify simulation, physics authority, ownership, or networking behavior. It only affects local client-side spatial representation of already-synchronized data. Potential API Example SetGlobalSyncOffset(Vector3 offset) GetGlobalSyncOffset() This feature would allow world creators to build significantly larger and more complex environments while remaining fully compatible with VRChat’s existing networking architecture.
