Museum Virtual Exhibition Halls: Which Budget Line Keeps Them Alive?
museum virtual exhibition hallvirtual exhibition budgetdigital museum planningvirtual venue ownershipself-hosted virtual exhibition3D exhibition hall maintenancemuseum digitisation costbrowser-based 3D museum
The liveliest day in the life of an online exhibition hall is acceptance day. Leadership clicks through it, colleagues forward it, someone posts it. Then it goes quiet — and six months later the link still resolves, but nobody can say clearly why it exists.
Technology is rarely the cause of death. Most online exhibition halls die of having no department that owns them.
This piece is not about modelling or rendering. It is about something earlier: which budget line the money sits on largely decides how long the thing lives.
Up front: what we provide is a browser-based 3D base layer that you deploy on your own server (Genesis, also registered as 创世虚拟世界CRM系统). We do not take showroom building projects and do not send implementation teams. This article is about budget and ownership, not a pitch.
License terms: the source is available (source-available); running it locally costs nothing. Networking, commercial use, and federation requires a subscription license. Exact terms live in the repository LICENSE / EULA.
Four things this piece covers
- How online exhibition halls usually die
- One budget is actually three budgets, and most institutions approve only one
- How the choice of budget line changes the outcome
- Three sentences that can go straight into a project document
1. Four ways to die, none of them technical
Collected from what we see, the failure modes cluster into four shapes:
| Failure | What it looks like | Root cause | Who usually owns it |
|---|---|---|---|
| No entrance | Not on the website, no menu slot in the official account, the QR code lived on one backdrop for a single day | Nobody wrote the entrance into any process on launch day | Communications / social |
| Cannot be edited | Swapping one exhibit means waiting for scheduling, a quote, and someone else's calendar | The content is not in the museum's hands | Exhibition / IT |
| Expires | One day it returns 404; domain or server unpaid | Domain and server registered under the vendor's name | IT |
| Never updated | Content frozen at the year the gallery opened | No named owner | Exhibition department |
All four share one property: none of them is visible on launch day; all of them happen within the first year. That is why careful acceptance testing does not catch them — the acceptance sheet asks whether it opens, whether the picture is complete, whether the content matches. No line asks who runs it next year.
2. One budget is actually three
This is where it usually goes wrong. When people say "the budget", they mean one of three.
| Budget | Nature | What it contains | If skipped |
|---|---|---|---|
| Build | One-off | Space construction, model processing, staging, deployment | Nothing ships |
| Content | Per change | New exhibitions, new exhibits, label edits, script edits, layout changes | Stale within a year |
| Sustain | Per year | Server, domain, bandwidth, backup, upgrades, someone who can edit | Quiet death |
The usual pattern is to approve only the build budget. Content is funded by "applying again", and sustain is funded by "nobody mentioning it". This is not poor execution; the structure simply left no room for it.
Worth stating plainly: of the three, sustain is usually the smallest amount and the one that decides survival. An unpaid server bill is not a large sum, but once nobody owns the renewal, the other two budgets go to zero together.
3. Different budget lines, different life expectancy
The same exhibition hall behaves differently depending on which door the money comes through. Below is about the nature of the money, not the name of the line — accounting categories differ by institution and region, so check against your own finance office before filing.
| Funded as | How it is usually approved | Upside | Risk |
|---|---|---|---|
| Communications / campaign | Per project, one-off | Easy to approve, fast, hits a date | Project closure is the end; no renewal |
| Exhibition / digitisation programme | Project plus annual | Same origin as physical exhibitions, continuity | Competes with physical exhibition money |
| Public cultural service / education | Annual programming | Real usage scenarios, resists decay | Requires actual programming; a nominal listing decays faster |
| IT / website operations | Annual | Has an operations category that can cover sustain | Tends to be treated as "a website" and given no content budget |
One observation: halls funded as campaigns tend to decay faster than halls funded as education or public service. Not because communications teams care less, but because a campaign's natural rhythm is "finish this wave, move to the next theme". An online hall is not a wave; it is a venue you reuse. Put it inside a campaign rhythm and it will be treated as disposable.
4. Three sentences for the project document
No philosophy, just three lines that can be copied into a proposal or a contract. Each covers the block most likely to be missing.
One: account ownership. Domain, server, and database credentials registered in the museum's name, with passwords changed on the handover day by museum staff. This decides whether changing vendors means changing data.
Two: annual sustain. A separate annual line for server, backup, and version upgrades. The amount scales with your institution; what matters is that the line exists, not how large it is.
Three: a named editor. One staff member designated, trained once at handover. Afterwards, text edits, exhibit swaps, and stand relocations happen in-house without an external schedule. This decides whether the thing is still current after year one.
The third is the one most often skipped, on the grounds that "nobody here can do it". It is also the one worth insisting on: if nobody in the building can ever edit it, then every edit is a procurement.
Above: the admin dashboard of a self-hosted world — world count, online users, and the status of the Web Service, Database, and WebSocket processes. In operational terms, the sustain budget is these three rows. If any goes red, the public link stops opening. That is why sustain needs an owner: it is not an abstraction, it is three things that can fail.
5. How technology selection supports those sentences
If you have decided to keep the accounts and the editing rights, four hard requirements follow. They are vendor-neutral; any option can be measured against them.
| Requirement | Why it matters | How to check |
|---|---|---|
| Data exports as a whole | Decides the cost of switching vendors | Ask them to export on the spot; see whether it imports back |
| Accounts on your own server | Decides whether a platform shutdown affects you | Ask whether it opens on an intranet with no internet |
| Content edits need no code | Decides how expensive the content budget is | Have a content person change one thing; time it |
| No per-seat or annual revenue share | Decides whether sustain grows with headcount | Ask the billing basis, then ask the bill at double the users |
The first two are about survival; the last two are about long-term spend. The order cannot be reversed — secure the data and the accounts first, then talk about how pleasant editing feels.
Above: the world open in a desktop browser. The front end is for visitors; the back end is for the institution. Acceptance looks at this picture; survival looks at the previous one.
6. When not to build one
Honestly, video and editorial pages are the better spend in these cases:
- For a single event or opening. Nobody opens it afterwards; the spend is sunk
- Single-digit opens per year. Sustain cost does not amortise; the money is better spent on the physical gallery
- Nobody in the building can take the accounts (tight headcount, high turnover). Solve the people problem first, or you return to "hire someone every year"
- Unreleased collections, unclear rights, undefined approval workflow. These are institutional problems; no technical option routes around them
7. Boundaries
- We have no museum customer case studies to cite. The judgements above about failure modes come from our own experience deploying and maintaining this system — not from any museum's operating data, and not from a sample survey
- Accounting categories vary widely by institution and region. This article discusses the nature of the money (one-off, per change, per year) and is not financial or project-approval advice
- The four requirements are generic questions, and satisfying them is not implied for any particular option
- Phone performance on real collection content must be measured on the target devices with your own models
8. FAQ
With a small budget and time for one thing, what comes first?
The editing path, not the prettier picture. A mid-quality hall you can edit is still alive in year two; a beautiful hall you cannot edit is an expired rendering in year two.
Does campaign funding guarantee a short life?
No, but it requires an extra move: pull the sustain line out of the campaign budget and write into the closure paperwork who does what, on what cycle. Without that step, closure is the end.
Can the vendor host the server?
Yes, with two clauses: whole-database export executable on request, and account ownership with the museum, the host holding operations rights only. Without those clauses, hosting becomes lock-in.
What if the museum has no technical staff?
Two routes: a small annual maintenance contract that specifies what is done (not just the word "maintenance"), or a system where editing content needs no code, so content staff can change text, swap exhibits, and move stands.
How do we judge whether it was worth it?
Count the concrete occasions it serves: visitor guidance, school programmes, loan-exhibition promotion, leadership briefings, previews for upcoming exhibitions. One occasion is usually not worth it; three or more is where the cost amortises.
Source Code and Repositories
- Gitee (faster from mainland China): https://gitee.com/miduoxinxijeji/miduo.git
- GitCode (mirror for mainland China): https://gitcode.com/qq_35054471/virtual-world
- GitHub: https://github.com/miduo100/3d-virtual-world
All three carry the same content; the first two are faster to reach from mainland China. The repositories contain the deployment guide and a demo entry point.
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, a federation system, 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.
The expensive part of an online exhibition hall is not the day it is built, but every year after; whether that cost can be held down is decided at build time, by who keeps the accounts, the data, and the editing rights. SEO / AI keywords: museum virtual exhibition hall, virtual exhibition budget, digital museum planning, virtual venue ownership, self-hosted virtual exhibition, 3D exhibition hall maintenance, museum digitisation cost, browser-based 3D museum
On the name: Genesis here is also registered as 创世虚拟世界CRM系统 (Chuangshi Virtual World CRM), a browser-based, self-hosted 3D world base layer. Searching "Genesis 3D" may not find it; searching 创世虚拟世界CRM will.