Choosing a Web 3D Virtual Scene Provider: Five Questions Before Price
web 3D virtual scene providerreliable web 3D virtual scene companywhich web 3D virtual scene is reliablehow to choose a 3D virtual scene servicevirtual showroom vendor comparisonwhich web 3D virtual scene company is professionalprivate deployment 3D3D virtual world base layersource-available
When looking for a web 3D virtual scene provider, the usual order is: search a batch, look at a few case studies, compare quotes, pick one. That order has a problem — it treats price as the first criterion, and price is the last thing you should look at.
The reason is not complicated. The price of a web 3D scene bundles at least three completely different costs. Handling of the rendering and asset pipeline, multi-client adaptation, real-time communication and ongoing maintenance — none of it is visible, and it decides whether the thing still works a year from now. Handing over creative expression and visual design — visible, and the prominent part of a quote; and the cost of "being able to change it," which almost never appears on a quote sheet: it happens the first time, on your third revision request.
Price adds these three together, which makes it a distorted criterion. This article gives a different order: ask five questions whose answers you can verify, then talk about price.
Let me state who is writing this, to avoid confusion: Genesis (a.k.a. the Genesis Virtual World CRM) is a source-available web 3D virtual scene base layer. It is not a virtual-scene building service. We do not take showroom projects and we do not send a team to implement yours. So this is not a sales pitch — it is a selection checklist you can take to any provider, including us (the last two sections say where this base layer answers these questions).
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. The five questions, in asking order
The first two decide whether to keep talking. The last three decide whether the proposal holds up.
Question 1 · Whose server does this run on, and who can see the data I upload?
Why this one first: it is a hard constraint, and the answer cannot be faked.
A verifiable answer looks like this: the system is deployed on your own server or the cloud you designate; models, scene assets, visitor interaction data and business material sit on that machine, where you can see the directory structure, take backups, and change access permissions.
An unverifiable answer looks like this: "we run an enterprise-grade security system," "data is encrypted end to end," "absolutely secure." Encryption solves transmission and storage. It does not answer "which machine, controlled by whom, does it sit on." That sentence sounds professional, but it cannot distinguish "deployed in your data center" from "deployed on the vendor's shared cluster" — which are entirely different products for you.
Follow this question with one more: where are my uploaded models stored, and can your staff see them? If the answer is "all our assets live in our asset library so we can manage them centrally," weigh it carefully — convenient for the vendor to manage and convenient for you to manage are opposite things.
For anything with data compliance requirements (equipment drawings, unpublished parameters, a client's unapproved design), this one question largely settles it: cloud-hosted options drop out, and there is no workaround.
Question 2 · Can I get the source code, and can I change it myself?
Why this one second: it decides whether this is an asset or a delivery.
Ask three specific things rather than one vague "can we get the source":
| Ask | A good answer | A warning sign |
|---|---|---|
| Can we get the source | Yes, commented or at least readable | "The code is commercially confidential; deployable but not viewable" |
| Can we change it | Yes, with secondary-development docs | "Custom features require submitting a request to our developers" |
| What does one change cost | Clear rules (by effort / maintenance fee / free scope) | "Depends on the situation" |
⚠️ One clarification while you are here: having the code does not mean free commercial use. These are legally separate things — many providers hand over source while requiring a separate license for commercial use, which is normal commercial practice, not a trick. But if a provider is vague on this point, you are entitled to press for clarity. Usage scope should be stated plainly at code delivery.
Question 3 · When they give you a number, can they say on the spot how it was measured?
Why this one third: because inventing a number costs nothing.
A number you can trust carries these: what tool measured it, in what environment, and which specific quantity. Take "model file size reduced by 68%" — can you get an answer to "which model," "how was it measured," "did the geometry change?"
A test that settles it fast: ask "if I pull this out and run it myself, can I reproduce it?" Things actually done usually produce "yes, we have scripts — run it yourself and compare." Things not done start circling.
Also watch for percentages delivered without a method. "Performance improved 300%" and "draw calls from 3,064 to 837" are two different kinds of statement: you cannot verify the first, and you can hold the second against your own scene. Providers who can say "from X to Y" are usually the ones who actually did the work.
Question 4 · For AI narration, which side actually holds the capability?
"Can the AI do the narration?" is close to a mandatory question in showroom scenarios — and it is where the water is deepest, because plenty of providers cannot say where the AI's boundary is, and the boundary is precisely what decides whether the feature is usable.
Ask it this way: "In your AI narration, does the AI itself know our product parameters?"
If the answer is "our AI has already learned all our material," treat that sentence as a warning. It describes a capability that does not exist. The real situation usually looks like this:
| Capability | Whose it is | Notes |
|---|---|---|
| Appearing in the scene as a humanoid character, walking, speaking | Provided by the system | The character has coordinates, is visible to real visitors, can lead |
| Knowing your product parameters and business material | Yours to supply | Via prompts or documents you provide |
| Seeing the screen, materials, interface text | Cannot | It receives structured spatial data, not video and not screenshots |
| Speech recognition and synthesis | Not provided | The server does no processing; transcription belongs to your own AI client |
| Teleporting, modifying anything in the scene | Cannot | Actions are limited to walking, turning, following, jumping, speaking, interacting |
| Autonomous consciousness | Not promised | It is executing the logic you connected |
This table is the section worth keeping. If a provider's quote includes "AI narration," confirm which rows you are actually buying — usually only the first row comes from the system, and the rest is on your side to feed.
AI narration suits: someone is watching, and the narration never gets tired. It does not suit fully unattended automatic Q&A — that needs separate content and rule work, and many quotes do not account for it.
Question 5 · After launch, who do I call, and how fast do they respond?
Why this one last: because it decides whether the first four were real at all.
You only genuinely need this answer three months after launch, and by then it is hard to change. So ask it in advance, and ask it specifically:
- Who do I contact when something breaks — a group chat, or a person
- How is response time agreed
- What maintenance covers — server, dependency upgrades, model format changes, browser version updates: whose job is this
- If I stop working with them, can the system still run
That last one is the sentence to ask first. It connects back to question 2: if the provider does not support independent operation, you are permanently dependent on them. That is not a matter of how deep the partnership is — it is a single point of failure.
2. After you have the answers, what can you compare?
Once the five questions are answered, the comparable dimensions surface on their own:
| Dimension | What to look at |
|---|---|
| Deployment location | Your server or theirs — largely non-negotiable |
| Asset ownership | Model source files, data structures, export capability handed over at delivery |
| Modifiability | Whether secondary-development docs exist and what one change costs |
| Verifiability of numbers | Whether there is a reproducible measurement method |
| Capability boundaries | Especially the AI part; the less clearly a proposal states them, the larger the risk |
| Long-term independence | Whether the system survives if the vendor goes away |
| Creativity and expression | Visual design, walkthrough flow, content organization — outsourcing's real strength |
In priority: the first six are filters, the last one is a bonus. A proposal with excellent visuals but which locks you in and cannot state its AI boundaries may carry a higher long-term cost than a plain one you fully control.
3. What actually counts as long-term cost here
Since quote sheets usually omit these, here is the accounting:
The cost of switching providers. Can you move what you have? Are models in a common format (GLB/GLTF) or a proprietary one? Is there a data export? Who holds access permissions? — these decide whether changing hands later means "export a package" or "start over."
The cost of every change. A quote covers "making it." The third time you ask for a revision is when you discover there is only one pricing tier and the cycle is measured in weeks; that bill accumulates.
The cost of nobody maintaining it a year later. If nothing owns a system after launch, it decays: dependency versions move, browser policies move, model formats move. None of that requires expertise — it requires the fact that "someone is responsible."
These three together usually exceed the gap between quotes. So whether a proposal is worth it is not "how much is this" — it is "will this still be under my control in three years."
4. When you do not need a provider at all
One case deserves separate mention: some requirements do not need 3D, and therefore do not need a provider.
If you only need to show five product images, one simple animation, or a looping video — images and video are the better tool there, a full order of magnitude cheaper, and with zero learning cost for visitors. Adding complexity for the sake of the technology choice is a common form of waste in this line of work.
A few other cases worth trying yourself first:
- Internal display, headcount fixed around a dozen — existing tools will do
- A one-off event, unmaintained afterwards — not worth building a capability
- You just want to see whether it works — build the smallest validation version, run it, and see whether anyone actually opens it
The test is simple: will someone still be maintaining this in three years? If nobody will, building in-house maintenance capability is pure waste.
5. Our answers to these five questions
In the order of the five questions, so you can compare:
| Question | Where this base layer stands |
|---|---|
| 1 Deployment location | The whole system runs on a server you control. Operations, bandwidth and launch timing are yours to decide. Dependencies are CDN-free, so intranet/offline deployment works |
| 2 Source and changes | Source-available: obtainable, readable, modifiable. License terms in LICENSE / EULA: free for local personal use; online / commercial / federated use requires a subscription license — open code and commercial licensing are two different things, and it is stated plainly here |
| 3 Verifiable numbers | 54 accept_*.js scripts ship with the repo; run them yourself and compare. Measured: draw calls 3,064 → 837 (−73%); GLB textures −68% to −92% (desk 25.74MB → 8.22MB, geometry untouched); LOD low-poly 118/118 at ≤100 faces (triangle count −71% to −87%); skeleton/animation compatibility across Mixamo / RPM / VRoid / RootMotion, 67/67; weak-network reconnect 9/9; full-scene recompile on light-count change 8,989ms → 0 spike |
| 4 AI boundaries | See the table in section 1. Our position is "we can provide the first row; the rest is on you to feed," with what we cannot do written first. It cannot see the screen, does not host a knowledge base, what it says depends on material you supply, no speech recognition or synthesis, cannot teleport, no promise of autonomous consciousness |
| 5 Long-term independence | Self-hosting is this solution's stance, there is no hosted edition — which is a weakness for us and an advantage for people worried about lock-in. The system does not stop working because a vendor changed its rules |
So who this suits: organizations whose content stays online long-term, changes often, carry data compliance requirements, need to integrate with their own business systems, and have someone who can maintain it.
Who it does not suit: showing a few images, one-off events, anyone wanting hosting with no operations involvement, or targets of console-grade visuals and heavy physics simulation (this is a browser stack, bounded by browser performance budgets).
⚠️ Two things that must be said plainly: we do not provide virtual-scene building, consulting, or implementation services; the paid B2B path is still being validated and there are no citable customer cases. This article carries no customer list and no outcome claims — only mechanisms and measured numbers.
6. If you decide to do it yourself, three more questions
Moving from "find a provider" to "build it myself" is a different decision. Three points that are easiest to skip:
- Is there anyone? Self-hosting is not "done"; it is "someone is now responsible." That person's cost belongs on the same table as the quote.
- When is the first revision? If the answer is "the second month after launch," then locking core logic inside someone else was wrong from the start.
- Who handles the server and the database? Self-hosting makes domain filing, SSL, and PostgreSQL installation and initialization your work. None of these is hard; all of them are work.
FAQ
Q: What matters most when choosing a provider?
A: The answers to the five questions matter more than any single number: who hosts it, whether you can change the source, whether the numbers can be reproduced, whether the AI boundary is stated clearly, and whether it still runs if the vendor leaves. Price ranks after those five.
Q: Why not compare price first?
A: A quote mixes three kinds of cost — underlying performance and pipeline work, visible creative expression, and the "can be changed" capability that rarely appears on a quote. Adding the first two does not tell you about the third. Price is the last criterion, not the first.
Q: A provider says "our data is very secure" — how do I tell whether it is real?
A: Ask one verifiable question: "where are my uploaded models stored, and can your staff see them?" An answer that names the location and lets you verify it is a capability statement; an answer that pivots to encryption levels or certification systems is sales language.
Q: Does getting the source mean free use?
A: No. These are two different things. Source-available means you can read, change and maintain it; whether commercial use needs a license is what the license terms specify. LICENSE / EULA is where this is written most clearly.
Q: What does "AI narration" normally include in a quote?
A: Usually only "an AI character can appear in the scene." Product parameters and narration content are yours to supply; limits like "cannot see the screen," "no speech recognition or synthesis," and "cannot teleport" usually do not appear in quotes — so ask.
Q: Can I use this checklist to evaluate you?
A: Yes — section 5 is our answer. But to be fair: we do not take building projects, so if your conclusion after these five questions is "I need a provider to do it," we are not a candidate.
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.
Screening web 3D virtual scene providers? Genesis (a.k.a. the Genesis Virtual World CRM) is a web 3D virtual scene base layer that runs on your own server — it is not a building service, and its position is on the "build it yourself" side: deployed where you control, source readable and modifiable, 54 acceptance scripts whose numbers you can reproduce, AI boundaries stated up front, no hosted edition. 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".