做数字孪生可视化项目交互需求永远是甲方最关心的一环。最开始接触这类项目时很多客户问的第一句话是模型能点吗点了会不会亮我一般回答能点也能亮。但后来问题升级了设备有好几种状态光高亮不行能不能点一下变成不同的颜色比如正常绿色、报警红色这个问题很实际。以山海鲸可视化为例我这边有一个完整的实现案例今天整理出来和大家聊聊。这个案例要解决的核心问题很简单在三维场景中点击模型除了默认的高亮反馈外如何把颜色也切换成想要的业务状态色。很多数字孪生项目里模型不代表单一物体背后往往绑定一个设备、一个温控器、一台生产线设备颜色代表设备健康度。高亮只是视觉提示颜色才是业务信息。所以这个需求一旦想通后面做状态监控、告警联动、应急指挥都会顺很多。这篇就按我的实际实施顺序来写偏操作向直接可复用。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台实施人员一个个去配置事件改得昏天黑地。建议从一开始就建立批量管理思路按命名规则、按分组、按数据表去批量下发配置。在山海鲸可视化中可以先把同类型设备放入同一个组比如“泵组”“阀门组”然后对组绑定统一的状态数据源和事件模板。状态颜色映射表也建议在项目一开始就定下来并且放在文档里。以下是我常用的一份颜色方案可以直接抄作业状态码状态名称推荐颜色场景含义0正常#00D68F设备运行正常1预警#FFC53D参数接近阈值提醒关注2报警#F5222D设备异常需要处理3离线#8C8C8C数据中断或设备停机4检修#2F54EB设备处于维护状态这份表里尽量降低了颜色的饱和度避免在大屏上长时间观看刺眼。实际项目中颜色可能还要根据甲方VI调整但状态码和含义不要随便改改来改去逻辑就乱了。4.3 与2D看板、弹窗、图表的联动点击模型变色只是一种交互真正的价值在于把三维场景和2D看板联动起来。我做的项目中点击泵站里的一个设备后除了模型变红还会触发右侧面板弹出这个设备的基本信息、实时数据、最近5分钟曲线同时整个大屏顶部的统计卡片也会变化。整个过程只需要一次点击用户立刻能获取完整的上下文不需要在多个页面之间跳来跳去。在山海鲸可视化这类平台里三维场景和2D看板通常可以通过共享数据集、资源联动、按钮事件等方式联动。建议你在设计事件时把“点击模型”作为事件源后续所有动作都以分支形式挂在这个事件下面。比如高亮当前模型、设置模型颜色、弹出设备详情面板、筛选2D图表数据、发送设备位号给顶部标题区域。这样一个事件就完成了所有联动逻辑清晰后期也好维护。5. 实战中的常见问题与排错记录5.1 点击模型没有反应的排查路径做交互功能时最容易遇到的就是明明给模型加了点击事件预览时点了却没反应。我遇到这类问题会按下面顺序排查基本都能定位到原因。先检查当前场景是否处于可交互状态有些平台在预览时默认没有开启编辑再确认事件动作是否绑定了当前模型特别是动作里如果使用固定模型ID很容易出现ID对不上然后看看模型是否有遮挡比如透明外壳模型挡住了内部模型点击事件可能被外层模型吃掉最后看浏览器控制台有没有报错脚本一旦报错前面配置的动作大概率不会执行。还有一个很容易被忽视的点如果模型是导入的整机模型没有拆成可交互子节点那点击事件只能加在父节点上。这种情况下点击某个部件由于碰撞体和网格范围内大部分顶点属于子对象父级不一定会收到鼠标事件。解决办法是建模阶段为每个关键部件拆分模型或者在平台中为需要交互的部件单独设置碰撞体或热区。这件事越早做越好后期补会非常痛苦。5.2 高亮出现但颜色不变或颜色丢失点击后有高亮说明事件流程已经走到了模型对象但颜色没变化多半是材质不配合。最常见的原因是模型使用了多材质而事件动作只改了其中一个材质如果模型是用Blender、草图大师等导出的表面可能存在多个材质球。另一个常见原因是模型自身带有贴图纹理颜色覆盖了基础色这个时候你修改基础色当然看不出来。遇到这种问题我的临时检查方法是把模型所有材质合并成单材质或者把纹理贴图临时去掉看颜色能不能变。如果合并材质后颜色还是变不了那就要检查是不是有动画或状态在覆盖颜色。有些平台支持模型动画动画在循环播放时会把材质颜色持续刷回原值导致你怎么改都会被临时覆盖。解决方法是暂停或停止该模型的动画或者把颜色修改动作放在动画更新之后。这个坑不容易想到但一旦遇到排查起来很费时间。5.3 多个模型同时高亮、颜色混乱页面出现三四个模型同时高亮、颜色五颜六色往往是事件逻辑里缺少重置动作。举个例子先点AA变红再点BA没有恢复B也变红看起来就像场景里面故障成片。实际上A可能已经恢复正常了但视觉上还是红的。解决思路是点击B之前先把所有模型的状态颜色复位为数据源状态对应的颜色然后再对B应用高亮和当前的选中色。如果你的平台支持“取消所有选中”可以直接使用否则可以在事件开头通过循环脚本把每个模型都恢复默认。另外要注意如果模型数量很多每次都把所有模型遍历一遍性能会有压力。这时候可以在代码里维护一个“当前已变色模型”的集合只重置集合里记录的模型而不是全场景遍历。配置项里如果提供了类似“清除所有状态效果”的动作通常效率更高。我在演示项目中就遇到过场景里几十台设备同时闪烁的问题后来改成只重置上一个模型性能立刻好了很多。5.4 场景卡顿与模型性能优化三维场景卡顿不一定是因为内存不足更多时候是GPU draw call太多尤其是设备模型多、每个模型还有独立材质的情况。点击变色这种高频交互还容易触发整棵场景树刷新优化不好就会一卡一卡。首先要控制模型面数建模时尽量使用合理的LOD远处设备用低模其次能共用材质的模型尽量共用这样GPU可以合批渲染性能会明显提升。在做颜色切换时尽量不要每帧都设置材质颜色只在状态变化时更新一次。如果平台有“实例化渲染”选项建议开启特别适合几十上百个结构相同、颜色不同的设备模型。另外在低配电脑上多测试几轮尤其是连续快速点击不同模型时观察内存和帧率变化。如果出现显存持续上涨说明可能有资源泄漏优先检查是不是每次点击都动态创建了新材质没有释放。6. 案例效果与个人经验总结6.1 一个典型落地场景泵站设备状态监测实战案例放在泵站场景里最有代表性。当时项目做了某泵站数字孪生大屏三维场景里包含泵、阀门、管道、仪表、建筑等模型设备数量总共接近一百个。最初版本只做了点击高亮用户可以点击设备查看详情。后来客户提出要把状态直接体现在模型上我们就做了颜色切换联动。借助山海鲸可视化将每个设备模型按照位号命名接入泵站SCADA系统的设备状态数据设备故障时模型自动变红点击模型后不仅高亮还能弹出实时数据面板。上线后运维人员反馈很正面。过去看设备状态要靠2D列表扫一眼只能看到数字现在直接看三维场景里哪个模型红了就能快速定位到问题设备。点击后变高亮配合右边的实时数据面板也不用再去翻工单系统。整个交互闭环一次点击完成大大减少了寻找设备的时间。这其实就是数字孪生带来的最实际价值用空间直觉替代数据表格。6.2 实施心得与建议最后说几点我从这个项目里沉淀下来的经验。第一需求阶段一定要确认颜色规范是正常绿报警红还是倒过来别等到开发完了再改颜色映射改了之后所有模型都要重新验证。第二模型命名和逻辑ID是命脉宁可前期多花半天时间整理命名也不要后期熬夜改配置。第三能用数据驱动就不要用点击动作写死颜色生产环境状态是动态的你不可能派人一直坐在那里点模型。我个人在项目里最有感触的一点是高亮和变色不是两个功能而是一条完整交互链路上的两个环节。高亮负责告诉用户“你选中了哪个”变色负责传递“这个设备现在是什么状态”两者加在一起用户只需要一次点击就能理解当前情况。如果你也在做数字孪生三维场景建议先把模型层级、数据字段、颜色映射这三件事理清楚再动手配置交互。交互配置本身不难难的是前面这些准备工作。这个项目后续还可以扩展的方向也很多比如点击模型同时播放设备运行动画、根据温度变化产生动态粒子效果、把历史状态回放做成时间轴山海鲸可视化的三维场景加上这些联动后能用的场景会越来越丰富。如果你们正好也有类似需求可以照着文章里的思路先跑通一个原型有问题再交流。