数字孪生可视化：点击模型切换业务状态色的实现指南

做数字孪生可视化项目，交互需求永远是甲方最关心的一环。最开始接触这类项目时，很多客户问的第一句话是：模型能点吗？点了会不会亮？我一般回答：能点，也能亮。但后来问题升级了：设备有好几种状态，光高亮不行，能不能点一下变成不同的颜色，比如正常绿色、报警红色？这个问题很实际。以山海鲸可视化为例，我这边有一个完整的实现案例，今天整理出来和大家聊聊。

这个案例要解决的核心问题很简单：在三维场景中，点击模型除了默认的高亮反馈外，如何把颜色也切换成想要的业务状态色。很多数字孪生项目里，模型不代表单一物体，背后往往绑定一个设备、一个温控器、一台生产线设备，颜色代表设备健康度。高亮只是视觉提示，颜色才是业务信息。所以这个需求一旦想通，后面做状态监控、告警联动、应急指挥都会顺很多。这篇就按我的实际实施顺序来写，偏操作向，直接可复用。

1. 需求拆解：为什么“高亮之外还要变色”

1.1 高亮的本质与局限性

在三维场景里，高亮其实是给用户一个“你选中了我”的视觉反馈。常见做法是给模型加描边、加发光，或者把透明度调整一下，让目标物体从周围环境中跳出来。你可以把它理解成手电筒照到一个设备上，只负责吸引注意力。这种交互在点击查询、模型定位、场景切换时非常有用，也是数字孪生项目中最基础的交互反馈之一。山海鲸可视化里也有类似能力，选中模型后设置高亮样式，预览时点一下就能看到效果。

但高亮也有一个很明显的局限：它只有“亮”和“不亮”两种状态。一个布尔值能表达的反馈，承载不了多态业务信息。比如一个机房里几十台服务器，用户点一台，这台亮了，但它是正常运行还是负载过高？高亮没法区分。你总不能一台设备存了故障，显示成“更亮”，另一台显示成“亮一百倍”，人眼根本没法分辨。而且高亮本质上还是没有脱离“选中”的含义，它不能告诉用户“当前这台设备处于什么状态”。这就是为什么很多人做数字孪生做过一阵后，会自然产生一个想法：能不能让模型本身根据状态显示成不同颜色。

1.2 颜色切换带来的真实业务价值

切换颜色的本质，是把模型的视觉状态从“选中”升级成“状态表达”。它不仅仅是把材质从灰变成绿，而是把一个设备的业务含义直接编码成了颜色。最常见的场景就是设备状态监控：绿色代表正常、黄色代表预警、红色代表报警、灰色代表离线。运维人员在大屏前扫一眼三维场景，不需要逐个点击设备，就能知道现场大概哪块区域有问题。如果你所在的项目还处在“所有模型一个颜色、点一下才高亮”的初始阶段，这个升级会带来很直观的体验提升。

另一方面，颜色切换还能减少交互层级。传统方式下，要看设备状态可能需要打开列表、查详情、看弹窗，路径很长。而点击变色可以在一个动作里完成“选择”和“状态呈现”两件事，用户不需要读取额外文字就能获得状态信息。这也是数字孪生对比传统2D管理的优势之一。当然，颜色不能随便用，需要事先定好一套状态色规范，让所有操作人员一看就懂。我在项目里一般会把颜色规范写进需求文档，防止后面甲方自己人也争到底哪个颜色代表报警。

1.3 这个需求在山海鲸可视化中的可行性

山海鲸可视化做这件事是完全可行的。它的定位是低代码可视化平台，既可以用内置交互配置完成点击高亮、颜色联动，也可以绑定数据集做状态驱动。和纯手写Three.js相比，它的优势是建模和交互的可视化程度高，实施人员不用写很多代码就能交付；和传统代码开发相比，它又把模型的属性暴露得比较充分，不至于让人想改个颜色都找不到入口。我下面讲的步骤，就是基于山海鲸可视化场景编辑器来展开的。

2. 山海鲸可视化中的模型准备与场景搭建

2.1 模型导入与层级命名规范

