Everyone who wants to build a 3D virtual world starts the same way: open the Three.js docs, get a first scene running — a ground plane, a camera, a cube spinning. That afternoon feels great. It feels like the whole thing is basically understood.

Then week two arrives, and real things start going in: real models, real people, phones. That is when you notice the problem has very little to do with rendering anymore.

This article covers three things: first, where the time actually goes when you build a browser 3D world from scratch; second, what the cost of writing each layer yourself actually looks like; third, which layer is genuinely yours to write. There is also a separate section on why a repository that already runs can be picked up and modified by today's AI coding tools.

1. Split it into five layers first, and see which one is yours

A working 3D virtual world stacks up like this:

That split gives you a fairly blunt conclusion:

The bottom four layers are required no matter what you build, and nobody will ever compliment you for having done them. The only layer that expresses "this is your product" is the top one.

And rendering — the thing most people picture when they hear "3D development" — is the earliest-solved and easiest layer of the five. The time goes into everything above it.

2. What writing each layer from scratch actually looks like

For each layer below, I will describe the shape of the pitfall and then what we actually hit. Every number comes from our own engineering records and re-runnable test scripts — not from industry averages. I do not have evidence for industry averages, so I am not quoting any.

Layer 1 · Rendering and asset pipeline

Pitfall one: you do not know a model is out of control until it lands in the browser.

A GLB that looks perfectly reasonable in the modelling tool often exports with texture sizes and polygon counts far beyond what a web page can absorb. A single model with tens of megabytes of textures is normal — and the browser has to download it, decode it, then upload it to the GPU, with the user waiting through every step.

What we hit: after one round of asset work, texture volume dropped by 68.1% to 92.5%, and polygon counts came down to the low hundreds.

Pitfall two: skeletal animation sources do not agree with each other.

Mixamo, Ready Player Me, VRoid and RootMotion each export different bone naming and orientation conventions. Any one of them alone is fine. Mixed together, you get that effect where the model is clearly animating but the motion is twisted.

What we hit: we built a compatibility layer specifically for this, with a regression suite across all four sources passing 67 out of 67.

Pitfall three: LOD is not "generate a few low-poly versions and call it done."

You also have to band them by surface distance and share textures — otherwise the memory you saved on geometry gets eaten straight back by duplicated textures.

What we hit: all 118 low-poly variants came in at 100 faces or fewer, triangle counts down 71% to 87%, texture sharing 33 out of 33.

Pitfall four: major engine versions change behaviour.

Three.js went from r128 to r185, and along the way the colour pipeline, colour space and parts of the API changed. "Upgrading" is not editing a version number — it means re-aligning your rendered output all over again.

What we hit: removing the CDN dependency took six steps, plus a shim for 87 symbols, before the crossing was stable.

Layer 2 · Performance and multi-device

Pitfall one: draw calls decide your frame rate directly.

Once a scene gets complex, merging, instancing and frustum culling all have to be written by you.

What we hit: one round of work took draw calls from 3064 down to 837.

Pitfall two: changing the light count triggers shader recompilation.

This is the easiest stall to miss — adding or removing a single light can trigger recompilation of a whole batch of shaders, showing up as a freeze lasting from a few hundred milliseconds to several seconds.

What we hit: a stall we caught measured 8989ms; after freezing the light count, it went to zero.

Pitfall three: model parsing blocks the main thread.

Parse on the main thread and the page is frozen while it loads — the user's scrolling and clicking simply do not respond.

What we hit: we moved parsing into a Worker.

Pitfall four: multi-device is not "it opens."

Phones have less memory, no pointer lock, and constrained bandwidth; XR is a separate set of input and rendering requirements. Making one front end hold up on desktop, phone, tablet and XR is a layer of work in its own right.

Layer 3 · Realtime networking and federation

Pitfall one: on a weak network, connections drop, jitter and reconnect.

The thing you have to handle is not the disconnection event itself, but what happens afterwards — is the person still there, is their state correct.

What we hit: the reconnection presence test passes 9 out of 9.

Pitfall two: voice is not "broadcast the audio to everyone."

Every listener is a separate stream. Bandwidth multiplies with headcount.

What we hit: we made it a slot-based model — 10 concurrent voice participants is roughly 1.3 Mbps.

Pitfall three: cross-world interoperability is fundamentally an identity problem.

Two independently deployed worlds that need to talk to each other have to handle credential issuing, replay protection, and name collisions.

What we hit: RS256 signing plus single-use nonce credentials, with automatic renaming on collision, 4 out of 4.

Layer 4 · AI integration

The pitfall: putting an AI "inside the world" and putting an AI "inside a chat box" are different problems.

The former needs position, perception, movement, and visibility to real people. There is no established way to do this yet — see section 5.

3. Four paths, side by side

