In peak season, a showroom's staffing math never adds up: one presenter can only take so many customers a day, and visitors do not queue up on schedule. Hiring raises costs; not hiring means half the visitors wander aimlessly and leave. Online showrooms reshape the problem rather than solve it — web chat is one-on-one, and ten simultaneous questions still jam the window.

This article is about something structurally different in a 3D world: the AI humanoid character is "publicly present" — it stands in a shared space where every visitor sees it and hears it at the same time. Web chat cannot do this; not for lack of a feature, but because the medium differs. Below: which implemented capabilities this rests on, what landing looks like, and where the limits are. Implemented versus planned are kept separate.

I. Why repetitive explaining eats staffing

Break a presenter's day apart and the bulk is not high-value deep conversation but high-frequency repetition:

• The same product introduction, delivered ten or twenty times a day;
• The same "opening hours / where to go / can I touch it" questions, answered over and over;
• Two tour groups colliding, and hands are suddenly short.

Deep conversations — pricing, proposals, after-sales disputes — need a human. But the repetitive work above should never have occupied human hours. The catch: until now there was no tool that could be present. Text chat can batch-reply, but customers don't feel a person in the hall; a recorded audio guide needs no staffing, but it doesn't know you and won't walk you through.

II. Web chat vs. a 3D-world AI: present, and public

"Public presence" is the crux. What a human tour leader really provides is a group sharing one live explanation — the sentence you hear, the person next to you hears too. An AI humanoid reproduces exactly that structure: every sentence it says travels the real-person chat pipeline, delivered within 30 meters, so nearby visitors each see the bubble overhead. It does not open a separate session per person.

III. The mechanics of leading a group (all implemented)

• Walking and following: walk to a coordinate, or continuously follow a visitor (with a stop distance and max duration, designed for guiding); movement is speed-limited like real people (1–20 m/s, default 9) — no teleporting;
• Speaking: travels the real-person chat pipeline, delivered within 30 meters as bubbles — one sentence, everyone nearby sees it at once;
• Spatial radar: it knows who is nearby, how far, facing which way (Key holders: radar radius up to 200 meters; guests: 30 meters);
• Event stream: new visitors appearing and moving arrive via a configurable real-time event stream (off / per-second aggregate / item-by-item), which the character can use to decide whether to speak;
• Object descriptions: every world object can carry an "AI description" written in the editor (up to 500 characters), delivered with the spatial radar — it knows what each point of interest is.

The combined meaning: the "queue to ask" step disappears. Visitors don't raise a hand and wait; they follow along. The explanation is shared by everyone nearby, and human staff step out of repetitive explaining — re-entering only when a customer reaches proposals and pricing.

IV. What landing looks like

Before integration: lay out the showroom route and write clear "AI descriptions" for each point of interest; set a few greeting rules (what to say when someone nears the entrance, what to say after someone lingers at an exhibit).

During integration: three steps — the discovery file, exchanging the Key for a 15-minute token, connecting to the dedicated channel. Your chosen LLM then drives the character: greeting at the entrance, walking the route, answering beside exhibits. Twenty visitors in the same space all see the same AI doing the same thing.

After integration: review chat logs (persisted in real time, archived daily) to see what visitors ask most, then fill in point descriptions and the knowledge base. The human seller's role shifts from explaining to closing — the AI brings people to that point.

V. Honest limits: what it cannot do

The third deserves emphasis: one-to-many saves staffing and gives up one-on-one privacy. Where private quotes and proposals are needed, a human must take over — the AI's job is to bring people to that point.

VI. What to prepare

• Route points and descriptions (business staff can write these);
• A code-capable AI client (the repo ships a zero-dependency Node example that runs the full pipeline);
• Greeting and explanation scripts.

VII. What it does not suit

• Sales scenarios built on private one-on-one talks (finance, medical consulting) — public delivery conflicts with them;
• Small venues one human already covers — adding the system just adds maintenance;
• Anyone wanting "fully unattended automated closing" — it handles reception and guiding; closing still needs a person.

VIII. FAQ

Q: A hundred visitors at once — can it keep up?

A: For "action," yes — it is seen and heard by everyone simultaneously, and that cost does not grow with headcount. For "dialogue" there is a ceiling: responses are driven by your client, so concurrency depends on the model service you connect. On the platform side, measured traffic is about 1 KB/s per agent; one hundred agents in one world total about 0.8 Mbps, with server load around 1% of a single core.

Q: Will visitors mistake it for a human?

A: No. AI identity is always explicit — an entry notice and an overhead prefix. This is a product red line; there is no "pretend to be human" option.

Q: Compared with a recorded audio guide, is the extra cost worth it?

A: Depends on what you need. For fixed content playback, an audio guide is enough. If you want greeting on approach, answers to questions, and route guiding, you need a character that senses space and acts — which is exactly this article's form. The two serve different needs; there is no need to pick only one.

IX. Source code and repositories

All three mirrors hold identical content; the first two are faster for visitors in mainland China. The repos include deployment guides and a demo entry.

• Gitee (faster in mainland China): https://gitee.com/miduoxinxijeji/miduo.git
• GitCode (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.

Want one AI presenter serving every visitor at once? Genesis (the Genesis Virtual World CRM System) is a Three.js 3D virtual-world base deployed on your own server — AI as a publicly present humanoid character: guiding, explaining, greeting. The capabilities are implemented. The official site (search "Genesis Virtual World CRM") has a demo world you can walk through.

About the name: Genesis in this article refers to the Genesis Virtual World CRM System — the same self-hosted 3D virtual-world product. If searching "Genesis" does not find us, search "Genesis Virtual World CRM" directly.