展厅模型从设计师手里到访客能打开，中间要过哪几道手

一个展厅项目从设计到访客手机上能点开，中间隔着一段没人明说、但每一段都会掉人的路。这篇把这段路拆开讲清楚——不谈技术实现，只谈交接：模型从谁手里出来、以什么格式出来、谁为它的体积负责、哪一步会卡住整条链。

写在前面：我们提供的是一套部署在你自己服务器上的网页3D 基座（创世Genesis／创世虚拟世界CRM系统），不接展厅代建、不派团队实施。这篇是给这条链上各个环节的人看的坐标图，不是自荐。

许可口径：源码开放（source-available），本地跑不花钱；要联网、要商用、要联邦，需要订阅授权。 准确条款在仓库 LICENSE / EULA 里。

一、把链路拆成六段

一段一段看，才知道卡在哪。

段	谁经手	交付物	这一段最容易出的问题
1 设计建模	设计师	建模源文件	源文件里的东西浏览器不需要，但被原样带进去了
2 导出	设计师	模型文件	格式选错，返工
3 优化	中间经手	可上网的模型	谁做、算谁的成本，很少说清
4 布场	实施／设计师	场景配置	动线和视角是设计意图，不能丢
5 上线	技术方	一个网址	谁的服务器、谁维护、怎么更新
6 被访问	访客	—	手机打开第一屏、加载多久

六段里，第 2 段和第 3 段是断裂得最厉害的地方。原因很简单：设计师的交付标准是"模型准确"，而浏览器的标准是"模型在网络里能跑"。这两个标准不重叠。

二、第 2 段：格式选错，返工一整轮

这是最贵的一个坑，因为它发现得太晚。

格式	特点	用在什么时候
GLB / GLTF	浏览器原生友好，体积小	默认选它，尤其是要上网页的
FBX	主流建模软件都导出，但浏览器侧要转	只在中间环节用，别直接上
OBJ	简单、久远、不带动画与材质信息	一般不用，除非极特殊需求
VRM	带骨骼与表情，面向角色	有角色模型时用
3D 资产的其他格式	用途各异	确认浏览器侧能不能处理

要问清楚的一句话：这个模型是要上网页给人看的，还是只用来出图的？

只用来出图的模型，导出时往往不优化——高精度贴图、几十万个面数、可能还带着未合并的物体。这些对出图无害，对网页是灾难。

⚠️ 另一个容易被忽略的：骨骼动画的兼容性。 同一个角色的模型和动画，从不同软件导出来，能不能配在一起跑，不是一个默认成立的事情。如果模型里有动画（比如展厅里有一个虚拟讲解员在动），这件事要单独验一次，别等到上线才发现动作不动。

三、第 3 段：优化这一段，谁做、算谁的成本

模型优化具体指什么：

• 减面数：远处的模型不需要那么多细节。三档不同精度的版本是最省事的做法
• 压贴图：贴图往往是体积的大头。压贴图不动几何，所以不会损失模型形状
• 剥无用数据：隐藏层、编辑器对象、未使用的材质
• 合并同材质：减少绘制调用

"不影响外观"这件事有前提——压贴图确实不改几何，但过度压缩会让近距离看时发糊。所以正确的说法是"按用途分级处理"，不是"压了看不出来"。

这一段的核心是归属问题：

• 如果优化由技术方做 → 这是一笔要在报价里说清的工作量
• 如果甩给设计师做 → 设计师会多出没被计入报价的时间，而且他未必知道该怎么做
• 如果谁都不做 → 浏览器会替你做，代价是所有人一起卡

第三种是常见的默认状态，也是最贵的。因为成本没有消失，只是转移到了每一个访客的等待里。

四、第 4 段：布场丢意图，比技术问题更可惜

这一段是设计师的心血所在：走哪条动线、进门第一眼看到什么、哪台设备放在视线高度。

上图是浏览器端 3D 编辑器。布场这件事在这个界面里完成——摆模型、调属性、定相机初始视角。也正因为它可编辑，"改一版"才变成了点几下，而不是重做一遍。

上图是手机浏览器实机画面：虚拟摇杆、语音、拍照与跳跃控件。展场的最终读者是拿着手机的人，所以触屏操作这一段必须在布场时就考虑进去，而不是最后补。

这些意图在"把模型放进场景"的时候，最容易被抹掉。

常见的丢失方式：

• 模型默认的朝向不对 → 进门看到的是设备的背面
• 位置按模型原点算，而不是按展品应该被看到的那一面
• 相机初始视角是默认的，而不是设计时确定的那个"进门第一眼"
• 设备被放在够不着也看不清的地方（技术上放得下，体验上没法用）

⚠️ 顺带说一句：这些没有一条是技术问题。 它们都是"有没有问过设计师"的问题。这一段花的时间不在渲染，在沟通。

五、第 5 段：上线，决定这件事能活多久

模型处理完了，怎么放出去。这一段要定的几件事，每一件都影响后面能不能持续：

