设备需要开合或旋转演示，模型制作前要约定哪些活动部件

把“做一个动画”拆成可确认的动作

动作至少写清谁在动、相对谁动、从哪里到哪里，以及用户何时触发。门板绕铰链转动、抽屉沿导轨移动、整机旋转展示，所需的模型组织并不相同。只交一段视频也不等于交付可在页面中反复开合的资产。

先列活动部件表：部件编号、初始姿态、轴心或移动方向、结束姿态、跟随它运动的附件、复位要求。角度和距离应由已确认资料或展示方案给出，没有依据时先确认示意动作，不编造真实设备的极限行程。

轴心和父子关系为什么要提前检查

门板如果绕自己的中心旋转，看起来会穿过机柜；把手如果没有跟随门板，会悬在原地。应在简单着色的样件阶段先看动作，再投入外观细节制作。Three.js Object3D官方文档区分对象的局部位置、旋转与父子层级，并说明旋转和缩放可围绕指定枢轴进行。依据为2026年10月6日文档，项目应按实际安装版本和资产格式核对。

这不是要求所有项目采用Three.js，而是说明“形状正确”与“运动组织正确”是两件事。使用其他制作与接收工具，也要保留可重复执行的活动关系，不能只依赖制作人员临时拖动得到的画面。

分清三种交付，不要默认全包含

• 可动资产：活动部件、层级、轴心和默认姿态已经整理，但不一定有时间轴或按钮。
• 动画片段：指定动作、时长、循环或停止方式已经制作，需确认目标工具能读取。
• 应用交互：点击触发、动作打断、重复点击、复位与界面状态等逻辑，由应用实现范围决定。

采购方可以只需要其中一种，也可以组合采购，但要写明交接点。尤其“状态变了模型跟着动”涉及数据或业务触发条件，不能因为已有动画，就默认实时联动也已完成。

样件验收要走完整动作过程

1. 先看静止状态，确认部件位置、编号和默认朝向。
2. 从开始到结束慢速查看，关注门板、把手与相邻物体是否出现明显穿插或分离。
3. 从前、侧和实际使用视角查看，不只用制作动画时的最佳镜头。
4. 停止在中间再继续、结束后复位，确认不累积偏移；是否需要支持这些操作应先写入范围。
5. 导出后在接收环境重复同样步骤，保留版本与结果。

什么时候不应追求复杂运动

如果目的只是让观众认出设备，整机旋转或少量拆分说明可能已经足够。没有内部资料却增加开盖展示，会把未知结构暴露出来；没有真实运动依据却制作连贯动作，可能让观众误以为演示已经验证了机械可行性。

假设示例：售前页面需要展示柜门打开后的空间安排，可以用确认过的静态内部模型与开门动作；若要证明设备能在某载荷下安全运行，那已超出展示建模的结论范围，需要另行明确专业验证责任。

交付时把已完成动作、未包含触发逻辑及未验证物理条件分别列出。这样后续开发能够接着做，也能避免把展示效果误当成设备性能承诺。

双开门等联动动作还应记录是同时启动还是依次启动，避免同一套模型被双方理解成不同演示。

先画出部件的固定点、转轴和允许动作，再借助模型与UI协同方法确认演示如何触发。把起止状态和复位结果放进项目验收清单，并在三维建模服务范围里区分部件制作、动作演示与真实设备控制。