Same Showroom, Three Design Options: Let the Client Walk Through Them Instead of You Building Three Sets of Slides
3D design option comparisonmulti-version design comparisonvirtual showroom option comparisonhow to show design options to a client3D model comparison toolonline design presentation3D virtual world base layerbrowser 3Dprivate deployment 3Dsource-available
A common situation in exhibition design: the same space, three versions for the client. Warm-toned business style, cool-toned tech style, open-ceiling style. You produced all three, and you produced them properly — but at handover what usually goes out is three renderings, two videos, and a comparison you have to talk through until your voice runs out.
The problem is not your work. It is that you turned something the client could compare with their eyes into something they have to imagine.
The audience of a rendering sees a picture. The audience of a video sees a curated path. What the client actually has to decide is: walk through all three spaces and judge which circulation feels right, which lighting reads correctly, which proportion does not feel oppressive. None of those judgments can be completed by imagination. They require walking.
This article is about turning "comparing three versions" from a handover document into something interactive, and about the traps involved.
Stated upfront: 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 take showroom building projects or send a team to implement. Licensing: 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. Not repeated below.
1. Why slide decks fail at this specific job
Understand the mechanism and you know what to build.
Above is the in-browser 3D editor: model library on the left (GLB/GLTF direct upload, VRM packaged with textures, OBJ with mtl), scene viewport in the middle, object list and properties panel on the right. For option comparison, the two jobs of "placing" and "reconfiguring" happen mostly here.
Above is a live desktop-browser view. Stated plainly: this is an in-development test world with no visual polish. It is here because it represents the real form more honestly than a retouched screenshot — this is what visitors actually see.
| What the client has to judge | Can a slide / rendering carry it |
|---|---|
| Whether the proportion feels oppressive | ❌ A single viewpoint shows no proportion relationship |
| Whether circulation flows or collides | ❌ A still image has no continuity |
| Where two versions actually differ | ❌ Depends on visual memory, which is not reliable |
| How the space looks in afternoon light | ❌ Renderings show flattering, idealized light |
| Whether the client can explore further themselves | ❌ They can only see the angles you chose to show |
The deck is not badly made — the format itself cannot carry the act of walking.
And walking is exactly what the client is doing during selection. They will not read your comparison notes carefully; they will go on feel. And feel needs spatial awareness, and spatial awareness can only come from continuous movement.
2. Three ways to build the comparison
First, what each one suits — picking wrong is worse than not doing it:
| Option | Differences it suits | Upside | Cost |
|---|---|---|---|
| Three spaces side by side | Layout and fixtures | Frictionless; nothing for the client to learn | Three scenes to maintain separately |
| One space, three configurations | Soft fit-out (cases, palette, partitions) | Higher comparison efficiency — the differences are isolated, so the client does not spend attention on the parts that were identical | Requires configuration switching |
| Switching on tap | Overall atmosphere (materials, lighting, color temperature) | One tap and the whole tone of the space changes | If lighting and post-processing change too, each switch involves a load |
Which one to pick turns on a single question: at which layer do the three options differ? If they differ within one layer (all fit-out), take the second. Only when the differences cross layers do you need separate spaces.
Option 1 · Three spaces side by side (the least-effort structure)
One virtual world, three entrances, each leading to version A, B, or C.
- Upside: simplest structure; nothing for the client to learn
- Best for: differences that are mainly layout and fixtures
- Watch out: put the three spaces adjacent within one coordinate system — that gives the lowest comprehension cost
Option 2 · One space, three configurations (differences in soft fit-out)
If all three options share the same architectural shell and differ inside (different display cases, color scheme, partitions), do not build three worlds. Build one world with three configurations.
The client switches inside the same space and sees "the same shell, three arrangements." This has the highest comparison efficiency — because the differences are isolated, and the client does not waste attention on the parts that were identical to begin with.
Option 3 · One space, switching on tap (differences in overall atmosphere)
If materials, lighting, and color temperature all differ, the switch changes the rendering configuration along with the models. One click and the whole tone of the space changes.
⚠️ There is a technical dividing line here: if switching only repositions models, it is fast; if lighting environment and post-processing change too, each switch involves a load. That load must be covered — it must never be exposed, because a client who clicks and sees nothing happen concludes the page is frozen.
3. Traps you will actually hit
Trap 1 · Using the same lighting for all three versions defeats the comparison
In the rendering era the habit is soft flattering light on everything, because it looks good. In a comparison scenario that destroys the judgment — the thing clients often want to compare is atmosphere, and atmosphere is carried by light.
Real sun orientation and real color-temperature differences are exactly what renderings tend to beautify away. When building an interactive comparison, make the light real instead.
Trap 2 · Past a few versions, the entryway becomes a disaster
Two versions: two entrances. Three versions: still fine. At five or six, the entryway itself becomes a problem.
At that point the answer is not more entrances — it is giving the client a path: walk them through in the order you designed, rather than letting them pick. Because at that count, the client's choice difficulty has already exceeded their ability to judge.
Trap 3 · Dropping the raw models in makes it stutter, which destroys the comparison
This one is fatal. If the client opens it and it stutters, drops frames, or white-screens, their conclusion is not "I want option B" — it is "this company is unreliable."
So comparison scenarios demand far more performance than ordinary browsing. The reason is simple: during comparison all the client's attention is on the picture, so any stutter gets read as a quality problem.
Concretely:
- Uploaded models must go through optimization. Raw exports from modeling software carry editing-time data (hidden layers, editor objects, unused materials) which is pure waste in a browser
- Distant models need simplified versions. Clients back up to survey the overall layout — a distance that rendering framing simply never covers
- Loading needs progress and feedback. Slower is fine as long as they know it is loading; silent freezing is not
Trap 4 · The client cannot see the detail, then asks "can we zoom in?"
Comparison is about the whole, but late-stage decisions return to detail. If your comparison only works at a distance, one question about detail sends you back to making another rendering — and you are where you started.
So comparison scenarios need to support walking close, rotating close, and inspecting materials up close. Build that in the first time, not after the client asks.
Trap 5 · The client will always ask "what if we combine the two?"
This is guaranteed, and it is usually the last opportunity for a change request.
Supporting "same fixture in a different color" or "knock out this wall for a glass partition" is worth more than producing three more static options. If your structure supports local substitution, this is easy. If it does not, you rebuild.
4. How far is far enough
Ordered by return on effort, do the first two:
| # | What "good enough" means | Is this the pass mark |
|---|---|---|
| 1 | The three options can each be walked in a browser | This is the pass mark; not doing it means not doing it at all |
| 2 | Differences between the three are identifiable at a glance | Lighting or tone differs clearly, not three near-identical images |
| 3 | Close up, the detail still holds | Materials and textures survive close inspection |
| 4 | One space, switchable configurations | An upgrade from three separate spaces to three configurations |
| 5 | Partial combinations | To answer "combine two options" |
⚠️ One judgement worth making: if the three options differ very little (only color scheme and a few display cases), an interactive version may not be worth it. A set of side-by-side renderings plus one comparison table might be the better use of resources. The value of interactive comparison rises with the size of the difference.
5. The real return comes afterward
The above is about delivery. What is actually valuable is this part:
The client's walkthrough keeps generating new questions. Questions that previously required another rendering to answer.
Now he can just ask: "does this column block the equipment?", "can this corner be curved?", "would a display case here make it cramped". You adjust in the editor, he refreshes, and he sees it.
That is the biggest difference between interactive delivery and rendering delivery — not prettier pictures, but fewer round trips of communication. And in the scheme-selection stage, those round trips are usually the most time-consuming part of the project for both sides.
6. Limits specific to this direction
- It addresses "option selection", not "long-term use after completion." Once the design is settled, these things usually stop being opened. Do not expect it to become a permanent site section unless your business has a genuine need for "continuously viewable new options."
- It does not replace drawings and technical specifications. Spatial sense does not substitute for construction drawings, and good-looking material does not mean the process can deliver it. Draw this line explicitly with the client to avoid expectation mismatch at handover.
- It is not an acceptance tool. The completed space will still differ from the visualization (construction tolerance, material color shift). An interactive option is a decision tool, not an acceptance basis — say this upfront.
FAQ
Q: Is interactive comparison worth it for just two options?
A: Marginal. Renderings side by side usually suffice. It pays off at three or more options, or when the three differ substantially.
Q: What if the client never opens the link?
A: That happens a lot. So the interactive version cannot replace the verbal walkthrough — it comes after you have talked it through, as a way for the client to confirm once more. Its job is to reduce repeated confirmation, not to replace conversation.
Q: Do I need both a desktop and a mobile version?
A: Share of viewing options on a phone is not small — clients check again in the meeting room, on the road. So mobile has to work, and that belongs in the first version rather than being patched in later.
Q: How much model optimization effort does this take?
A: This is the deciding factor, not an optional extra. Raw models put straight into a browser will have the comparison experience ruined by stutter. Compression, simplification, and texture work are mandatory.
Q: What if the client asks "can we change the color?"
A: If your structure supports substitution, it is easy. If not, plan for it now — because this request almost always shows up late.
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.
Holding several design options that need comparing? Genesis (a.k.a. the Genesis Virtual World CRM) is a web 3D virtual scene base layer that runs on your own server — uploaded models get three-tier LOD generated for them, GLB textures compress by sixty to ninety percent with geometry untouched, and distant models do not turn into blue boxes. The editor runs in the browser (GLB/GLTF/VRM/OBJ imports, object list and properties panel). 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".