讲师：夜航（易知微设计总监）
本文将围绕 Web + 游戏引擎模式下的数字孪生项目展开，系统梳理其核心流程，重点聚焦四个方面：设计师在上下游协作中的技术认知边界、整体协作流程与配合方式、设计师在项目中的关键任务，以及对接开发团队时的提效方法。
围绕这些在真实项目中普遍存在的难点与问题，易知微「数字孪生实战训练营」也首次完整公开了一线交付团队的方法论与实战路径 ，带你从0到1拆解一个数字孪生项目的完整落地过程。目前训练营课程已全部更新完毕，如需了解更多内容，可点此进入易知微官网。
**（3）新西兰数字孪生专业公司网站：**场景氛围通透明媚，符合国内甲方审美需求，是行业实用参考。
1.2.3. 空间数据可视化。
三维场景与二维不同，需要完成大量空间数据可视化表达，除平面地图基础点线面外，还要研究三维场景中区域热力、数据层次的呈现方式。
推荐两个参考网站：
**（1）基于地理信息的数据可视化网站：**包含弧线、直线、六边形区域热力、散点、平面热力图、GeoJSON地理数据驱动地图、建筑物三维呈现、等高线、动态分布等多种数据表现形式，覆盖人口密度、车流、湿度、紫外线强度等场景。
**（2）麻省理工感知城市实验室：**拥有丰富且具创造性的数据呈现案例，可作为项目创意灵感来源。
2. Web+游戏引擎模式项目协作流程
在 Web + 游戏引擎的项目模式中，协作流程往往比传统项目更为复杂，其核心在于多角色协同与多端联动。基于实际项目经验，可以将整个流程拆解为"角色分工---需求阶段---执行阶段---开发与联调阶段"几个关键模块，从而更清晰地理解整体推进节奏。
2.1. 角色分工：多角色协同推进项目落地
在该模式下，一个完整项目通常涉及以下几类核心角色：
- **PM/PD：**即项目经理或产品经理，负责整体项目推进、需求梳理与方案设计；
- **设计师：**承担 UI 设计与交互设计相关工作；
- **模型师与场景地编（场景美术设计团队）：**负责三维模型制作与场景构建；
- **开发侧：**包括游戏引擎开发团队（如 UE）以及 Web 端开发团队，分别负责不同端的功能实现与技术支撑。
这些角色在不同阶段深度参与，共同完成从需求到落地的全过程。
2.2. 需求调研阶段：明确方向与达成共识
在项目初期，需求调研是最关键的环节之一，主要围绕三个核心维度展开。
- 业务功能需求的梳理：需要明确项目要实现的业务场景，以及系统应具备的具体功能。这一阶段往往决定了项目的整体方向。同时，如果涉及到团队尚未接触过的新技术，还需要在这一阶段同步开展技术预研，为后续开发做好准备，因此通常会被放在最前置的位置。
- 场景美术风格的调研与统一：这一环节主要由设计师、模型师以及场景地编共同参与。三方需要围绕最终视觉效果达成一致认知。通常的做法是，设计师与场景地编会先收集并整理参考图，明确预期的视觉方向，并组织讨论确定整体风格。模型师则基于这些风格参考，开展模型设计、贴图设计与材质设计，确保输出内容与整体风格保持一致。
- 交互逻辑与数据方案设计：在产品经理接收需求后，设计师、游戏引擎开发以及 Web 开发需要共同参与交互逻辑的讨论。一些功能的实现方式与交互设计，需要三端协同确认。同时，数据的来源以及接入方式，也需要在这一阶段明确，主要由开发团队负责承接与设计。
2.3. 执行阶段：并行推进设计与内容生产
在进入执行阶段后，各角色开始按照分工并行推进具体工作。
首先由产品经理完成原型的初步设计，明确产品结构与功能逻辑。在此基础上，设计师开展 UI 设计工作。同时，当场景建模需求明确后，模型师同步启动三维模型的制作工作。
模型完成后，场景地编将模型导入游戏引擎中，进行场景搭建与美术表现设计，完成空间布局与视觉呈现。与此同时，设计师也会基于自研平台进行页面搭建，并完成初步的交互配置。
当这一阶段结束时，项目整体的视觉效果已经具备初步雏形。
2.4. 视觉评审与中期对齐：多方联合优化效果
在初步成果形成后，设计师、模型师与场景地编需要进行一次联合评审，对整体视觉效果进行统一调整。
这一环节通常还会邀请客户共同参与评审与反馈，通过多轮沟通与优化，逐步收敛视觉方案，形成一个相对稳定的中期版本成果。这一步对于后续开发的顺利推进至关重要。
2.5. 功能开发阶段：引擎与前端协同实现
在视觉方案基本确定后，进入功能开发阶段。
对于需要在游戏引擎中实现的功能，由 UE 开发团队负责具体实现。在此过程中，设计师需要提供必要的支持材料，包括场景中的弹窗、标牌、点位等元素的切图素材，以及功能效果图等。这些素材将作为开发的重要依据，具体交付标准和细节深度也会在实际项目中进一步细化。
在素材与设计方案提供完成后，引擎开发人员开始进行场景交互功能的开发。当这一阶段完成后，整体功能层面基本构建完成。
2.6. 数据接入与系统联调：打通多端能力
在功能开发完成后，进入数据接入与系统联调阶段。
通常由客户侧提供相关接口，项目团队负责完成数据接入工作。同时，还需要打通 UI/Web 端与游戏引擎场景之间的通信机制，确保前后端与引擎之间的数据联动与交互正常运行。
这一阶段是从"可用"走向"可运行"的关键环节。
2.7. 测试与交付：整体打包与联合验证
在所有开发与联调完成后，项目进入最终阶段。
团队会对整体工程进行打包，并由所有相关角色共同参与运行测试，对系统功能、性能及稳定性进行全面验证。通过测试后，项目即可进入最终交付阶段。
整体来看，Web + 游戏引擎模式下的项目协作，是一个典型的多角色、高协同、跨端联动的复杂流程。从前期需求调研到中期设计执行，再到后期开发联调与测试交付，每一个环节都需要明确分工与高效配合，才能确保项目顺利落地。
3. 游戏引擎孪生中，设计师的关键任务
在该流程中，设计师除完成Web端UI设计与交互设计外，还需承担三项新增核心工作：场景风格敲定、场景功能效果设计、场景交互动效设计。
3.1. 较复杂的渲染效果图（和场景/模型关联度高）
在项目中，一类与场景和模型强关联的效果，通常需要由设计师输出较为复杂的三维渲染效果图。这类内容往往基于模型师提供的基础白模展开，在工具层面，多使用 Blender 等三维软件进行二次加工与视觉表达。例如常见的建筑楼层拆解效果，设计师需要在已有模型基础上，分别呈现未拆解状态与楼层分解后的结构效果，用于明确最终呈现逻辑与交互方式。
这一过程并不是设计师的单点输出，而是需要与场景地编及 UE 开发团队反复对齐。通过效果图的形式，提前确认"最终能实现到什么程度"、"视觉呈现应达到怎样的预期"，从而在开发前达成一致，减少后期反复修改的成本。
此外，类似三维热力图、复杂数据可视化效果等内容，也属于这一类场景。对于已有经验沉淀的通用效果，团队通常会积累为组件库，项目中可以直接复用；但一旦遇到新的业务需求或未曾实现过的效果，仍然需要设计师先行输出效果图，再由设计与开发共同评估技术实现路径。
同样的逻辑也适用于电子围栏、零部件结构选择等场景。例如零部件的结构切换，本质上是材质与样式的组合设计，不同表现形式对整体项目风格的影响较大，因此需要由设计师主导确定最合适的视觉方案，再交由开发实现。
3.2. 较简单的平面效果图（通用样式）
相比之下，另一类偏通用的视觉需求，则更多以平面效果图的形式呈现，整体复杂度相对较低，但在项目中同样不可或缺。
这类效果通常包括一些基础的交互视觉元素，例如零部件标牌的选中样式、流光流线效果、扫描范围的圆形提示、区域高亮（Diff 选中效果）等。这些内容往往不依赖复杂三维结构，可以直接基于已有素材或参考进行设计。
在实际制作中，设计师通常会使用 Figma、Sketch 等工具完成相关设计，并输出对应的切图资源，交付给开发使用。由于这类效果具有较强的通用性，一方面可以通过素材复用提升效率，另一方面在设计上也更强调与整体风格的一致性，而非复杂表现。
整体来看，这一类平面效果图更偏向"快速支撑功能呈现"，在保证视觉统一的前提下，以高效率完成交付，是项目推进过程中重要的基础支撑环节。
4. 协同对接引擎开发团队的「提效技巧」
4.1. 场景风格与色调快速达成一致
项目实施前必须与模型、场景团队约定风格，避免返工。早期项目常出现UI与场景风格各自独立、无法融合的问题。
场景风格主要分为三类：
- 写实风格：市场主流，易被客户接受，是典型数字孪生效果。
- 科技风格：对团队视觉表现力要求高，设计师需主导明确风格程度，输出详细风格规范或统一参考图。
- 其他风格化效果：与写实风差异较大，包含卡通质感、灰色低多边形、简洁彩色等风格，需多找参考、及时沟通，避免偏差。
如果在前期沟通阶段团队没有达成一致，但已经各自开始推进了，这个时候该怎么办？举个例子，客户要求做一个"蓝色科技风"的 UI，基于此，如果当前效果已经做出来了，那么整体色调应该如何调整？
在这个场景中，首先需要识别影响整体色调的主要元素，主要包括草地、建筑、天空以及道路。从色卡中可以发现整体颜色是偏暖、偏灰的色调。而前面提到的 UI 风格图，蓝色的饱和度较高，整体更加鲜亮，且偏冷色调。这样一来，就会产生明显的不匹配：一个是偏灰、偏暖的场景风格，一个是偏冷、高饱和的 UI 风格，两者之间存在冲突。
再对比另一张同样是园区场景的图片，虽然同样包含天空、道路、草地，甚至视角也接近，但通过颜色调整------比如草地由草绿色转为青绿色，灰色由暖灰转为冷灰------整体视觉效果就发生了明显变化。当将这类调整后的画面放入场景中时，会发现它与 UI 风格的匹配度明显更高。
因此，在这个过程中，关键是优先识别画面中占比最大、影响最强的色块，然后有针对性地与场景美术沟通，对这些关键元素的颜色进行调整，从而实现整体风格的统一。
4.2. 为标牌弹窗建立引擎常用字体组合库
大多数情况下和场景内位置关联度较高的标牌弹窗，会在游戏引擎中开发。但不同设计师在不同项目中，有可能会使用不同的字体。每个字体的相同字号对应的高度不一致，就会导致开发同学更换字体或调整这些字体高度细节比较耗费精力。
这时候就可以约定好几个常用的中文和数字字体搭配组合，形成UE中的字体组件，便于开发同学快速调用。
4.3. 切图规范
在实际项目中，切图的规范性往往直接影响开发效率与最终还原效果，其中一个常见问题就是切图留白不合理。尤其是在科技风设计中，很多设计稿会使用发光效果，如果不加控制，辉光范围可能会很大。当直接导出分组切片时，就容易出现图片四周存在大量"不可见留白"的情况。这些区域肉眼不易察觉，但在实际使用中，会对开发进行布局定位带来干扰，甚至影响交互点击区域。因此，在切图时需要借助切片工具，根据实际可见内容来裁切尺寸，尽量减少不必要的留白。
此外，对于同一系列的图标切图，尤其是存在多状态（如正常、维修、告警等）的图标，需要特别注意留白区域的一致性。不能简单按照每个图标的内容大小单独裁切，否则尺寸不统一会增加开发适配成本。统一的切图尺寸和留白规则，可以显著降低开发侧反复调整的工作量。
在涉及自适应宽度的元素（如标题栏、弹窗背景）时，通常需要进行三段式切图（左、中、右）。此时需要确保三部分的高度完全一致，避免出现左右高、中间低的情况，否则开发在对齐时会出现偏差。同时，中间可拉伸区域应尽量使用纯色，避免使用点状、条纹等纹理，否则在拉伸过程中容易产生变形，影响视觉效果。
在此基础上延伸到九宫格切图，其原则与三段式类似：四个角保持固定且尺寸一致，中间区域作为可拉伸部分，同样建议使用纯色填充，避免复杂纹理带来的拉伸问题。通过这些规范，可以有效提升设计与开发之间的协作效率，保证最终效果的稳定还原。
4.4. 效果验收常见问题清单
在项目交付前，效果验收是非常关键的一步。我们整理了一份常见问题清单，主要可以分为三大类，帮助大家在验收阶段更系统地发现问题、规避风险。
- 场景表现层面：需要重点关注模型比例是否合理，比如楼宇、树木、车辆等在现实中都有相对明确的尺寸关系，如果不注意，很容易出现楼过高、树过大等与现实比例不符的情况。此外，还要检查标牌大小是否符合设计规范，由于 UE 中的尺寸体系与设计稿存在差异，开发完成后需要重点核对是否过大或过小，是否影响阅读或遮挡场景。同时，标牌中的文字也需要检查适配情况，包括是否溢出背景、字号是否过小或比例不协调。最后是整体色调的一致性，尤其是由 UE 开发直接实现的一些功能效果（如道路流光、引导线等），要重点核查是否符合设计稿中的主色调与高亮色规范，避免出现风格偏差。
- UI 适配问题：主要集中在场景中的弹窗、标牌等 UI 元素，需要检查字体是否与设计规范一致，字号是否合理，以及是否存在缺字情况，尤其是在一些特殊字符或不常见文字中。此外，还需要关注多语言支持情况，例如英文及特殊符号的显示是否正常、是否符合预期。
- 动效与交互体验：一方面需要检查动效时长是否合理，避免过快或过慢，尤其是在如楼层拆解等大屏展示场景中，如果动画过快，容易引发视觉不适。另一方面，要检查热点点击区域是否准确，避免因切图问题导致点击范围过大或过小。同时，对于缩放、旋转及运镜操作，也需要重点测试其流畅性，检查是否存在卡顿、穿模或镜头移动过快导致眩晕等问题。
通过以上几个方面的系统检查，可以在交付前有效发现问题，确保最终呈现效果与设计预期一致。
以上就是本次干货分享的全部内容，下篇课程将为大家讲解提升项目过稿率与交付质量的方法技巧。同时还有Web篇、游戏引擎篇的技术讲解与项目协作流程内容，由不同老师分享。如果对以上内容有任何疑问，或想进一步交流，如需了解更多内容，可点此进入易知微官网。