Table of Contents Show
TL;DR / For those who don’t know the tool: Sneeze sits between spatial services and AR and VR clients. It consumes glTF output from Blender, Maya, Houdini, Revit and Cinema 4D, and forms the engine layer of OMBI at the Metaverse Standards Forum.
A browser engine for rooms
The Metaverse Standards Forum introduces Sneeze on June 15, 2026 as an open metaverse browser engine. RP1 acts as lead architect and maintainer. The engine targets spatial services that appear through location and proximity rather than through a conventional page, tab or app-store download.
The project names Sneeze as the world’s first open metaverse browser engine. That is a marketing claim. Its practical definition is more useful: Sneeze keeps the scene graph, manages network connections, executes service logic and renders a shared spatial scene. A browser or native application supplies the shell around it. The planned release uses the Apache License 2.0 and places the code on GitHub. The final repository URL has not been published, but should be online soon.
The distinction between engine and browser matters. A web browser wraps navigation, settings, updates and user trust around an engine. Sneeze takes the engine role for spatial content. Developers can embed it beside an existing web renderer or use it inside a standalone native spatial browser.
Tabs would get crowded
A normal web browser loads one origin into one page context. Sneeze works with spatial fabrics. A spatial fabric combines mapped content, a coordinate system and related services into an environment such as a city street, university campus, factory floor, airport terminal or game arena.
Every fabric requires a map service. That service supplies geometry, terrain, objects, coordinates and streaming updates. Other services can add presence, communication, commerce, safety alerts, equipment data or location-bound content.
That model gives augmented reality a browser-style discovery mechanism. The engine opens and closes streaming connections as fabrics become relevant. It does not load each environment as a fixed document. Proximity supplies the navigation event.
Rendering gets an adapter
Sneeze routes scene rendering through ANARI, the Khronos rendering abstraction. ANARI describes meshes, materials, lights, cameras and volumes through a common API, then delegates drawing to a renderer underneath. The current architecture uses Filament through an ANARI-compatible wrapper for rastersiation. ANARI keeps that renderer replaceable. The application code above the abstraction does not need a rewrite when the engine swaps the renderer below it.
Tracking and device input pass through OpenXR. Head pose, hand pose and controller state come from the active XR runtime. Sneeze combines that tracking with the user’s position to place the virtual camera in the SOM coordinate space. The render loop reads the SOM as it exists for the current frame. It does not wait for every service writer. Network updates and WASM modules can keep changing the scene while rendering continues, and the next frame picks up the new state. That separation matters across phones, desktops, AR glasses and virtual reality headsets. Hardware changes below the abstraction layers. The scene model and service boundary stay in the engine.
For 3D, VFX and visualisation teams, this vocabulary will reach client meetings long before it settles into production pipelines. We will create the models, materials, animation and environments that spatial browsers present, so names such as SOM, glTF, WebAssembly, ANARI and OpenXR are worth learning before the next briefing becomes another group exercise in confident nodding. Again.
DCCs stop at delivery
Sneeze does not replace content creation tools. It consumes their output. glTF carries 3D models, animation and scenes from the DCC side into the browser engine.
The format can carry mesh geometry, physically based materials, textures, skeletal animation, morph targets and a hierarchy of transforms. Its binary container can package the same delivery data. Sneeze treats that payload as rendered content rather than as an editable authoring scene.
glTF does not carry the live multi-user state, service streaming or change notifications described by the browser architecture. The map service and SOM handle those jobs. The format transports assets; the spatial system handles what changes around them.
KTX supplies GPU-oriented textures. SPIR-V supplies portable shader bytecode. Compiled WASM modules carry service logic. Together they create a delivery boundary between authoring and runtime.
Materials and textures can come from Substance 3D or Quixel Mixer. Models and animation can come from the usual DCCs. The engine sees the files, not the artist’s preferred interface, node graph or collection of mysteriously named final-final files.
That boundary gives existing Blender workflows a direct route into the proposed runtime through glTF export. It does not promise that every shader, modifier, simulation or custom rig behaviour survives the trip.
Game engines need translation
Unity and Unreal Engine projects have a migration path. Assets that convert cleanly to glTF can move across. Engine-specific rendering, physics, UI and networking do not transfer directly. Those systems depend on the original runtime. Custom effects need new shaders or materials for the Sneeze rendering model, while service logic needs the host-function API instead of engine-specific calls.
That makes migration a conversion job rather than an import button. The architecture preserves the distinction between content that crosses the runtime boundary and systems that remain coupled to a game engine.
Server-side adapters provide another route. An existing application can run as a backend service and expose model data through the browser protocol, while Sneeze renders the result on the client. That route trades direct client execution for compatibility with existing server infrastructure.
Open standards, mixed maturity
The engine stack draws from the Khronos Group, the W3C and existing internet standards. ANARI handles rendering abstraction. OpenXR handles XR device interaction. glTF, KTX and SPIR-V cover 3D assets, textures and shader bytecode. WebAssembly runs service logic.
The Metaverse Standards Forum hosts OMBI as an open project for standards organisations, technology companies, developers and researchers. RP1 contributed a working prototype and leads the engine architecture and maintenance.
The project’s open-source plan puts implementation beside standardisation. Code, documentation, test cases, reference services and developer tooling all fit the contribution model. The final code URL remains the missing practical detail at press time.
Academia joins the build
The University of Rochester has launched the Open Metaverse Academic Alliance through its Center for Extended Reality. The alliance brings universities, researchers, educators and professionals into spatial standards work.
Its current focus includes OMBI. Participants can contribute use cases, conduct research, evaluate proposals and work on the open-source engine. The alliance also connects academic work with enterprise partners and student training.
Two AWE sessions, one booth hunt
The Metaverse Standards Forum and RP1 present Sneeze at AWE USA 2026 in Long Beach. The conference runs from June 15 (Yesterday) to June 18. Sean Mann and Neil Trevett will discuss the browser initiative on June 16 at 4:30 PM in Room 101A. A working roundtable follows on June 17 at 1:40 PM in Room 103B. The Forum and Khronos occupy Booth 104. RP1 occupies Booth 928. The first native browser built with Sneeze is due for discussion and demonstration during the event.
The useful boundary
For artists and pipeline teams, the immediate technical point is the runtime boundary. DCCs create assets. glTF, KTX and SPIR-V carry compiled output. WASM carries service logic. The SOM combines live scene state from separate operators.
Sneeze packages those pieces into an embeddable engine rather than a single proprietary application. Its design defines the architecture in substantial detail, while the missing repository blocks code-level inspection before launch.
Open standards case and initiative scope.
https://omb.wiki/standards
Architecture, SOM, WASM, rendering and content pipeline.
https://omb.wiki/sneeze
Original OMBI project page.
metaverse-standards.org/open-metaverse-browser-initative
OMBI launch announcement.
https://metaverse-standards.org/news/blog/introducing-open-metaverse-browser-initiative/
Forum homepage and project context.
metaverse-standards.org
Open Metaverse Academic Alliance.
https://www.rochester.edu/university-research/initiatives/extended-reality-research-and-application-extrra/open-metaverse-academic-alliance-omaa/
Open Metaverse Browser Architecture PDF.
https://cdn.rp1.com/product/Open-Metaverse-Browser-Architecture.pdf
AWE 2026 sessions.
https://www.khronos.org/events/awe-2026
