From the Designer's Model to a Visitor's Browser: Six Handoffs in Between
how to publish a 3D model on a websiteuploading models to the web3D showroom building processGLB model optimization3D model compressionhow to fix slow 3D scene loadinghow to display 3D models on a web page3D virtual world base layerbrowser 3Dsource-available
A showroom project, from design to a visitor being able to open it on their phone, crosses a stretch of road that nobody states explicitly — yet every stage of it loses people. This article takes that road apart: not about implementation, only about handoffs — whose hands the model passes through, in what format it comes out, who is responsible for its size, and which stage can stall the whole chain.
Stated upfront: we provide a web 3D base layer that runs on your own server (Genesis / a.k.a. the Genesis Virtual World CRM). We do not take showroom building projects and do not send a team to implement. This article is a map for everyone along that chain, not a sales pitch.
Licensing terms: the source is available (source-available); it is free to run locally; online, commercial, or federated use requires a subscription license. Exact terms live in the repo's LICENSE / EULA.
1. Six stages
Look at them one at a time and you can tell where things stall.
| Stage | Whose hands | Deliverable | What goes wrong here most often |
|---|---|---|---|
| 1 Design and modeling | Designer | Modeling source files | Things the browser never needs are carried through as-is |
| 2 Export | Designer | Model file | Wrong format chosen, full round of rework |
| 3 Optimization | Whoever is in the middle | A model that can go on the web | Who does it and whose cost it is — almost never stated |
| 4 Staging | Implementer / designer | Scene configuration | Circulation and sightlines are design intent, and they get lost |
| 5 Launch | Technical party | A URL | Whose server, who maintains it, how updates get in |
| 6 Being visited | Visitor | — | First screen on a phone, and how long the load takes |
Six stages, and stages 2 and 3 break the most often. The reason is simple: a designer's standard of delivery is "the model is accurate," while the browser's standard is "the model can run over a network." Those two standards do not overlap.
2. Stage 2: choosing the wrong format costs a whole round
This is the most expensive trap, because it surfaces too late.
| Format | Characteristics | When to use it |
|---|---|---|
| GLB / GLTF | Native browser-friendly, compact | Default choice, especially anything going on the web |
| FBX | Exported by most modeling software, needs conversion browser-side | Use it only as an intermediate, never upload it directly |
| OBJ | Simple, old, carries no animation or material info | Generally avoid unless there is a special reason |
| VRM | Bones and expressions built in, oriented to characters | Use it when there is a character model |
| Other 3D asset formats | Varies | Confirm the browser side can handle it |
The one question to ask: is this model going on the web for people to view, or is it only for producing images?
Models that exist only to produce images are often exported without optimization — high-resolution textures, hundreds of thousands of triangles, possibly unmerged objects. None of that hurts image rendering; all of it is a disaster on the web.
⚠️ One more easily missed item: skeleton animation compatibility. Whether a character model and its animations exported from different tools will work together is not a default truth. If your model contains animation (say, a virtual guide moving around the showroom), verify this separately — do not discover at launch that nothing moves.
3. Stage 3: optimization — who does it, and whose cost is it
What optimization actually means:
- Reducing triangle count: distant models do not need that much detail. Three versions at different levels is the cheapest approach
- Compressing textures: textures are usually the bulk of the file size. Compressing them does not touch geometry, so model shape is not lost
- Stripping unused data: hidden layers, editor objects, unused materials
- Merging same-material objects: reduces draw calls
"'It doesn't affect the look' has a precondition" — texture compression genuinely does not change geometry, but over-compressing makes surfaces look mushy up close. So the accurate phrasing is "handled by grade according to purpose," not "we compressed it and you cannot tell."
The core of this stage is ownership:
- Optimization done by the technical party → a workload that belongs in the quote
- Pushed onto the designer → unpaid time they did not price in, and they may not know how
- Done by nobody → the browser does it for you, at the price of every visitor waiting
The third is the most common default and the most expensive. Because the cost does not disappear; it transfers into every visitor's wait.
4. Stage 4: staging loses intent, which is more costly than technical problems
This stage is where the designer's work lives: which path a visitor walks, what they see first, which exhibit sits at eye level.
Above is the in-browser 3D editor. Staging happens in this interface — placing models, adjusting properties, setting the initial camera angle. And because it is editable, "revising one version" becomes a few clicks rather than a rebuild.
Above is a live phone-browser view: virtual joystick, voice, camera and jump controls. The final reader of a showroom is holding a phone, so touch interaction has to be thought about during staging rather than patched in at the end.
That intent is most easily erased at the moment models are placed in a scene.
Common ways it is lost:
- The model's default orientation is wrong, so visitors walk in on the back of the exhibit
- Positions are computed from the model origin rather than from the side the exhibit is meant to be viewed from
- The initial camera angle is the default one rather than the "first view on entry" agreed during design
- Equipment is placed where it can technically fit but nobody can reach or see it
⚠️ Worth saying plainly: none of these are technical problems. They are all "did anyone ask the designer" problems. The time in this stage goes into communication, not rendering.
5. Stage 5: launch decides whether this thing outlives the project
The model is processed. Now it has to go live. The things decided here all determine whether it keeps running.
| Question | What happens if it is undecided |
|---|---|
| Whose server it deploys to | Data and models end up in unclear hands, and unclear hands eventually cause trouble |
| Who maintains it | Three months later nobody owns it, and the system decays |
| How content gets updated | Changing one thing means redoing everything, so every update is a rebuild |
| Whether the data can be taken back | This one matters most — see below |
On "can the data be taken back," the question needs to be specific. Asking "can you export it?" is not enough. You need to know:
- Is the model a common format (GLB) or a proprietary one
- Is there an export path that takes the whole library
- Who holds access permissions, and whether switching providers means reconfiguring from scratch or migrating directly
This line determines what switching costs. If the answer is "the whole thing is proprietary and only we can maintain it," then the project has no exit mechanism — regardless of how smooth the current collaboration is.
6. Stage 6: the visitor's first screen
The first five stages all exist to serve this one. And this stage is the only acceptance criterion.
There is one hard fact: most showroom visitors open it on a phone, in a meeting room, on the road, or on site with the client.
So what you should check is not "it loads in one second on my computer" but:
- Is the first screen on a phone white, or is there an image
- How much has to load before there is anything to look at
- Is there a "loading" state, or do they just wait
- On a weak network, does it hang at some percentage forever
⚠️ On that last one: a progress bar that moves steadily to the end is more trustworthy than a percentage that jumps around. A client watching 30% stall for ten seconds is more alarmed than one watching 30% → 50% → 70% — because the latter at least shows progress.
7. The thing most often missed
Across the whole chain, every stage delivers "a file." But what this project actually delivers is an address that stays up.
Files can be handed over. Things that are running need someone watching. That is why "who maintains it" cannot be discussed separately from "launch" — they are the same decision: whether this belongs to a system or to a person.
If it belongs to a system: updates must be able to change part of it, not rebuild everything.
If it belongs to a person: that person must still be there after the project ends.
FAQ
Q: Can't the designer just export the model and send it over?
A: They can — but ask first whether that model is for image production or for the web. A model built for rendering, uploaded directly, is heavy on the browser side: it carries editing-time redundancy and usually has no detail tiering.
Q: Is optimization mandatory?
A: Yes. Not for looks — for "the client does not experience lag." Option comparison and product presentation both put the client's attention entirely on the picture, and lag gets read directly as a quality problem.
Q: Who should do the optimization?
A: Whoever has the tools and the standard. The cheapest way to decide: whoever can produce a reproducible check result (size, triangle count, whether tiered versions exist).
Q: My model is only one or two gigabytes — can't I just upload it?
A: The fact that one machine can open it does not mean a visitor can. Size, textures, and loading strategy are one problem together. And if this showroom is going to be visited on phones, the size problem gets amplified.
Q: How do I avoid rebuilding everything on the next update?
A: This is a stage-5 decision — design updates as partial replacement and only the changed parts get touched; design them as full-package replacement and every update is a rebuild. Ask this before the first launch.
Q: Which stages does this base layer help with?
A: Stage 3 (three-tier LOD generated on upload, GLB texture compression) and stage 6 (loading strategy, placeholder field, progress feedback) are what we cover. Format choice in stage 2, staging intent in stage 4, and operational ownership in stage 5 have to be decided by the people on the project — no tool does those three for you.
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.
Have a "from model to visitor" job to push forward? Genesis (a.k.a. the Genesis Virtual World CRM) is a web 3D virtual scene base layer that runs on your own server and does not provide building or implementation services — what it covers is the optimization and loading stages: three-tier LOD generated on upload, GLB textures compressible by sixty to ninety percent with geometry untouched, distant models that do not turn into blue boxes, and loading with progress and placeholder feedback. The source is available; run it locally free of charge; online, commercial, and federated use require a 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".