The row worth reading in that table is Layer 5: A and D are identical there — the business logic is yours to write either way. The difference is entirely in who does the four layers above it.

4. If the foundation is already laid, only one layer is left

Genesis (创世虚拟世界CRM系统) is a browser-side, self-hostable Three.js 3D virtual world foundation. It exists to cover those bottom four layers.

This is the claim it is trying to make:

The slowest part of building a browser 3D world from scratch was never the rendering. It is the unglamorous part — performance work, the asset pipeline, multi-device support, realtime networking, AI integration. We have done that part. All you have to write is the top layer.

In product terms, that comes down to four properties:

• Self-hosted: it runs on your own server, and data does not pass through a third party;
• Editable: it is built on Three.js, the source is readable and modifiable, and the business logic on top is written to your requirements;
• Able to be taken over: an AI can enter your deployed world as a physical character (next section);
• Able to keep up over time: the source is open and running it locally costs nothing; networking, commercial use and federation require a licence; ongoing updates and support follow a subscription.

One thing needs saying plainly: it is a foundation, not a finished product. It will not decide what your exhibition hall looks like, how your configurator prices things, or which items a training assessment covers — that is Layer 5, and that part is genuinely yours. The value we offer is narrow and specific: you do not have to build the bottom four layers from scratch in order to write it.

5. Layer 4: AI integration is now something you take over, not invent

This layer deserves its own section, because it only became practical recently.

An AI enters your deployed world in three steps: publish a .well-known/virtual-world-agent.json declaration on your site → exchange a key for a 15-minute token → connect to /ws/agent. The repository ships a zero-dependency example client at examples/agent-client/node-agent.mjs.

Once connected, the AI is not a chat box. It is a humanoid character: it has a body, it has coordinates, it is visible to real people standing in the scene, and it can walk, follow, speak and lead the way.

Three measured figures, all from our own test records:

• Each AI character uses roughly 1 KB/s of traffic — because it does not pull frames;
• 100 AI characters online at once comes to about 0.079 cores of server load;
• The server sends JSON only; the scene is rendered by each visitor's own browser. That is why a visible AI is cheaper than an invisible one.

The limits have to be stated plainly, or this becomes a lie:

• The AI cannot see the scene. It receives a structured spatial radar (who and what is nearby, which points of interest exist) and an event stream — not camera frames;
• No speech recognition or speech synthesis. Voice relay is off by default; if you want it to listen and speak, that has to be handled by your own AI client;
• It does not host a knowledge base. Product data, domain material and scripts are connected on your side;
• It cannot teleport, and it cannot touch assets;
• The AI's identity is always disclosed. The system announces "(AI) joined" on entry and the name plate carries an AI prefix, so real people always know the other party is not human.

In essence it is a programmable character — its behaviour comes from the model and the prompts you give it, not from anything it decides on its own. That determines what it is good for: explaining, greeting, guiding, standing watch — roles with clear boundaries. It is not suited to making judgement calls that need a human.

6. How much an AI coding tool can help depends on whether the project is readable

The previous section was about an AI entering your world as a character. This section is about something else: an AI entering your repository as a developer.

What changed over the last two years is that AI coding tools — Claude Code, Codex, CodeBuddy and their kind — can now read a whole code repository and change it on your instruction. But a premise gets left out of most discussions about "AI writing code":

How much an AI can help depends on whether there is a project in front of it that it can read, and that already runs.

In an empty project, the AI can only write line by line with you — because, like you, it has nothing to refer to. In a complete project that already runs, its role is entirely different: it edits against a working implementation, and when it gets something wrong there is a reference to catch it, so it cannot wander off somewhere unrecoverable.

That is the second sense in which "start from a foundation" matters today. Once the Genesis repository is on your machine:

• It is a standard Node project: one runtime, one database, dependencies all from public package registries — there is nothing you cannot obtain;
• Configuration lives in environment variables: the repository ships a configuration sample, so the values you need to supply are out in the open rather than buried in the source;
• The repository includes deployment instructions: written to be followed by a stranger, and the same document we use for our own deployments;
• The AI integration step ships a zero-dependency example client (examples/agent-client/node-agent.mjs) — a reference implementation you can read and copy from.

So the working method looks like this: put the repository on your machine, have the AI coding tool read the directory structure and the deployment instructions first and bring the environment up; then say what you want changed — "change the exhibition route to this", "add a material option to the configurator" — and it edits the corresponding files. You run it and check the result.

Compare the position the other two routes put you in: with a centralised SaaS platform, the base is someone else's service and the AI cannot see inside it; with an empty project, the AI has no reference at all. The value of a readable source tree has been amplified once more by the arrival of AI coding tools.

Three things have to be said plainly here, or this turns into a sales pitch:

