基于 Matrix 构建的开放、分散式、身临其境的世界
Third Room is a platform for shared virtual worlds built on top of Matrix. Third Room aims to make it easy to discover, create, and share 3D worlds with others.
Visit thirdroom.io
Your homeserver should be on Synapse version 1.62 or higher. This is due to Third Room's requirement of the Cross-Origin-Resource-Policy: cross-origin header for the media repository's download route. Third Room uses SharedArrayBuffers which require us to run in a secure-context.
You also should have a TURN server set up with your homeserver. More info on how to do that here.
Third Room enables people to discover and create virtual worlds while protecting their privacy and giving them ownership over their data. We use open standards to ensure that both the 3d content and social networking data is portable and interoperable with other platforms. We empower creators to design and program rich and interactive virtual worlds and avatars using a wide variety of 3D content creation tools and harnessing the power of the glTF file format.
The Third Room client developed in this repository is only one implementation of a possible Third Room client and we welcome additional web or native clients to implement the protocols we design together. Third Room itself is designed around the Matrix protocol, but pieces of this project can be utilized in other 3D web applications including other virtual world platforms. We intend to build the client in a modular fashion, improving the overall landscape for the 3D web ecosystem and being a good participant in the open source community that we are benefitting from.
We will be a good participant in the immersive web. Third Room is just one piece of the overall immersive web. We believe platforms that intend to create their own "metaverse" are missing the point of that term. There is only one metaverse just as there is only one internet. We will embrace and encourage interoperability instead of accepting fragmentation.
Third Room at its core is focused on creating spaces for people and communities to feel safe. We will foster an open community that is kind, respectful, and accepting of others. We will utilize Matrix's existing moderation tools and extend them to best protect our community members against trolls and harassment. We will put users in control of their own privacy and always design with a privacy and safety first mindset.
Third Room is built on top of the Matrix group VoIP spec (MSC3401) where WebRTC connections for voice and game networking are established over Matrix. Matrix is also used for hosting the 3D assets for these virtual worlds and your avatars as well as providing decentralized identity, end to end encryption, text chat, room permissions, and more. We've also started work on a Matrix spec for virtual worlds (MSC3815).
Third Room is completely open source under the Apache 2.0 license. You can check out this repository, fork it, and modify it as you please. The project is governed by the Matrix.org Foundation and all our work is done in the open. We're still getting the foundation of the project set up and don't have a streamlined flow of taking on external contributors right now. If you are interested in helping out you can join us in the #thirdroom-dev:matrix.org Matrix room.
Manifold, Third Room's engine, lives under the /src/engine directory of this project. It is developed with the bitECS and Three.js libraries. It is eventually intended to be published as a standalone project for use with or without Matrix, but it is currently under active development and not ready for a public release yet.
Manifold is built with bitECS, a high performance ECS library written in JavaScript. bitECS is built around Data Oriented Design and JavaScript's TypedArrays to improve CPU cache performance.
In addition to performance, ECS design lets us have predictable execution of systems and more easily debug issues that arise in our game loop.
We've also adopted bitECS's function programming patterns throughout our engine for simpler abstractions, better tree shaking, and faster design iteration.
Manifold is designed around a multithreaded architecture which allows us to fully utilize your system's hardware. As a result, the core of the engine is split across these different threads. We have carefully built out lock-free scene graph data structures backed by JavaScript's SharedArrayBuffers and Atomics. This allows us to split the renderer from the game thread and run each at different rates. With high refresh rate monitors becoming the norm, this is becoming increasingly important. You can now get smooth 120hz+ rendering while your game logic runs at a stable 60hz. Allowing for the renderer thread to submit draw calls as soon as possible in the frame and keep the GPU saturated while your game logic gets a full 16ms to run complex physics simulations and more. The render thread then uses interpolation to smoothly animate the transforms of objects in your scene.
Another short term option we are considering for reducing input latency is with a locking double buffered approach. Where the game simulation is ran at the same rate as your monitor's refresh rate. This approach has the game thread computing the state of the next frame and the render thread rendering the last frame's state. It requires the game simulation to complete within the time frame of your monitor's refresh rate or you will drop frames which may not be preferable when you are bound by your game's simulation. However, if your simulation is simple, this can be a good option for reducing input latency. It's also possible that we may be able to switch between these two approaches depending on the average execution time of your game thread on your particular device.
Browser limitations and API adoption of things like OffscreenCanvas and Atomics.waitAsync create design constraints that are fairly unique to the Web. Our current architecture lets us stay flexible and adapt to advancements in browser technology.
Manifold uses Three.js as its rendering library. However, the Three.js API is not intended to be used directly by Third
Room developers. We've built a multi-threaded scene graph API with a similar shape to the
glTF data model. Our intention is for glTF content to
be loaded on the game thread, passed to the render thread via the
MessageChannel postMessage API, and then
modifications to transforms or materials can be made synchronously on the game thread with data structures backed by
SharedArrayBuffers. These rendering changes will be applied on the next render frame.
The renderer itself currently exists on either a dedicated WebWorker when OffscreenCanvas is available, or it shares the main browser thread when it's not.
Three.js is built around the WebGL API and recently switched over to WebGL2 as the default. There is also early support for the WebGPU support. We're currently focusing on the WebGL2 target as browser support is very good now and we can get some performance improvements over WebGL1 with features like Uniform Buffer Objects and Vertex Array Objects.
Most of our rendering features will be tied to the glTF specification and extensions.
Currently supported:
To Do:
暂无开放 Issues，或尚未同步最近议题。