Past the third showroom, the hard question stops being how to build one and becomes where the last one went. This article separates "more" into version sprawl (a problem of provenance) and event sprawl (a problem of entry points), then compares one-site-per-event with one base layer holding several spaces across six dimensions: adding an event, accounts, model reuse, finding old content, who maintains it, and who you call when it breaks. Path B has a cost of its own — it does not remove deployment and maintenance, it makes them happen once instead of once per event. A three-layer content split follows — model, space, access, each with an owner — noting that the access layer is the one nobody owns and the one that causes trouble half a year later, backed by two rules: name models on the way in, and write one note per event. It closes with what an update actually touches, the five agreements to settle before starting, four cases where this approach is the wrong fit, and plain limits: the base layer does not store your content, "open it anytime" assumes a paid-up server and an unexpired domain, and the figures come from our own test environment rather than a client's long-term operation.
managing multiple 3D showroomsvirtual showroom content archiveshowroom version managementweb 3D showroom deployment3D model library reusemaintaining a virtual showroomvirtual showroom URL structureself-hosted 3D showroom
Previous pieces covered the technical side; this one moves to the visitor's viewpoint — the first thirty seconds after opening the link. The screen at 0–1s is your one chance to introduce yourself, and most 3D showrooms hand over blank space, a progress bar, or a blurry image. Three ways to get it wrong: opening blank (visitors read it as broken and do not return; a placeholder scene is not a temporary substitute — it is itself the first screen's content); opening blurry (an image used as a cover makes a false promise, and the worst option is pretending to be done); progress stalling (30% frozen for ten seconds alarms more than 30%→50%→70%). Two metrics must be separated: "time until something is visible" decides how long a visitor is willing to wait; "time until fully loaded" decides how long they actually wait. Mobile gets its own treatment (touch has no hover; weak network needs separate testing; using desktop load time to infer phone load time is a common form of optimism here). Stated honestly at the end: this piece describes mechanisms, not measured numbers.
3D showroom slow to loadhow to fix slow web 3D loadingfirst screen of a 3D scenevirtual showroom loading stalls3D model slow on phone3D scene loading progressbrowser 3D performance3D virtual world base layerwebgl optimizationsource-available
Between the designer's model and a visitor opening it on their phone lie six stages nobody states explicitly, yet each one loses people: design and modeling, export, optimization, staging, launch, being visited. This article covers handoffs rather than implementation and the failure mode of each: wrong format chosen at export costs a full rework round (models built for image production are exported unoptimized, carrying hidden layers and unmerged objects — harmless for rendering, a disaster on the web; models with skeletal animation need compatibility verified separately or you find at launch that nothing moves); the ownership question at the optimization stage (who does it, whose cost — if nobody does, the browser does it for you at the price of every visitor waiting; and "doesn't affect the look" has a precondition, since over-compressing turns mushy up close, so the accurate phrasing is graded by purpose); staging losing intent (orientation, initial camera angle, exhibit position — none of these are technical problems, all are "did anyone ask the designer"); launch deciding whether this outlives the project (whose server, who maintains it, how partial updates work, and most importantly whether the data can be taken out as a whole, which determines the cost of switching — a collaboration with no exit mechanism is asymmetric risk); and the first screen as the only acceptance criterion (most visitors are on phones; a progress bar moving steadily to the end is more trustworthy than a jumping percentage, since a client watching 30% stall for ten seconds is more alarmed than one watching 30%→70%). Seven FAQs close the piece, and it states plainly which stages this base layer covers — optimization and loading — while format choice, staging intent, and operational ownership have no tool that does them for you.
how to publish a 3D model on a websiteuploading models to the web3D showroom building processGLB model optimization3D model compressionhow to fix slow 3D scene loadinghow to display 3D models on a web page3D virtual world base layerbrowser 3Dsource-available
Three options for the same showroom, handed over as three renderings and two videos — the problem is not the quality of the work but turning something the client could compare with their eyes into something they must imagine. This article covers making the comparison interactive: three spaces side by side (differences in layout), one space with three configurations (differences in fit-out — highest efficiency, because the differences are isolated), one-click switch (differences in atmosphere, where the switch load must be covered and never exposed). Plus five traps you actually hit: identical soft lighting across all three versions destroys the comparison (rendering habits beautify; make the light real here); past a few versions the entryway itself becomes the problem (give the client a path rather than a choice); unoptimized models lead the client to conclude "this company is unreliable" (comparison scenarios demand far more performance than ordinary browsing because all attention is on the picture); the client cannot see detail and asks to zoom (build close-range capability the first time); and the client inevitably asks "what if we combine two options." Also five levels of sufficiency ordered by return on effort (with the judgement that near-identical options do not justify the investment), where the real return comes afterward (fewer communication round trips in the option-selection stage), and three limits specific to this direction (selection not long-term use; not a substitute for drawings and craft feasibility; not an acceptance tool).
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
Choosing a web 3D virtual scene provider — five verifiable questions matter more than price. ① Whose server does it run on, and who can see my data (a verifiable answer names server ownership and directory permissions; "enterprise-grade security system" is sales language). ② Can I get the source, change it myself, and what does one change cost (having code is not free commercial use; the two must be stated separately in the license). ③ When they give a number, can they say how it was measured ("from 3,064 to 837" is verifiable; "300% improvement" is not). ④ For AI narration, which side holds the capability — with a six-row capability table: appearing/walking/speaking as a character comes from the system; knowing product parameters is yours to supply; it cannot see the screen, does no speech recognition or synthesis, cannot teleport, and autonomous consciousness is not promised. ⑤ After launch, who do I call, how fast, and can the system still run if the vendor leaves (ask that one first). Also covers three long-term costs (switching providers, every revision, nobody maintaining it a year later), four situations that need no provider at all, and this base layer's position on each of the five questions: deployed on a server you control; source-available and modifiable; 54 re-runnable acceptance scripts; AI boundaries stated; no hosted edition. Honestly labeled: no building service, no customer cases. Licensing: source-available, not an open-source license — run locally free of charge; online, commercial, and federated use require a subscription license.
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
Planning a web 3D virtual scene? The first question is not which company is good but whether to build it at all. This article gives seven decision points: is the content one-off or long-lived, how often will it change, can data leave your building, who visits and how many, does it need to integrate with business systems, is there anyone who can maintain it, will it still be in use in three years — plus the other half written out in full: when outsourcing is genuinely better (a single expo, content different every time, buying only this month's delivery, no web background on the team). After deciding to build, the four layers a base layer must cover (rendering kernel / asset pipeline / performance and multi-client / real-time communication) with measured values (draw calls 3,064→837, GLB textures −68% to −92%, LOD low-poly 118/118 at ≤100 faces, cross-source skeleton compatibility 67/67, weak-network reconnect 9/9, 54 re-runnable acceptance scripts), with editor and live screenshots; the AI-guided-tour section states what it cannot do (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). Honestly labeled: no building service, no customer cases, mobile not fully measured, unsuited to showing a few images or heavy physics simulation. Licensing: source-available, not an open-source license — run locally free of charge; online, commercial, and federated use require a subscription license.
which web 3D virtual scene company is betterweb 3D virtual scene providerwhich web 3D virtual scene to choosevirtual showroom system selectionoutsource or self-build 3D scenewhich web 3D virtual scene can be self-hostedprivate deployment 3D3D virtual world base layersource-available
“I want my own metaverse,” translated into engineering, is one question: what does the base layer give you and what do you write? Using the Genesis browser-based 3D virtual world base layer, this article covers where to start on layer 5 (the business layer): a five-layer table (rendering kernel r185/WebGL2; asset pipeline LOD/GLB/3DGS; multi-client and communication; open interfaces MCP/federation/admin — the lower four ship with the source; the business layer is yours); the work split of “editor places, code behaves” (GLB/GLTF/VRM/OBJ imports, object list and properties panel, the screenshot scene holding 373 objects); four directions that can land with their capability support (showrooms, training, community/brand spaces, digital memorial spaces), honestly labeled that the paid B2B path is still being validated with no customer cases; a live mobile screenshot of the same world (frame rate and power draw not fully measured); and a five-step executable order (deploy and run acceptance → build a minimal scene in the editor → add one business rule alongside the existing implementation → connect AI per the docs → talk licensing when going online). Licensing: source-available, not an open-source license — run locally free of charge; online, commercial, and federated use require a subscription license.
metaverse development3D virtual world base layerself-hosted metaverseThree.js source code3D editor buildingvirtual showroom development3D training systemmultiplayer online worldfederation interconnectionsource-available
From clone to a 3D virtual world on your own server, enterable from a browser — what does the path look like? This article walks the full deployment road using things that actually exist in the repo: environment self-check (check-env.js and a Windows check script), database creation and import (database/ with import docs), centralized environment-variable configuration (.env.example commented line by line), startup (a Windows launcher or plain Node, plus Dockerfile and docker-compose), and 54 re-runnable acceptance scripts for post-deployment verification. Stated honestly, the work no document can do: installing the environment, domain and HTTPS, secret management (with a principle worth stealing — after a secret leaks, “deleting” never replaces “rotating”), and backup strategy. Two live screenshots: the desktop world (spawn point, buildings, billboards) and mobile (virtual joystick, voice, camera controls). The three classic snags: PostgreSQL auth configuration, the WebSocket upgrade in the reverse proxy, and restarting after config changes. Boundaries stated: no deployment-time numbers; the container route unverified in long-term production; mobile frame rate and power draw not fully measured.
3D virtual world deploymentself-hosted 3D worldNode.js 3D serverPostgreSQL for 3D worldsWebSocket reverse proxyDocker 3D deploymentintranet 3D deploymentThree.js self-hostingenvironment variablessecret management
Interested in a 3D virtual world base layer but unsure what cloning actually gets you? This article lays out the full inventory of the Genesis source code with live screenshots: an actual listing of the repo root (world front end and server, deployment docs, database scripts, environment checks, Dockerfile and docker-compose, AI access examples, 54 re-runnable acceptance scripts, LICENSE/EULA/patent disclosure), plus the four-piece walkthrough — the browser 3D editor (GLB/GLTF, VRM, OBJ imports; object list and properties panel), an unretouched desktop world screenshot (honestly labeled an in-development test world with unfinished blocks), the admin module list, and the three concrete pieces of AI access (discovery file, token endpoint, zero-dependency example client plus a standalone MCP Server). Licensing stated plainly: source-available is not an open-source license — run locally free of charge, while online, commercial, and federated use require a subscription license; environment setup is on you; and the in-source/not-in-source boundary table makes the key point — you get the factory for building worlds, not a finished world.
3D virtual world source codeself-hosted 3D worldThree.js base layer3D world editorGLB importVRMmetaverse developmentAI agent accesssource-available3D world admin console
"How far along is your base layer?" needs two rulers. Measuring "is it usable today" — yes: a fully usable self-hosted 3D virtual world foundation whose rendering kernel (Three.js r128→r185/WebGL2, CDN-free), asset pipeline (118 LOD variants, GLB textures −68%~−92%, 3DGS 26/26), performance governance (draw calls 3064→837, the light pool eliminating an 8989 ms freeze), multi-client adaptation, real-time communication (weak-network self-healing 9/9), AI access (≈1 KB/s per agent, 100 agents at 0.079 CPU cores), and cross-world federation (same-name auto-rename 4/4) are all running now, each backed by re-runnable acceptance scripts. Measuring "how far the direction can go" — against the form browser-based 3D virtual worlds can eventually take, the base layer covers roughly 5%–8%; the two statements must be read together: the base layer is fully usable, and more than ninety percent of headroom remains — the number expresses opportunity, not debt. Above it sit four planned items (AI-assembled worlds, an agent store, agent interoperability via A2A, cross-world federated AI), each mapped to "which base-layer capability is already proven and which segment is missing," with the explicit declaration that none are implemented and none should be evaluated as shipped features. Layer-5 business logic — showrooms, training, community worlds — has a complete landing surface today.
3D virtual world base layerself-hosted 3D worldThree.js foundationbrowser-based 3D3D world developmentAI agent accesscross-world federationprivate 3D deploymentvirtual world roadmapMCP Server