不管是高亮还是变色，前提是模型能被精确识别。很多人项目做到一半才发现，模型是一个整块，点击一个泵，整个车间都亮了，这就是模型组织结构没做好。在山海鲸可视化中创建三维场景，建议提前和建模同事约定：一个可交互设备对应一个独立节点，节点命名使用规范的英文标识，例如Pump_001、Valve_002、Sensor_003。不要用中文名、不要用空格、不要用“设备1(最终) v3”这种名字，后续配置数据源和事件时你会感谢自己当时的克制。

模型格式方面，我习惯优先用glTF或GLB格式，这两种格式对材质、贴图和动画的支持比较完整，浏览器端渲染兼容也好。部分平台也支持FBX，但有时会在材质属性上出现问题，比如颜色被贴图盖住，导致后面改色不生效。所以如果是为了做交互变色，导入场景前先确认模型使用的是标准材质，并且至少有一套基础色可控。另外，一个模型里尽量不要混用太多材质球，不然运行时你要同时更新多个材质，很容易漏掉其中一个，造成颜色显示一半一半。

2.2 场景属性与模型对象的管理

模型导入后，第一步是建立对象管理逻辑。在山海鲸可视化场景编辑器中，选中任意模型，右侧会显示这个模型的相关属性。我通常会把模型的显示名称改成和生产系统中的设备位号一致，比如“P-101循环水泵”，然后在备注或Tag字段里填入逻辑ID，比如“pump_101”。这个逻辑ID非常重要，它会在后面作为点击事件和数据报文之间的关联键，如果这里乱了，后面所有联动都会跟着乱。

有些项目可能用到外部采集的数据，比如设备的电流、温度、启停状态，这些数据通常来自数据库或API接口。我建议在场景搭建阶段就把每个模型和数据字段对应关系整理成一张表，字段至少包括：模型名称、逻辑ID、设备类型、状态字段名、单位、正常范围。后续做数据绑定时，直接按这张表配置，能省下大量反复试错的时间。别看这些准备工作繁琐，实际上了项目你才会发现，大多数交付延期不是平台功能不够，而是前期数据关系没有梳理清楚。

2.3 数据源准备与状态字段设计

要实现“点击模型之后切换颜色”，最直接的方式是点击动作去修改当前模型颜色。但如果你想做的是“真实设备状态驱动颜色变化”，那就得先准备数据源。山海鲸可视化支持常见的数据源接入方式，比如数据库、接口、Excel等，具体以你使用的版本为准。我一般建议先创建一个模拟数据源，里面包含两个字段：设备ID和设备状态。设备ID用来匹配模型，设备状态用来决定颜色。

状态字段建议使用数字或英文枚举，不要直接放中文。比如0=正常，1=预警，2=报警，3=离线。理由有两点：第一，中文在数据报文里容易有编码问题，万一接口返回的编码不一致就很麻烦；第二，数字枚举可以方便做范围判断，比如值大于等于2就触发报警色。如果你熟悉SQL或脚本，可以在数据源里做一个计算字段，把温度和阈值转换成状态编码，这样模型侧不需要写复杂逻辑。

3. 点击交互：高亮与颜色切换的实现步骤

3.1 给模型绑定点击事件

先说标准做法。在山海鲸可视化中，选中你要交互的模型，在交互设置里添加“点击”事件，然后配置对应的动作。很多低代码平台的逻辑都是这种“事件—动作”结构，触发事件后执行一系列动作。要做的第一件事，就是让点击事件能够识别当前模型。平台一般会带一个当前模型参数，你后续的动作可以直接引用它。如果你用的是“选择模型”这种对象类型参数，一定要确保动作中指向的是“触发事件的模型”，而不是某个写死的模型名称。

这一步看起来琐碎，但非常影响后续扩展。举例来说，如果你给一百台泵都绑定了同一个事件模板，而模板里动作绑定的模型是固定的Pump_001，那点击Pump_002也会去改Pump_001的颜色。所以我建议在事件配置里优先使用“当前对象”或“事件源”参数，而不是手动选中模型。这个习惯做好之后，无论是高亮还是变色，都能自动适应每个设备。

3.2 高亮样式设置与开关时机

