The previous article covered the mechanism: an AI explaining things proactively in a 3D scene does not rely on a camera, but on a spatial radar + an object list + one description per object.

This article does only one thing: turns that into a sheet you can fill in by following along.

Because in practice you discover that what decides whether the whole thing is any good is not how clever the AI is, but how well the descriptions you write are written. With the same model, if the description is empty it will only say "there is a machine here"; if the description is well written, it can deliver a passage a customer is willing to listen to all the way through.

Below is everything the business side has to do, in order.

---

1. First accept one thing: if the descriptions are bad, everything after that is wasted effort

The system reserves a field on every world object called the AI description. You fill it in directly in the editor, with no code. It is the semantic entry point through which the AI knows this world — what the AI receives is the object's position and an internal name; with no description filled in, it only knows "there is a thing there."

The field has two hard constraints:

• the entry limit is 500 characters;
• when the AI receives it through the spatial radar, anything beyond 300 characters is truncated.

So the practical conclusion is blunt: write within 300 characters. Fill in all 500 and the last 200 are wasted.

2. How to write the description: a four-part template

Do not write a parameter table. No customer will stand there while you read out twenty parameters, and the AI should not talk that way either. Write four parts in this order:

Bad example -> good example:

A filled-in example (about 260 characters):

Five-axis vertical machining centre EQ-2200-C, aimed at small and medium batches of precision parts.
Three key points: travels 800×600×500 mm; 24-station automatic tool changer as standard; positioning accuracy ±0.005 mm.
Suits moulds, complex curved parts, and high-precision single-piece or small-batch work; for large batches of simple parts the three-axis machine next door will be more economical.
The EQ-1800 beside it is three-axis with slightly shorter travels, and differs in both price band and lead time — customers often compare the two.

A very short description already settles "am I that kind of customer, and which one should I look at."

A compliance reminder: the AI description is visible to all Agents, including public guest identities. Do not put sensitive commercial information such as costs, floor prices or undisclosed parameters in it.

3. Planning the layout: one route, five positions

Before placing products into the 3D showroom, sketch a route. It does not need to be complicated — five positions are enough:

One easily overlooked detail: do not place the positions too close together. The AI judges "which machine this person is looking at" from distance, facing direction and dwell time — with two machines side by side, that judgement becomes fuzzy. This is exactly why the judgement should stay in the business's hands: you can define the rules for your own showroom.

4. Keep the knowledge base and the descriptions separate — do not mix them into one pot

This is the place people most often confuse. The two have different jobs:

In one sentence: the description handles "recognition", the knowledge base handles "depth". With only descriptions, the AI can explain but not answer follow-ups; with only a knowledge base, the AI does not know which machine the customer is standing in front of, so it cannot be used.

5. The four things to do on the platform side (about 10 minutes)

1. Turn on the master switch — Agent access is off by default; it cannot connect without this;
2. Create an Agent: give it a name, set its appearance (a whole set of model / animations / skeleton that is delivered with its identity), and choose a streaming tier (for a docent, standard or realtime is recommended);
3. Generate the API Key — the plain text is shown only once, save it on the spot; you will not see it a second time;
4. Set the limits: concurrency, movement speed (1–20 m/s; the default of 9 matches a human), and observation range.

6. What the AI-side loop looks like

The business side only needs an environment that can run Node 18+, and the project ships a zero-dependency sample client. The logic is one loop:

Discovery (visit the domain's .well-known endpoint)
   -> exchange the Key for a 15-minute short-lived token
   -> connect to the world
   -> read the spatial radar every 1-2 seconds
       Someone approaching a machine? -> walk over -> give an explanation
       Someone walking?             -> follow   -> stop at the next point worth explaining
       Someone asking a question?   -> answer from the knowledge base -> guide them onward if needed
   -> visitor leaves / 5 minutes idle with no input -> leave automatically

Meanwhile, what the human side sees is: a character with an AI badge approaching and stopping, with a speech bubble popping up above its head. Its walking is animated, not jumping frame by frame.

7. Acceptance: six checks you can run on site

• ☐ A visitor opens the URL and can see the docent, carrying an AI badge
• ☐ The docent proactively approaches the visitor instead of standing still
• ☐ Questions get answered, and the answers come from the business's own knowledge base, not generic chit-chat
• ☐ Movement is continuous, without teleporting or sinking into the ground
• ☐ Zero errors throughout, and it reconnects automatically after a dropped connection
• ☐ After visitors disperse, the docent leaves automatically once idle

8. Eight common pitfalls (ordered by how often they happen)

1. Forgetting to fill in the object description — the most common one. The symptom is the AI walking over and then saying "there is a machine here";
2. Writing the description close to 500 characters — it is truncated to 300 on delivery, so the last 200 are wasted. Aim to finish within 300;
3. Putting sensitive information in the description — it is visible even to public guest identities; never put costs or floor prices there;
4. Placing positions too close together — with two machines side by side, "which one they are looking at" becomes fuzzy;
5. Setting the movement speed very high — it looks twitchy. The default already matches a human; in most scenarios leave it alone;
6. Not connecting a knowledge base — descriptions let it explain, but follow-ups go unanswered, and the customer's trust breaks at exactly that step;
7. Forgetting to turn on the master switch — the backend default is off, the Agent cannot connect, and the symptom is "the client shows no error, it just cannot get in";
8. Not saving the Key — the plain text is shown only once; if you lose it you can only revoke and issue a new one.

9. What this approach is not suited to

• Anyone who wants the AI to read fine detail in images (for example judging whether a machine surface has a scratch) — it receives a structured radar and cannot see the picture;
• Anyone who wants it to replace hands-on training on the real machine — feel and force are things a virtual scene cannot give;
• Anyone who only wants a pure text chat agent — an ordinary chatbot is cheaper and there is no reason to bring 3D in;
• Anyone with nobody who touches code and no plan to hire someone for the deployment — this is a foundation rather than a finished product, and the startup cost will be higher than expected.

Several other boundaries should be stated just as plainly: the platform does no speech recognition or synthesis (to have the AI speak aloud you attach speech synthesis on the AI side; two-way real-time voice is not provided at this time), it does not host a knowledge base, it does no terrain conforming (movement is a plane with boundaries), and the AI cannot teleport or touch assets (it follows the same rules as a human visitor). One more that is easily misunderstood: it is not an employee with a mind of its own, but a programmable character whose words come from the descriptions and prompts you wrote.

10. FAQ

Q: Do we need to hire a 3D developer?

A: Putting models in, finishing the descriptions, and running the sample client require no coding. Only deep interaction (clicking a part to show parameters, a model comparison tool) needs secondary development on the foundation.

Q: How many people can one AI serve at once?

A: It can serve in a queue, or you can run several Agents with divided roles. Automatic avoidance between multiple AIs in the same scene has known issues still in the pipeline, so it is advisable to test with your target number of people first.

Q: Will the AI's walking look odd?

A: Movement speed can be on the same order as a human, and the human-side view is interpolated and smoothed, so it does not jump frame by frame. Only setting the speed very high makes it look unnatural.

Q: Do visitors know it is an AI?

A: Yes, and by design they have to — there is a "(AI) joined" system notice on entry and an AI prefix before its name. That is our red line, and it also removes the compliance risk of impersonating a real person.

Q: Are chat logs stored?

A: Yes. Chats are written to the local database in real time and archived according to the backend configuration (7 days by default). The business needs to tell visitors about this in its terms of service. Voice is not relayed by default, and audio is not stored.

11. Source Code and Repositories

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.

• 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

Plan Comparison: Self-Hosted Deployment vs. Platform Leasing

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 a landing template you can fill in directly? Genesis (the Genesis Virtual World CRM System) is a Three.js 3D virtual world foundation you deploy on your own server: visitors come in with a browser, the AI is present as a human-shaped character, and it speaks first according to the object descriptions you filled in. The official site (search for "Genesis Virtual World CRM" to find us) has a demo world you can walk around.

About the name: Genesis (创世Genesis) in this article is the same self-hosted 3D virtual world product as the Genesis Virtual World CRM System (创世虚拟世界CRM系统). If searching "Genesis" does not find us, search for "Genesis Virtual World CRM" instead.