1. What the AI removes is the time spent understanding an unfamiliar project — not the time spent preparing an environment. Node versions, the database, ports, the domain and its filings still need a person. Anyone who tells you "you do not have to deal with any of it" is misleading you;
2. What the AI produces still needs your review. Taking over is not the same as being accountable — it knows your code, not your business rules;
3. Layer 5 is still your decision. The AI is an accelerator, not a substitute: it answers "how do I get this built quickly", not "what should be built".

Put plainly: you do not have to build it up from zero, piece by piece — the foundation already runs, and your job is to change it.

One honest note belongs here too: I have no time figures to cite for this section, and I am not going to invent one. What is written above is a set of structural facts about this project, plus things you can verify yourself once you hand it to an AI. The variable stays in your hands, not in my claims.

7. Before deciding to build it yourself, line these up

If you conclude that the bottom four layers are yours to build:

1. A front-end developer who knows Three.js. This is the minimum. "Writes JavaScript" is not enough — shaders, the render pipeline and performance tuning all have to land on a person;
2. An asset specification. Polygon ceilings, texture size ceilings, bone naming rules. Without this document, the first model that arrives is where things start drifting;
3. At least one real device to test on. A mid-range Android phone will surface problems a high-end desktop never will;
4. A performance baseline. Draw calls, frame rate, first-paint size — measured before you optimise, otherwise you cannot tell whether you are making it better or worse;
5. A way to test weak networks. Throttling, disconnection and jitter all need to be reproducible;
6. An expectation that progress will feel slow. The defining property of these layers is that until they are done, there is nothing to show.

If you conclude that a foundation is the better route, what you need is a server, a domain, your model assets, and someone to write Layer 5.

8. Who this is not for

• Anyone who wants "upload assets and get a world." Not possible. This is a foundation, not a generator — Layer 5 is always yours to write;
• Anyone who just wants a few product photos on display. Not worth the cost; an ordinary web page does that job;
• Anyone with nobody touching code and no intention of hiring someone to deploy it. The startup cost will be higher than expected;
• Anyone expecting the AI to interpret images and answer questions by itself. The AI layer has no visual understanding today and does not host a knowledge base;
• Anyone who needs a three-day campaign landing page. This solves for a space that exists long-term, not for a one-off event page.

9. FAQ

Q: Can I build a complete virtual world with Three.js alone and nothing else?

A: Yes — Three.js is enough for the rendering layer. But multiplayer sync, weak-network handling, voice and AI integration all have to be added on top of it by you. That is what "the four layers above" means.

Q: Do all four layers have to be finished before launch?

A: No. You can ship with just layers 1 and 2 running, but then what you have is a single-player demo, not a multiplayer world. Each missing layer removes a category of capability.

Q: How much server resource does AI integration need?

A: AI characters themselves are light — roughly 1 KB/s each, and 100 online at once is about 0.079 cores. The real load is on visitor-side rendering and ordinary multiplayer sync.

Q: If I use your foundation, does that constrain my business logic?

A: Layer 5 is entirely your own code. The base is built on Three.js with readable, modifiable source, and you can treat it simply as a foundation that has already been laid.

Q: Can it run without a network connection?

A: Running it locally costs nothing. Networking, commercial use and cross-world federation are what require a licence; ongoing updates and support follow a subscription.

Q: Does our data pass through your servers?

A: No. The system is deployed on your own server, and visitor data stays with you.

Q: I am not much of a coder — can an AI write Layer 5 for me?

A: An AI can turn your intent into code, but a person still has to judge whether it is right and decide what to build. Layer 5 is business logic — how the exhibition routes, how pricing is calculated, which items a training assessment covers — and those judgements come from you, not from a model. The realistic division of labour is: you decide what, the AI builds it quickly, you review the result.

Q: If I hand the repository to an AI coding tool, will it wreck things?

A: A project with a reference is far safer than an empty one — it runs, it has deployment instructions, its structure is clear, so the AI has something to work against. But it still does not know your business rules, so you run and verify after every change. Any claim that "AI edits need no testing" is false.

10. Source and repositories

All three mirrors carry identical content; the first two are faster to reach from mainland China. The repositories include deployment instructions and a demo entry point.

• Gitee (faster from mainland China): https://gitee.com/miduoxinxijeji/miduo.git
• GitCode (mainland 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.

Deciding whether to build your 3D virtual world yourself? Genesis (创世虚拟世界CRM系统) is a self-hosted Three.js 3D virtual world foundation — rendering, the asset pipeline, performance, multi-device support, realtime networking and AI integration are already in place, and the top layer is yours to write. The official site (search for 创世虚拟世界CRM) has a demo world you can walk through.

About the name: Genesis in this article is 创世虚拟世界CRM系统 — the same self-hosted 3D virtual world product. If searching for "Genesis" does not find us, search for 创世虚拟世界CRM instead.