点击模型后先高亮，这是很自然的交互反馈。山海鲸可视化里高亮一般通过描边、发光或透明度变化实现。我建议用描边加适度透明度变化，因为描边不依赖模型本身的材质颜色，即使模型贴图很花也还有辨识度；纯发光在某些低端设备上看起来会很生硬，而且如果模型本身是发光材质，视觉上会很乱。设置好高亮样式之后，你还需要考虑一个很关键的问题：高亮什么时候消失？

如果点击A设备，A高亮一直亮着，再点击B设备，A还是亮着，就会出现一大片高亮模型，视觉辨认度立刻下降。正确做法是：每次点击新模型之前，先清除上一个模型的高亮和颜色状态，再对新模型执行高亮和变色。在山海鲸可视化中，可以通过一个全局变量记录“当前选中模型”，或使用平台提供的重置状态动作。流程上就是在点击事件里加上两步：先取消所有模型选中状态，再设置当前模型选中状态。

3.3 切换颜色的核心思路与操作流程

这里就是标题里提到的问题重点了。高亮只是第一步，颜色切换才是状态表达。核心思路很简单：把模型的材质颜色属性，和当前设备状态值做映射。比如当前状态参数为0，就设置模型颜色为绿色；状态参数为1，设置模型颜色为黄色。在山海鲸可视化里，你可以在点击事件的动作列表中添加“设置模型颜色”或“修改材质属性”这类动作。如果产品版本支持数据联动，你还可以直接把模型颜色绑定到数据集里的一个字段，数据更新时颜色自动变化，连点击都不需要。

以模拟数据为例：我建了一个字段device_status，默认值是0。预览时点击模型，触发事件，先读取当前设备状态值，再根据状态值匹配颜色，最终把模型颜色设置为匹配值。如果想要循环演示，可以在点击动作里设置状态值加1，超过最大值就归零，这样每点一次模型颜色就变一次，方便验证逻辑。当然，生产环境不要用这种循环，应该把点击和状态查询分开，点击只负责选中和查询，颜色变化交给数据源推送。

3.4 如果平台内置能力不够，怎么用脚本兜底

山海鲸可视化的可视化配置已经能覆盖大多数场景，但如果遇到特殊逻辑，比如要根据连续数值渐变颜色、要同时改变多个相关模型颜色、或者要和外部系统交付复杂参数，还是需要脚本。即使平台有脚本面板，具体API也因版本而异，我不在这里编造一键复制就能跑的代码，但可以给你一个通用的逻辑参考：先查找模型对象，再设置高亮属性，再修改颜色属性。

// 伪代码，请按实际平台的接口调整 var model = scene.findModelByTag('pump_101'); if (model) { model.setHighlight(true); var status = data.getValue('device_status'); var colorMap = ['#00D68F', '#FFC53D', '#F5222D', '#8C8C8C']; model.setColor(colorMap[status]); }

这种脚本的好处是灵活，坏处是出了问题不好排查，而且版本升级可能有兼容性风险。我个人的建议是：能在配置层实现就别写脚本，脚本只做配置解决不了的事。如果非要写，也要把脚本集中放，并提前注释好，方便后来接手的人看懂。

4. 数据联动与业务状态扩展

4.1 从“点击变色”到“状态驱动变色”

上面第3章讲的都是点击后临时改色，属于“手动模式”。但数字孪生项目真正上线以后，设备状态每秒都在变，用户不可能一直用鼠标点。所以更合理的做法是让模型颜色由数据源自动驱动。数据源里设备状态一旦变化，三维场景里的模型颜色跟着变，不需要任何人操作。这也就是数字孪生中常说的“数字孪生体”概念：模型和真实设备时刻保持同步。

我在实际项目里的做法是：山海鲸可视化场景中不把状态值写死，而是动态绑定某个数据字段。平台在数据源刷新时，如果字段值改变，就执行相应的颜色更新动作。你可以在数据源配置里设置轮询刷新，比如每5秒读一次接口，也可以接收WebSocket推送。这样一来，点击高亮变成“查看详情”的入口，而模型颜色变成持续显示的状态指示灯，两者各司其职。