问题	不定会怎样
部署在谁的服务器	数据和模型在谁手里，说不清就出事
谁维护	三个月后没人管，系统会慢慢坏
怎么更新内容	改一次要动全部文件，等于每次更新都重做一遍
数据能不能拿回来	这一条最要紧，见下

关于"数据能不能拿回来"，要说得很具体，不是问一句"能不能导出"就完了。要问的是：

• 模型文件是不是通用格式（是GLB 还是私有格式）
• 有没有导出机制，能不能整库拿走
• 访问权限在谁手里，换服务商时要重新配一遍还是能直接迁

这一条决定了"换人"这件事的成本。 如果答案是"整套是私有格式、只能我们维护"，那这个项目没有退出机制——不管当下合作多顺。

六、第 6 段：访客打开的第一屏

前面五段都是为这一段服务的。这一段是实际的验收标准。

它有一个很硬的事实：展厅的访客大部分在手机上，而且是在会议室、路上、客户现场打开的。

所以要看的不是"在你的电脑上一秒加载完"，是：

• 手机上第一屏出来的是白屏还是画面
• 加载到多少才开始有东西可看
• 有没有一个"正在加载"的状态，还是干等着
• 弱网下会不会一直卡在某个百分比

⚠️ 关于最后一条：一条走到底的进度条比一个跳来跳去的百分比更可信。 客户看到 30% 停了十秒，比看到 30%→50%→70% 更慌——后者至少说明还在动。

七、最容易被忽略的一件事

整条链上，每一段的交付物都是"文件"。但这个项目的交付物其实是一个还在运行的地址。

文件是可以交接的，运行中的东西需要有人看着。这就是为什么第 5 段"谁维护"这个问题，不能和"上线"分开讨论——它们是同一个决定：这件事是交给系统，还是交给某个人。

如果交给系统：更新要能局部改，不能每次全量重做。

如果交给人：那这个人必须在项目结束之后还在。

常见问题

Q：设计师直接导出模型发过来不行吗？

A：可以，但要先问一句"这个模型是出图用的还是上网用的"。出图用的模型直接上传会让网页端很吃力——它带着编辑期的冗余数据，而且往往没做精度分级。

Q：优化必须做吗？

A：必须。不是为了好看，是为了"客户打开不卡"。方案对比和产品展示这两个场景，客户全程在看画面，卡顿会被直接读成质量问题。

Q：谁做优化最合理？

A：看谁有工具和标准。最省事的判定方式是：谁能跑出一份可复现的检查结果（体积多少、面数多少、有没有分级版本），谁做。

Q：模型只有一两个G，能直接传吗？

A：单机能打开不代表访客能打开。体积、贴图、加载策略是一组问题，要一起看。而且如果这个展厅要在手机上被访问，体积的问题会被放大。

Q：怎么保证下次更新不用全部重来？

A：这是第5段要定的事——更新方式设计成局部替换，就只需改动的部分；设计成整包替换，就每次都要重来。这一条要在第一次上线前就问清楚。

Q：这套基座在哪一段能帮忙？

A：第 3 段（上传即生成三档 LOD、GLB 贴图压缩）和第 6 段（加载策略、占位场、进度反馈）是我们覆盖的部分。第 2 段的格式选择、第 4 段的布场意图、第 5 段的运维归属，都要项目上的人自己定——这三段没有工具能替你做。

源码与仓库

三个地址内容一致，国内访问用前两个更快。仓库里有部署说明和一批验收脚本，可以自己跑一遍看实测值。

• Gitee（国内访问更快）：https://gitee.com/miduoxinxijeji/miduo.git
• GitCode（国内镜像）：https://gitcode.com/qq_35054471/virtual-world
• GitHub：https://github.com/miduo100/3d-virtual-world

关于创世Genesis

创世Genesis是一套基于Three.js+WebGL构建的自部署3D虚拟世界系统，帮助个人与企业搭建属于自己的3D空间。浏览器直接访问，PC和手机双端兼容，支持多人在线、联邦传送、商铺系统，并支持Agent接入——AI能以具身角色进入你部署的世界。数据运行在你自己的服务器上，不经过第三方平台——让每个世界都真正属于它的主人。

手上正有一段"从模型到访客"的活要往前推？ 创世Genesis（创世虚拟世界CRM系统）是一套部署在你自己服务器上的网页3D 虚拟场景基座，不提供代建与实施服务——它覆盖的是优化和加载这两段：上传即生成三档 LOD、GLB 贴图可压缩六到九成（几何不动）、远处模型不会变成蓝方块、加载有进度和占位反馈。源码开放、本地跑不花钱，联网、商用、联邦需要订阅授权。官网（搜「创世虚拟世界CRM」即可找到）有一个可以走一圈的演示世界。

关于名字：本文说的创世Genesis，即创世虚拟世界CRM系统，两者是同一个自部署 3D 虚拟世界产品。若你通过「创世Genesis」没搜到我们，直接搜「创世虚拟世界CRM」即可。