Running Several Web 3D Showrooms a Year: Where Does the Content Live?
managing multiple 3D showroomsvirtual showroom content archiveshowroom version managementweb 3D showroom deployment3D model library reusemaintaining a virtual showroomvirtual showroom URL structureself-hosted 3D showroom
Your first 3D showroom raises concrete questions: how to import the models, whether the client's phone can open it, how long it takes to load. By the third or fourth, the question changes: where is the last one?
A client digs out last year's option and asks whether it still opens. You go looking through a designer's chat history, a USB stick, or a cloud host that expired in spring. Finding it is luck. Not finding it is normal.
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 about organising content across several showrooms, not a 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.
Three things this article covers
- Why "more showrooms" always turns into a problem — and which layer actually breaks
- Two mechanisms: one site per event, or one base layer with several spaces under it
- How to split content into layers, and who owns each one
1. Which layer "more" actually breaks
First, be precise: there are two kinds of "more", and they fail differently.
| Kind of "more" | What it looks like | Where it hurts |
|---|---|---|
| More versions | The same showroom revised N times | Nobody can say which is final; the client may still hold an old link |
| More events | Different events, product lines, or years, each with its own showroom | Cannot find it, cannot get in, nobody owns it |
Version sprawl is a problem of provenance. Event sprawl is a problem of entry points. The same fix does not solve both — the first needs version rules, the second needs a directory structure.
What makes both worse is a third thing: content scattered across people.
- The models sit on the designer's machine
- The staging files sit with whoever did the build
- Last exported model is buried in a chat thread
- The link the client holds points at a host that expires this year
At that point, whether you can find something does not depend on how well you remember it. It depends on whether everyone in that chain is still there. When one person leaves, the archive breaks.
2. Two mechanisms
Strip it down, and there are two paths.
Path A: one separate site per event. Spin up a new place each time, hand over the link. It is clean and self-contained for that event. The cost is that every new event adds another place to maintain, renew, and keep the password for. By the fifth, you cannot tell which link belongs to which event.
Path B: one base layer with several spaces under it. The base is deployed once (on your own server). Each event is a space under it, sharing the same accounts and the same model library. Another event means another space — not another system.
The difference is not which one looks better. It is what the incremental cost looks like:
| Path A: one site per event | Path B: one base, several spaces | |
|---|---|---|
| Adding an event | New environment, configured again | A new space in the base |
| Accounts | One set per site | One shared set |
| Reusing models | Re-upload every time | Same library, referenced directly |
| Finding old content | Depends on someone remembering a link | It is in the space list |
| Who maintains it | Nobody, after handover | You, on your own server |
| Who you call when it breaks | The platform | Yourself, or a technical partner you name |
Path B is not free: someone has to deploy the base and keep it running. That work does not disappear. The advantage is only that it happens once, rather than once per event.
The image above is the in-browser 3D editor. On the left is the model library (115 models uploaded at the time of the screenshot); in the middle, the scene viewport; on the right, the object list and properties panel (this scene contains 1,074 objects). Once a model is in the library it is shared across the whole base — a second showroom does not re-import it.
3. Three content layers, three owners
Deciding who owns which layer matters more than picking a tool:
| Layer | What lives here | Who owns it | How often it changes |
|---|---|---|---|
| Model | Equipment models, booths, characters, textures | Designer / modeller | Low — set once |
| Space | Staging, circulation, initial camera for this event | Implementer / designer | Medium — once per event |
| Access | URL, accounts, who can view, when it comes down | Client / contact | Low, but forgetting it causes trouble |
The access layer is the one nobody owns. It is three lines — who sees it, at which URL, and when it closes — but if those three lines are never written down, six months later nobody knows them.
Two rules keep the layering from being decoration:
- Name models on the way in. Write what the device is. Avoid names like
booth_final3_rev.glb. Once the library grows, naming is the only index you have. - One note per event. Which space, for whom, and when it can be taken down. A single page is enough.
The image above is the world in a desktop browser. The same content opens in the same world on a phone — a side benefit of Path B: visitors do not install anything per event.
4. What an update actually touches
Once several events coexist, the practical question is: content changes.
A product line is replaced, a price card changes, a booth moves. The steps depend on how the content was stored in the first place:
- Same models, only position or copy changes → adjust inside the space; this is staging work
- A model itself is replaced → the new model enters the library, and the space's reference is swapped
- The event is over and you want to keep it → leave the space alone and remove it from the access layer
These three cost very different amounts: the first is minutes, the second depends on how large the new model is, and the third costs almost nothing. Sorting out which kind you are dealing with beats starting to click.
5. What to settle before you start
If you are taking Path B, these need deciding up front:
- A server of your own (or a clear hosting arrangement), and who operates it
- A naming rule for spaces (by year? by product line? by client?)
- Who gets an account, and who is the administrator
- Who writes the access note for each event, and where it lives
- A naming convention for models entering the library, and one file format (GLB / GLTF first for anything going on the web)
None of these are technical. They are agreements. Made early, they save an argument six months later.
6. When this approach is the wrong fit
Said plainly, so nobody spends effort for nothing:
- One showroom a year, never looked at again → a single separate site is less work; you skip carrying a base layer
- You want a vendor to handle everything, including the content → this is a system you run and edit yourself, not a build service
- You do not want to touch servers or domains at all → a hosted product fits better than self-hosting
- You only need a few static renderings → images are enough; 3D is overkill
7. Limits of "open it anytime"
A few honest notes:
- This base layer does not store your content for you. It lives on your server, and both the server and the data are your responsibility
- "Anytime" assumes the server is paid up and the domain has not expired — nobody else can do those two things for you
- We have not measured this at the scale of a real client running many shows over years. The library and object counts quoted here come from our own development and test environment, not from a client's long-term operation
- How many spaces your setup can hold, and how many people it can serve at once, has to be measured against your own server — our test figures do not transfer
8. FAQ
Can several showrooms sit under one URL?
Yes — separate space entries under one domain, so you only track one address.
Can a client see one event without seeing the others?
Access can be scoped per space. For account-level granularity, test it against the way you actually work.
Can two showrooms share one equipment model?
Yes. Once a model is in the library it is shared across the base, which is where this saves effort over one-site-per-event.
When an old event is taken down, is the content lost?
Taking it down removes the public entry; the content stays on your server, depending on how you back it up. Backups are yours to arrange — the system will not keep them for you.
How long does an update take?
It depends on which kind of change it is — moving something is quick, swapping a model depends on the new model's size. There is no figure that transfers from someone else's project.
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.
- 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.
Decide which kind of "more" you have before deciding whether you need a base layer. 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 showroom building or implementation services. 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".