4.2 多模型批量管理与状态映射

如果你的项目里只有几个模型，逐个配置当然没问题。可一旦模型数量到了几十上百，还靠手点就疯了。我见过不少项目初期只有3台设备演示，后面扩展到50台，实施人员一个个去配置事件，改得昏天黑地。建议从一开始就建立批量管理思路：按命名规则、按分组、按数据表去批量下发配置。在山海鲸可视化中，可以先把同类型设备放入同一个组，比如“泵组”“阀门组”，然后对组绑定统一的状态数据源和事件模板。

状态颜色映射表也建议在项目一开始就定下来，并且放在文档里。以下是我常用的一份颜色方案，可以直接抄作业：

这份表里尽量降低了颜色的饱和度，避免在大屏上长时间观看刺眼。实际项目中颜色可能还要根据甲方VI调整，但状态码和含义不要随便改，改来改去逻辑就乱了。

4.3 与2D看板、弹窗、图表的联动

点击模型变色只是一种交互，真正的价值在于把三维场景和2D看板联动起来。我做的项目中，点击泵站里的一个设备后，除了模型变红，还会触发右侧面板弹出这个设备的基本信息、实时数据、最近5分钟曲线，同时整个大屏顶部的统计卡片也会变化。整个过程只需要一次点击，用户立刻能获取完整的上下文，不需要在多个页面之间跳来跳去。

在山海鲸可视化这类平台里，三维场景和2D看板通常可以通过共享数据集、资源联动、按钮事件等方式联动。建议你在设计事件时，把“点击模型”作为事件源，后续所有动作都以分支形式挂在这个事件下面。比如：高亮当前模型、设置模型颜色、弹出设备详情面板、筛选2D图表数据、发送设备位号给顶部标题区域。这样一个事件就完成了所有联动，逻辑清晰，后期也好维护。

5. 实战中的常见问题与排错记录

5.1 点击模型没有反应的排查路径

做交互功能时最容易遇到的就是：明明给模型加了点击事件，预览时点了却没反应。我遇到这类问题会按下面顺序排查，基本都能定位到原因。先检查当前场景是否处于可交互状态，有些平台在预览时默认没有开启编辑；再确认事件动作是否绑定了当前模型，特别是动作里如果使用固定模型ID，很容易出现ID对不上；然后看看模型是否有遮挡，比如透明外壳模型挡住了内部模型，点击事件可能被外层模型吃掉；最后看浏览器控制台有没有报错，脚本一旦报错，前面配置的动作大概率不会执行。

还有一个很容易被忽视的点：如果模型是导入的整机模型，没有拆成可交互子节点，那点击事件只能加在父节点上。这种情况下点击某个部件，由于碰撞体和网格范围内大部分顶点属于子对象，父级不一定会收到鼠标事件。解决办法是建模阶段为每个关键部件拆分模型，或者在平台中为需要交互的部件单独设置碰撞体或热区。这件事越早做越好，后期补会非常痛苦。

5.2 高亮出现但颜色不变或颜色丢失

点击后有高亮，说明事件流程已经走到了模型对象，但颜色没变化，多半是材质不配合。最常见的原因是模型使用了多材质，而事件动作只改了其中一个材质；如果模型是用Blender、草图大师等导出的，表面可能存在多个材质球。另一个常见原因是模型自身带有贴图，纹理颜色覆盖了基础色，这个时候你修改基础色当然看不出来。遇到这种问题，我的临时检查方法是：把模型所有材质合并成单材质，或者把纹理贴图临时去掉，看颜色能不能变。

如果合并材质后，颜色还是变不了，那就要检查是不是有动画或状态在覆盖颜色。有些平台支持模型动画，动画在循环播放时会把材质颜色持续刷回原值，导致你怎么改都会被临时覆盖。解决方法是暂停或停止该模型的动画，或者把颜色修改动作放在动画更新之后。这个坑不容易想到，但一旦遇到，排查起来很费时间。

5.3 多个模型同时高亮、颜色混乱

