互动内容引擎与素材制作概念：Unity/UE/TouchDesigner/H5/专用软件怎么选
- 了解展厅互动内容引擎的五条主线（Unity/UE/TouchDesigner/网页H5/专用软件），知道各自适合什么场景
- 掌握互动素材制作的工程要点：分辨率适配屏体、触发逻辑设计、帧率要求
- 理解内容与硬件感应的对接方式（信号通道、协议、数据结构）
- 学会写外包互动内容的需求文档，避免"做出来用不了"
- 有一套引擎选型决策逻辑，能对照项目需求快速缩小选择范围
一个展项的体验好不好，感应准不准是门槛，但参观者真正感受到的是内容——动效流不流畅、交互反馈给不给力、风格和展厅整体调性搭不搭。
很多项目的真实状况是：硬件选好了，感应方案也定了，但到了"内容做什么、用什么做、怎么做"这个环节，方案书上只写了"互动内容系统"六个字，实际用哪个引擎、谁来做、什么格式交付，都是含糊的。最后要么外包商交来的内容跑不起来（分辨率对不上、帧率低、感应信号接不进去），要么甲方验收时发现效果和预期差太远。
这一节把内容侧的事情讲清楚。
R1 概念节，涉及具体软件版本/参数时以各引擎官方文档为准，行业数值为参考区间。
展厅互动内容引擎的五条主线
展厅互动内容开发，业内主要走这五条路：
| 引擎/方式 | 定位 | 典型输出形式 |
|---|---|---|
| Unity | 实时3D/游戏引擎，跨平台 | 打包可执行程序（.exe / Android APK） |
| Unreal Engine（UE） | 高保真实时渲染，适合大场面 | 打包可执行程序，部分支持Pixel Streaming |
| TouchDesigner | 创意编程/实时视觉，AV/VJ主流 | 实时运行的.toe工程（非打包可执行文件） |
| 网页 H5（Web） | 网页技术栈，轻量分发 | 运行在浏览器里（Chrome/Electron壳） |
| 专用展厅软件 | 成品内容管理系统，低代码 | 配置化内容（非自研代码） |
没有哪个绝对更好，选哪条路取决于这个项目的预算、展项的复杂程度、内容更新频率、以及开发团队的技术栈。
一、Unity：最通用的展厅互动开发平台
适合什么场景：
- 展项有3D模型交互（旋转、拆解、缩放展品）
- 需要游戏化体验（答题、骨架互动、碰碰乐）
- 甲方要求内容在 Windows 工控机上独立运行（无网络依赖）
- 项目有定制化感应接入需求（需要写代码处理传感器信号）
能做什么：3D场景渲染、物理模拟、触摸/鼠标/手势交互、视频/音频播放、与外部系统通信（UDP/TCP/WebSocket/串口）。
不适合什么：超高保真的实时渲染（UE 更强）；内容以视频循环为主不需要交互（播控软件或TouchDesigner更合适）；开发团队只会H5，没有Unity开发者。
工程要点：
- 打包前确认目标机器显卡能否稳定跑目标帧率（展厅工控机通常用N卡中端，不是高端游戏显卡）
- 多屏拼接场景：Unity支持多显示器输出，但需要在代码里明确配置Display.displays；渲染分辨率=整块拼接屏的总分辨率，不是单块屏
- 与中控/传感器对接：通常走UDP或TCP Socket，Unity端开一个监听，接收中控发来的JSON或自定义格式触发消息
一个展厅里常见的Unity对接链路：
中控（SoftControl）→ TCP/UDP → Unity端口监听
Unity接收到"展项A触发"消息 → 切换场景/播放动效
Unity交互结果（如答题正确）→ 发消息回中控 → 中控联动灯光/声音
二、Unreal Engine（UE）：高保真场景的选择
适合什么场景：
- 甲方要求的视觉质量非常高（如大型城市规划展厅、汽车展厅、科技馆主展项）
- 展项有大场景实时渲染（如城市沙盘漫游、工厂数字孪生）
- 预算充足、开发周期够长（UE学习曲线和开发成本都比Unity高）
能做什么：比Unity更强的光影和材质效果、Nanite虚拟化几何体（超多面数模型）、Lumen全局光照；也支持与外部系统通信，有OSC/UDP插件。
不适合什么：
- 中小型展项（内容不到UE渲染级别，浪费预算和工期）
- 开发团队不熟悉UE蓝图/C++（项目死在开发周期上的概率很高）
- 工控机配置一般（UE高质量场景对显卡要求远高于Unity，跑不起来交付现场很尴尬）
Pixel Streaming是个坑：UE5有Pixel Streaming方案（服务器端渲染推流到浏览器），可以减轻终端硬件压力，但引入了网络延迟和IT运维复杂度，大多数展厅场景反而不适合。除非有明确需求（如多终端共享一台高端服务器渲染），否则还是走本地打包。
三、TouchDesigner：实时视觉和创意互动的另一条路
TouchDesigner是什么：Derivative出品的实时创意编程环境（不是"引擎"，是节点式编程工具）。使用CHOP（Channel Operator）、SOP（Surface Operator）、COMP（Component）等节点拼接逻辑，特别擅长处理实时数据驱动的视觉——把传感器数据直接映射成画面变化。
适合什么场景：
- AV装置/沉浸式声光互动展项（粒子效果跟随声音/雷达数据跳动）
- 开幕式/发布会实时演出级互动（VJ风格）
- 快速原型做一个感应→视觉效果的demo
- 团队里有TouchDesigner设计师/VJ经验的人
不适合什么：
- 需要打包成稳定可执行文件部署到多台机器（TD是运行.toe工程，需要安装TD本体，商业授权价格不低）
- 展项需要复杂游戏逻辑/状态机（用TD做复杂业务逻辑会很痛苦）
- 运营人员不会TD，出了问题现场无法自行维护（风险高）
与感应的对接：TouchDesigner原生支持OSC、MIDI、DMX、串口、UDP，直接在CHOP里建对应的输入节点就能读传感器数据，开发速度快。这也是为什么做感应→实时视觉演出效果，TD比Unity快很多。
TD商业许可证按节点规模分级，展厅长期装置记得确认是否需要商业授权；非商业授权版有分辨率上限（1280×1080），正式展厅基本都需要商业版。以Derivative官网当前授权条款为准。
四、网页 H5：轻量、易维护、部署灵活
适合什么场景：
- 触摸查询机、互动翻书、答题展项（内容以网页UI交互为主）
- 内容需要频繁更新（改网页比重新打包发布App方便）
- 展项内容本来就是"查信息/做选择"而不是"3D互动"
- 多台展厅终端统一内容管理（部署到局域网服务器，所有终端访问同一URL）
运行方式：全屏Chrome（或Electron壳把网页打包成App形式）。Chrome的Kiosk Mode（--kiosk参数）可以做到无边框、无地址栏、全屏、不能退出，展厅里很常用。
能做什么：触摸交互、视频、音频、WebGL（3D渲染）、WebSocket（与外部系统实时通信）、Canvas 2D动效。现代浏览器的WebGL能力已经相当强，简单3D场景完全没问题。
工程要点：
- 感应与H5对接最常见的方式：WebSocket——中控或一个局域网服务（如Node.js/Python）接收传感器信号，通过WebSocket推给浏览器内的网页，网页端监听消息做响应
- 跨域/安全策略：Chrome Kiosk模式下部分安全策略要在启动参数里关掉（如
--disable-web-security），测试环境注意 - 触摸驱动：大尺寸触摸屏在Chrome里通常走Touch Events，确保H5代码用了正确的事件监听（touchstart/touchend，而不只是mousedown/mouseup）
- 离线部署：把H5打包成本地文件或部署在局域网服务器（不依赖外网），展厅环境不能依赖互联网
一个典型的H5感应链路：
科星网络IO（传感器信号）→ Modbus TCP → 本地Python服务
Python服务 → WebSocket广播 → 全屏Chrome内的H5页面
H5页面收到消息 → 切换页面/播动效/显示内容
五、专用展厅内容软件：低代码方案
展厅行业有一批专用的内容制作/管理软件，面向非程序员的内容设计师，常见的有：
- SCALA：数字标牌内容管理，支持触摸互动
- Ventuz：节点式实时演示/展厅软件，适合销售展示
- Brightsign：数字标牌播控平台（更靠近播控方向）
- 各展厅系统商自带的配套内容编辑器
适合什么场景：
- 展项内容以展示/查询为主，不需要深度自研逻辑
- 甲方运营团队自己管内容、不想每次找开发团队改
- 项目周期短、预算有限，没有时间自研
不适合什么：需要特殊感应接入、复杂逻辑、深度定制效果——专用软件的灵活性是换来低代码的代价。
引擎对比表
| 维度 | Unity | UE | TouchDesigner | H5/Web | 专用软件 |
|---|---|---|---|---|---|
| 适用内容类型 | 3D互动、游戏化展项 | 高保真3D大场景 | 实时视觉装置、AV | 触摸查询、翻书、答题 | 展示查询、数字标牌 |
| 开发门槛 | 中（需Unity开发者） | 高（需UE工程师） | 中（需TD设计师） | 低~中（前端开发即可） | 低（配置化） |
| 硬件要求 | 中等（主流N卡） | 高（高端显卡） | 中（实时视觉压GPU） | 低（集显可跑） | 低 |
| 部署形式 | 打包.exe | 打包.exe | 运行.toe工程 | 浏览器/Electron | 自带运行环境 |
| 感应接入方式 | UDP/TCP/Socket代码 | UDP/TCP/蓝图插件 | 内置OSC/UDP/串口节点 | WebSocket/HTTP | 看软件支持情况 |
| 内容更新 | 重新打包 | 重新打包 | 修改.toe即时生效 | 改网页/刷新 | 配置界面更改 |
| 授权成本 | Unity个人/学生免费；商业版按营收阶梯 | 免费+5%营收分成；有企业协议 | 商业版按功能授权，参见官网 | 开源框架免费 | 软件采购费用 |
| 典型展厅案例 | 科技馆互动展柜、工厂数字孪生答题 | 汽车展厅高保真漫游、城市规划沙盘 | 沉浸式艺术装置、开幕互动秀 | 企业展厅查询墙、翻书展项 | 数字标牌、轮播展示 |
上面的授权成本以各官方网站当前政策为准，版本迭代快，写方案前先核对最新条款，不要用过时信息报给甲方。
互动素材制作的工程要点
选好引擎只是开始，素材做对才能跑起来。展厅互动内容常见的素材工程问题：
分辨率适配屏体
这是最常见的踩坑点。展厅屏幕不是消费级电视——常见非标规格有：
- 拼接屏（3×1竖排LED屏）：可能是 5760×1080、5760×2160 这类宽超高的分辨率
- 异形LED（圆弧屏、柱状屏）：分辨率和比例完全由屏体点距和形状决定
- 多屏输出：Unity/UE多显示器输出时，渲染目标分辨率=整块拼接面的总像素
在开始做内容之前，拿到屏体规格书。关键参数：总像素分辨率（宽×高）、像素密度（室内LED一般2~4mm点距）、屏体刷新率（一般≥60Hz，高刷屏120Hz）。
设计稿按总分辨率出，资源按2倍（或需求定）出，给到引擎里配置好摄像机/画布的输出分辨率，打包/运行时帧缓冲区要对齐实际分辨率——否则要么糊（分辨率低了被放大），要么偏移（分辨率不匹配屏体映射）。
触发逻辑设计
互动内容里要定义清楚每个"触发事件"和"响应"的对应关系：
- 触发输入：来自哪个信号（哪个感应区的DI变化、RFID的哪张卡ID、触摸屏的哪个区域点击）
- 触发条件：是"边沿触发"（状态改变那一刻触发）还是"电平持续"（信号一直为高时持续显示效果）
- 响应行为：切换到哪个场景/播哪段动画/修改哪个变量
- 复位条件：展项什么时候复位回初始状态（离开后N秒、内容播完后自动回、手动复位）
这套逻辑在内容开发前就要写成文档（哪怕是一张表），否则开发到一半发现"触发后不知道该播什么"是很常见的事。
一个触发逻辑表的例子：
| 触发事件 | 条件 | 响应 | 复位 |
|---|---|---|---|
| DI1=1（有人进入） | 持续≥2秒 | 播放介绍动画（序列A） | 动画播完自动待机 |
| 触摸屏点击"区块1" | 边沿触发 | 展开区块1详情 | 点击"返回"或30秒无操作 |
| RFID卡号=0x1A2B3C4D | 边沿触发 | 显示"张三"欢迎界面 | 10秒后自动返回 |
| DI1持续=0超过30秒 | 持续≥30秒 | 复位到待机画面 | — |
帧率要求
展厅互动内容的帧率需求按场景区分：
- 触摸查询/翻书：30fps 够用，稳定比高帧率更重要
- 3D互动/滑动动效：60fps，低于这个人眼会感到卡顿
- 体感骨架游戏/手势跟随：60fps+，延迟要低，否则"肢体和画面对不上"的感觉很明显
- LED大屏视觉装置：屏体刷新率通常≥60Hz，内容帧率也要≥60fps，否则出现撕裂感
帧率的真实问题：开发机器（高端游戏PC）跑60fps不代表部署工控机也能跑60fps。内容开发完之后，必须在目标工控机上实际测试帧率，不能只在开发机上验收。工控机一般用中端N卡（如RTX 3060或更低），对高多边形/高分辨率场景有明显上限。
内容与硬件感应的对接
内容引擎接收感应信号的方式，归根结底就两大类：
方式一：中控统一调度（推荐，工程级）
传感器 → 工业IO（科星）→ 中控（SoftControl）→ TCP/UDP 通知内容引擎
内容引擎开一个本地端口（如UDP 9001）监听，中控在触发条件满足时发一条消息（如 {"action":"trigger","zone":"A"}），引擎解析消息后执行对应逻辑。
优点：
- 中控统一管所有感应节点，排查问题有日志
- 内容引擎只需要关心"收到什么消息→做什么响应"，不需要直接处理传感器硬件
- 中控可以做防抖、延时、条件组合，内容侧不需要重复做这些
缺点：
- 链路多一层，需要中控和内容开发者之间对齐消息协议（写接口文档）
方式二：内容直连传感器/IO（适合原型或简单装置）
科星IO / Arduino → 直接接内容引擎（TouchDesigner UDP / Unity串口）
TD原生支持OSC/UDP直读，Unity可以用串口或Socket直接接。跳过中控的话，内容开发者自己处理防抖、延时等逻辑。
适合单点装置、TouchDesigner艺术装置、或者快速原型验证——不适合需要中控统一管理的大型展厅项目。
对接协议约定（必须在开发前确定）
无论哪种方式，内容开发开始前要和对接方（中控工程师或IO硬件工程师）书面确定：
- 通信方式：UDP单播？TCP长连接？WebSocket？OSC？
- 地址和端口：IP地址+端口，两端一致
- 消息格式：JSON？固定长度字节？纯文本？（推荐JSON，可读性好）
- 消息内容字段定义：如
{"event":"zone_enter","zone_id":1,"timestamp":1234567890} - 心跳机制：是否需要定时心跳包确认连接在线
- 断线处理：连接断开后内容侧怎么处理（保持当前状态？返回待机画面？）
把这6条写进一个"接口约定文档"（哪怕是一张A4纸），内容开发、中控配置、现场调试三方各存一份。项目延期70%的时间花在"你说发的是这个，他以为接的是那个"上面。
外包互动内容时怎么提需求
外包内容开发时，"做出来用不了"几乎都源于需求文档不清楚。需求文档里要说清楚的事情：
必须写的技术规格
运行硬件规格：操作系统（Win10/11）、CPU（品牌型号）、显卡（型号）、内存（GB）。直接把工控机规格单附上去，让外包方自己确认能不能跑。
屏体规格：分辨率（宽×高）、排列方式（横屏/竖屏/拼接）、刷新率。
感应信号接入方式："我们会从中控发UDP，格式如下……"或者"从WorkBase给WebSocket推消息，JSON格式……"。写清楚协议和消息格式，不能只写"支持传感器接入"。
部署方式：打包exe开机自启？还是作为浏览器H5运行？工程文件是否需要交付（源码还是只交付打包件）？
内容维护方式：谁来改内容？运营人员能操作吗？需不需要后台管理界面？
帧率要求：标注目标帧率（如"60fps稳定，不低于55fps"）。
开机自启和看门狗：展厅程序通常要求开机自动启动、程序崩溃后自动重启。是外包方负责实现，还是业主方自行配置？说清楚。
常见坑（在需求文档里堵死）
- "感应方式后面再定"：外包方会按最简单的方案设计（鼠标点击模拟），最后接真实传感器时大改。需求书里写死接入方式。
- "展示效果参考某竞品"：参考可以，但要标注"参考视觉风格"还是"参考功能逻辑"。功能逻辑抄竞品可能涉及知识产权，也可能那个功能在当前硬件上实现不了。
- 不说屏体分辨率：外包方按1920×1080开发，最后屏体是5760×1080，内容全部要重排。
- 没写开机自启：测试机上手动跑没问题，展厅断电重启后什么都不动。
学会之后你能做出什么——效果与应用场景
这一节不是教你写 Unity 代码，也不是教你调 TouchDesigner 节点——那是内容方的活。它给你的是站在集成方角度做决策的能力：一个展项摆在面前，你能立刻判断"这内容该用哪条引擎路线做、外包时该怎么写需求、素材交付要卡哪些硬指标"。这三件事做对了，内容方交来的东西才跑得起来、接得进你的中控。
拿到一个互动展项，你现在能替甲方/内容方拍板"用什么做"：
| 展项是这样的 | 你该往哪条引擎路线引 | 为什么 |
|---|---|---|
| 展品要 3D 旋转、拆解、缩放，还带答题小游戏 | Unity | 通用、感应接入灵活、工控机主流 N 卡就能跑 |
| 城市规划大沙盘漫游、汽车高保真展厅、要"电影级"画质 | UE | 光影材质碾压级，但要配高端显卡+够长周期+够贵预算 |
| 粒子跟着声音/雷达数据跳、开幕式 VJ 秀、沉浸式声光装置 | TouchDesigner | 感应→实时视觉最快，CHOP 直读传感器；但要有 TD 人、买商业授权 |
| 触摸查询墙、互动翻书、答题、内容天天要改 | H5/Web | 改网页比重新打包快，WebSocket 接感应，集显都能跑 |
| 内容就是展示/轮播/数字标牌，运营想自己改、没预算自研 | 专用软件（SCALA/Ventuz 等） | 低代码换来快和省，代价是深度定制做不了 |
看懂这张表你就避开了最贵的两个坑：一是拿 UE 去做本该 H5 干的活（预算工期全烧在渲染上，工控机还跑不动，交付现场翻车）；二是用了 TouchDesigner 却没人会维护、没买商业授权，展厅开馆当天才发现分辨率被锁在 1280×1080。选型这一步选错，后面再努力都是补窟窿。
跟内容方对接，你现在拿得出硬约束：
- 素材规格卡死：开工前把屏体规格书甩过去——总分辨率（如 5760×1080）、点距、刷新率，别让对方按 1920×1080 埋头做完再全部返工。
- 触发逻辑先给表：哪个 DI/RFID/触摸区触发、边沿还是电平、播什么、多久复位，一张表写清，内容方不会"做到一半不知道触发后播啥"。
- 接口协议先签字：UDP 还是 WebSocket、IP 端口、JSON 字段、断线怎么办，六条写进一张 A4 纸，三方各存一份——项目 70% 的扯皮就死在"你说发这个、他以为收那个"。
- 帧率写进验收标准：60fps 稳定、不低于 55，而且必须在目标工控机上实测，不认开发机上的漂亮数字。
这套判断力用在哪些场景：
- 企业展厅 / 科技馆：一进门的互动展柜、答题触摸屏、体感游戏，你能一眼分出该走 Unity 还是 H5，报价和工期就不会拍脑袋。
- 城市规划馆 / 数字孪生：大场景漫游、沙盘联动，你知道什么时候值得上 UE、什么时候 Unity 够用，不被内容方"必须 UE 才高级"忽悠。
- 沉浸式数字展 / 艺术装置：声光粒子跟数据跳的，你会主动把它引到 TouchDesigner，而不是硬用 Unity 慢慢憋。
- 多点位查询终端：几十台查询机统一管内容，你知道 H5 部局域网服务器 + Kiosk 模式是最省心的路。
迁移价值：这套"按项目选引擎 + 卡素材规格 + 定接口协议"的功夫，不只用在展厅。零售快闪的互动屏、发布会的实时视觉、商场中庭的数字装置，底层决策逻辑一模一样——先看内容要什么、再看谁来做、最后卡死交付标准。你在展厅练出来的这套对接内容方的方法，换个行业照样管用。
动手挑战
- 找一个你参与过或看过的互动展项，判断它用的是哪种内容引擎（不一定能100%确认，根据表现特征猜测并说出理由）。如果换一个引擎做，会有什么不同？
- 设计一个"3个展区、每区一个触摸查询屏+一个PIR触发投影"的触发逻辑表，把所有触发事件、条件、响应、复位都列出来——这就是你给内容开发团队的交互设计文档。
本节学到的知识
- 展厅互动内容就五条主线：Unity、UE、TouchDesigner、H5/Web、专用软件；没有绝对更好，选哪条看预算、复杂度、更新频率、团队技术栈。
- Unity 是最通用的展厅平台：3D 交互/游戏化/独立跑工控机都行，感应走 UDP/TCP/WebSocket/串口；多屏拼接要在代码里配
Display.displays，渲染分辨率是整块拼接面的总像素不是单屏。 - UE 拼的是高保真大场景（Nanite/Lumen），代价是学习曲线陡、显卡要求高、周期长；Pixel Streaming 多半是坑——引入网络延迟和运维复杂度，展厅一般还是走本地打包。
- TouchDesigner 是节点式实时视觉工具不是"引擎"，原生支持 OSC/MIDI/DMX/串口/UDP，感应→视觉最快；但要装 TD 本体、非商业版分辨率上限 1280×1080，正式展厅得买商业授权。
- H5/Web 胜在轻量易维护：全屏 Chrome 走 Kiosk Mode（
--kiosk），感应对接最常用 WebSocket，触摸要用 Touch Events（touchstart/touchend），必须离线部署不依赖外网。 - 专用软件（SCALA/Ventuz/Brightsign）是低代码路线：展示查询够用、运营能自己改，但特殊感应和深度定制做不了。
- 素材第一坑是分辨率适配屏体：展厅屏是非标（拼接屏 5760×1080、异形 LED），开工前先要屏体规格书，按总分辨率出设计稿，否则不是糊就是偏。
- 触发逻辑开发前就得写成表：明确触发输入、边沿还是电平、响应行为、复位条件四要素，否则"触发后不知道播什么"。
- 帧率按场景分：触摸查询 30fps 够、3D 互动 60fps、体感手势 60fps+ 且低延迟、LED 大屏 ≥60fps 防撕裂；必须在目标工控机（中端 N 卡）上实测，别信开发机数字。
- 感应对接两条路：中控统一调度（工程级、有日志、能做防抖）vs 内容直连 IO（适合原型/单点/TD 装置）；无论哪条，通信方式/IP 端口/消息格式/字段/心跳/断线处理六项开发前书面签死。
- 外包需求文档必写：运行硬件规格、屏体规格、感应接入协议、部署方式、维护方式、帧率、开机自启+看门狗；把"感应后面再定/参考某竞品/不写分辨率/不写自启"这几个坑在文档里堵死。
小结 · 你掌握了什么
- 你理清了展厅互动内容的五条技术路线：Unity（通用3D）、UE（高保真大场景）、TouchDesigner（实时视觉装置）、H5/Web（轻量触摸查询）、专用软件（低代码展示）；知道各自适合什么场景、有什么限制。
- 你掌握了互动素材制作的三个工程要点：分辨率先拿屏体规格书、触发逻辑要在开发前书面定义、帧率要在目标工控机上实测——不是在开发机上验收。
- 你了解了内容与硬件感应的两种对接方式（中控统一调度 vs 直连），以及6条必须在开发前约定的接口规格。
- 你有了一套"外包需求文档必写项"，能在合同阶段就把"做出来用不了"的风险堵住。
下一步：把感应信号和内容引擎真正用工控机/工业IO串起来——看软硬结合：工控机+传感器+内容引擎搭一个互动装置。