How Far Is This 3D Virtual World Base Layer Built: The Layers Below Are Running, and Ninety Percent of Headroom Sits Above
3D virtual world base layerself-hosted 3D worldThree.js foundationbrowser-based 3D3D world developmentAI agent accesscross-world federationprivate 3D deploymentvirtual world roadmapMCP Server
A question we get often: this base layer of yours — how far along is it, exactly?
The question resists a single "percent complete" answer, because the number depends on which ruler you use. This article lays out both rulers. One measures whether the base layer is usable today — it is: a fully usable self-hosted 3D virtual world foundation whose lower layers are running right now. The other measures how far the direction can still go — if the endpoint is "what a browser-based 3D virtual world can eventually become," we stand at roughly 5%–8%. These two statements must be read together: the base layer is fully usable, and more than ninety percent of the headroom remains — the first is a statement about the present, the second about opportunity, not about something unfinished.
1. The layers below: what is running today
Between the engine and your business logic, these layers are built and covered by re-runnable acceptance scripts:
| Layer | What is built | Citable acceptance numbers |
|---|---|---|
| Rendering kernel | Three.js r128→r185, WebGL2, CDN-free (87-symbol shim) | 6-stage full acceptance, corrected color pipeline |
| Asset pipeline | Three-tier LOD, GLB asset surgery, 3DGS photographic scenes | 118 low-poly variants ≤100 faces, textures −68%~−92%, 3DGS 26/26 |
| Performance governance | Draw-call governance, light pool, shader warm-up, placeholder field | 3064→837, an 8989 ms freeze eliminated, worst-case first arrival 386 ms |
| Multi-client adaptation | Capability tiers (high/mid/low/XR), input abstraction | Desktop first screen 838 KB / 1.7 s |
| Real-time communication | Weak-network reconnect self-healing, voice quota system | 9/9, 10 concurrent speakers ≈ 1.3 Mbps |
| AI access | Humanoid agent three-step onboarding, MCP Server, action set | ≈1 KB/s per agent, 100 agents measured at 0.079 CPU cores |
| Cross-world federation | Identity migration, same-name auto-rename, protocol layer | 4/4, protocol fixes 15/15 |
| Asset hygiene | Orphan-asset audit and cleanup | 2.9 GB removed, directory 3.1 GB→390 MB |
The point of this table is not "we did a lot." It is: if you build a browser-based 3D virtual world, this engineering exists regardless of your business — whether you build a showroom, training, or a community on top, these layers have to exist. They have been verified repeatedly by a real, running world.
2. What the 5%–8% means
To be exact: if the eventual form of "browser-based 3D virtual worlds" were 100%, the base layer's current capability surface covers roughly 5%–8%.
Read that number as opportunity, not debt. It means: on top of a fully usable base — enter, walk around, multi-user, AI access, cross-world — more than ninety percent of directions remain open, and every layer can still grow a great deal. This is a fundamentally different state from "in development, not finished": the base layer is fully usable, deployable today, ready for your business logic today. The ninety percent says how far you can go from here, not that you cannot get anywhere.
3. What sits above: four planned items
The roadmap above the base layer, ordered by distance. A shared precondition first: everything in this section is planned and not implemented — do not evaluate any of it as a shipped feature.
| Planned item | What it aims to solve | Why it is next on the road |
|---|---|---|
| AI-assembled worlds | Let AI generate and place scene assets from descriptions | The AI-description chain exists (object semantic descriptions 9/9); extending toward "generate and place" is the next step in the same direction |
| Agent store | A place to publish and install agents built by others | The access protocol is open (MCP Server is live); what is missing is the distribution and trust layer |
| Agent interoperability (A2A) | Agents inside a world collaborating instead of acting alone | The single-agent action set is proven (8 actions); multi-agent collaboration is a new protocol layer |
| Cross-world federated AI | Agents carrying credentials working across worlds | Cross-world identity migration works (same-name auto-rename 4/4); the AI-side credential and permission design has not started |
Why a table rather than a vision board: because every row maps to "which foundation step is already proven, and which segment is missing." A plan anchored to accepted ground is a next step; a vision not anchored to anything is a wish.
4. Layer 5: what you can build right now
A finished base layer does not mean waiting for the roadmap. Your business logic — layer 5 — has a complete landing surface today:
- Showrooms and displays: place equipment and exhibits into a world, with a guide AI leading tours (the AI enters as a humanoid character, is visible to real visitors, can speak and guide — and it cannot see the screen, does no speech recognition or synthesis, and hosts no knowledge base; those boundaries are written into the onboarding docs).
- Training and rehearsal: new staff practice reception and operations in the browser — no shipping demo units, no gathering everyone in one room.
- Communities and interest worlds: self-hosted worlds with your own rules, data on your own server.
The layers beneath these scenarios — rendering, assets, multi-client, communication, AI access — are usable today. The relationship between the base layer and the roadmap is "you can start now" plus "it gets better later," not "wait and see."
5. What this base layer does not suit
Honest disqualifiers:
- You want generative world-building — type a sentence, get a complete world. That is a roadmap item; it does not exist today. The base layer provides the engineering of a world, not a world content generator.
- You want a hosted service — no servers, someone else runs it. The base layer's stance is self-hosting: data on your server, operations in your hands. If you want full hosting, this is not that path.
- One-time budget with no maintenance appetite — self-hosting means environment, updates, and backups need an owner, even with deployment docs and acceptance scripts as a safety net.
6. Boundaries and unmeasured items
- The progress figure (5%–8%) is an estimate of "capability surface as a share of the direction's endpoint"; there is no objective ruler, and different people will measure differently — treat it as direction, not precision.
- Every number in table one comes from re-runnable acceptance scripts in the repository (54 of them), measured on desktop; mobile and XR field performance we have not yet completed full measured testing on.
- The four roadmap items in section three are all unimplemented; "which foundation step is proven" refers to the capabilities they depend on, not to progress on the items themselves.
- The paid B2B path is still being validated; this article cites no customer cases.
FAQ
Q: When do the roadmap items ship?
A: No dates. What we can give is the ordering and the rationale: each item stands on accepted base-layer capabilities (see table three's "why it is next on the road"), and the pace follows feedback from the scenarios on sale. Promising dates and missing them costs more credibility than not giving dates.
Q: Isn't 5%–8% awfully small?
A: It depends on what 100% means. If 100% is "a walkable self-hosted 3D world," the base layer is already fully usable. If 100% is "what this direction becomes in ten years," then 5%–8% is the honest number — and it means exactly that people who join now have an enormous space to help define.
Q: Will base-layer updates break my layer-5 code?
A: That is precisely what "base layer" means as opposed to a throwaway rig: updates and support follow the subscription, and the interface toward upper layers is something the design is obligated to protect. For concrete compatibility commitments, rely on the repository's documentation — not on blank guarantees here.
Q: Why believe the layers below are actually "running"?
A: Don't trust me — trust the scripts. The repository ships 54 acceptance scripts (LOD 23/23, Agent 75/75, 3DGS 26/26, skeleton regression 67/67…), judged by real exit codes plus JSON reports. Clone and run them yourself.
Source & Repositories
The three mirrors are identical; the first two are faster inside China. The repos include deployment docs and a set of acceptance scripts you can run yourself to see the measured numbers.
- Gitee (fastest in China): https://gitee.com/miduoxinxijeji/miduo.git
- GitCode (China mirror): https://gitcode.com/qq_35054471/virtual-world
- GitHub: https://github.com/miduo100/3d-virtual-world
About Genesis
Genesis is a self-hosted 3D virtual world system built on Three.js + WebGL, helping individuals and businesses build their own 3D spaces. Accessible directly from a browser, compatible with both PC and mobile, it supports multiplayer online, federated teleportation, a shop system, and Agent integration—where an AI can enter your world as an embodied character. Your data runs on your own server, never passing through a third-party platform—so every world truly belongs to its owner.
Ready to write your own layer 5 on this base? Genesis (a.k.a. the Genesis Virtual World CRM) is a Three.js 3D virtual world base layer that runs on your own server — rendering kernel, asset pipeline, multi-client adaptation, real-time communication, and AI access are built and fully usable. The source code is open; run it locally free of charge. For online use, commercial use, or federation, take the subscription license. Search "Genesis Virtual World CRM" to find the site with a walkable demo world.
About the name: Genesis in this article is the same self-hosted 3D virtual world product also called the Genesis Virtual World CRM. If "Genesis" does not find us, search "Genesis Virtual World CRM".