页面出现三四个模型同时高亮、颜色五颜六色，往往是事件逻辑里缺少重置动作。举个例子，先点A，A变红，再点B，A没有恢复，B也变红，看起来就像场景里面故障成片。实际上A可能已经恢复正常了，但视觉上还是红的。解决思路是：点击B之前，先把所有模型的状态颜色复位为数据源状态对应的颜色，然后再对B应用高亮和当前的选中色。如果你的平台支持“取消所有选中”，可以直接使用，否则可以在事件开头通过循环脚本把每个模型都恢复默认。

另外要注意，如果模型数量很多，每次都把所有模型遍历一遍，性能会有压力。这时候可以在代码里维护一个“当前已变色模型”的集合，只重置集合里记录的模型，而不是全场景遍历。配置项里如果提供了类似“清除所有状态效果”的动作，通常效率更高。我在演示项目中就遇到过场景里几十台设备同时闪烁的问题，后来改成只重置上一个模型，性能立刻好了很多。

5.4 场景卡顿与模型性能优化

三维场景卡顿，不一定是因为内存不足，更多时候是GPU draw call太多，尤其是设备模型多、每个模型还有独立材质的情况。点击变色这种高频交互，还容易触发整棵场景树刷新，优化不好就会一卡一卡。首先要控制模型面数，建模时尽量使用合理的LOD，远处设备用低模；其次，能共用材质的模型尽量共用，这样GPU可以合批渲染，性能会明显提升。

在做颜色切换时，尽量不要每帧都设置材质颜色，只在状态变化时更新一次。如果平台有“实例化渲染”选项，建议开启，特别适合几十上百个结构相同、颜色不同的设备模型。另外，在低配电脑上多测试几轮，尤其是连续快速点击不同模型时，观察内存和帧率变化。如果出现显存持续上涨，说明可能有资源泄漏，优先检查是不是每次点击都动态创建了新材质没有释放。

6. 案例效果与个人经验总结

6.1 一个典型落地场景：泵站设备状态监测

实战案例放在泵站场景里最有代表性。当时项目做了某泵站数字孪生大屏，三维场景里包含泵、阀门、管道、仪表、建筑等模型，设备数量总共接近一百个。最初版本只做了点击高亮，用户可以点击设备查看详情。后来客户提出要把状态直接体现在模型上，我们就做了颜色切换联动。借助山海鲸可视化，将每个设备模型按照位号命名，接入泵站SCADA系统的设备状态数据，设备故障时模型自动变红，点击模型后不仅高亮，还能弹出实时数据面板。

上线后运维人员反馈很正面。过去看设备状态要靠2D列表，扫一眼只能看到数字，现在直接看三维场景里哪个模型红了，就能快速定位到问题设备。点击后变高亮，配合右边的实时数据面板，也不用再去翻工单系统。整个交互闭环一次点击完成，大大减少了寻找设备的时间。这其实就是数字孪生带来的最实际价值：用空间直觉替代数据表格。

6.2 实施心得与建议

最后说几点我从这个项目里沉淀下来的经验。第一，需求阶段一定要确认颜色规范，是正常绿报警红，还是倒过来，别等到开发完了再改，颜色映射改了之后所有模型都要重新验证。第二，模型命名和逻辑ID是命脉，宁可前期多花半天时间整理命名，也不要后期熬夜改配置。第三，能用数据驱动就不要用点击动作写死颜色，生产环境状态是动态的，你不可能派人一直坐在那里点模型。

我个人在项目里最有感触的一点是：高亮和变色不是两个功能，而是一条完整交互链路上的两个环节。高亮负责告诉用户“你选中了哪个”，变色负责传递“这个设备现在是什么状态”，两者加在一起，用户只需要一次点击就能理解当前情况。如果你也在做数字孪生三维场景，建议先把模型层级、数据字段、颜色映射这三件事理清楚，再动手配置交互。交互配置本身不难，难的是前面这些准备工作。

这个项目后续还可以扩展的方向也很多，比如点击模型同时播放设备运行动画、根据温度变化产生动态粒子效果、把历史状态回放做成时间轴，山海鲸可视化的三维场景加上这些联动后，能用的场景会越来越丰富。如果你们正好也有类似需求，可以照着文章里的思路先跑通一个原型，有问题再交流。