简介：这是一份面向互动投影项目开发者与效果测试人员的Unity3D捕鱼案例，聚焦激光雷达互动投影场景的演示与功能验证。案例以清晰美观的画面呈现捕鱼互动效果，可用于投影硬件联调、互动反馈观察、现场演示方案评估，也适合作为Unity3D互动投影雷达技术的学习参照。压缩包约26.64MB，文件总数与类型明细上游暂未提供，包体轻量，便于快速导入测试环境。已有1742人浏览学习，说明该案例在互动投影捕鱼方向具有一定关注度。读者可从中获得可测试的案例场景与完整视觉呈现，用于比对捕鱼交互的呈现方式、画面组织与投影适配效果，也可作为项目立项、方案汇报和功能测试的参考样本；对需要快速验证激光雷达互动投影效果、减少从零搭建演示场景成本的开发者较为实用。

1. 需求先立住：互动投影捕鱼真正要解决的是"人对得上鱼"，不是"鱼好看"

互动投影捕鱼这类项目，绝大多数失败的原因不是美术资源不够漂亮，而是人踩进投影区、手挥过去，鱼没有反应，或者鱼的反应位置和人差半米。用户要的是踩水花、赶鱼群、抓大鱼这种即时反馈，一旦延迟超过 150 毫秒或者坐标偏了，体验立刻崩塌。这套 Unity3D 互动投影捕鱼案例要解决的，就是激光雷达感知、坐标映射、Unity3D 实时渲染三件事的闭环：雷达负责"看见人"，算法负责"算准位置"，Unity3D 负责"给出反馈"。适合做数字展厅、科技馆互动地面、商业中庭暖场装置的团队，也适合拿它当毕设或课设里"多传感器+实时渲染"方向的完整参考。

2. 总体架构设计：雷达、投影机、渲染主机与标定四层职责划分

先把链路拆清楚，后面写代码才不会乱。这套系统在物理上只有四类设备，但在软件上要跑四条独立的数据流水线，任何一条堵住，表现出来都是"鱼不跟手"。

2.1 硬件链路：谁装在哪、谁连谁

互动投影捕鱼的安装形态通常是地面投影或墙面投影。地面投影更容易做出"踩水"的沉浸感，也是这个案例采用的主形态：投影机吊装在天花板正投或偏轴短焦投射，雷达固定在投影区边缘的立杆或横杆上，扫描平面平行于地面，高度一般取离地 40～60 厘米。

这个高度不是随便定的。太低，地面的接缝、地毯绒毛、散落的杂物都会被扫进来，点云里全是噪声；太高，成年人能扫到腰，一米二以下的小孩直接漏检。40～60 厘米刚好切过成人的小腿和儿童的大腿，是两种身高都能稳定命中的区间，属于踩过坑之后才会固定下来的经验值。

投影机亮度这一项容易被低估。地面投影的有效亮度会被环境光吃掉一大截，展厅白天开灯的情况下，3000 流明投 3 米宽的画面基本看不清鱼的颜色，通常要 5000 流明起步，并且尽量做遮光。这不是画质问题，是"看不见鱼就等于没做"的问题。

2.2 软件分层：从扫描帧到画面刷新的四条流水线

软件上我一般切成四层，层与层之间只走一种数据结构，避免逻辑代码里到处出现"从哪个雷达来的""原始距离是多少"这种细节。

• 采集层：一个独立的后台线程负责 UDP 收包，只做"拆包入队"，不做任何解析。雷达的扫描帧是持续推过来的，15 Hz、每帧几百个点，如果在 Unity 的Update里同步Receive，只要丢一帧就会卡住渲染。
• 坐标层：把点云从极坐标转成直角坐标，做距离过滤、聚类、多目标跟踪，再用单应矩阵把雷达坐标映射成投影画面的归一化坐标。这一层是整套系统的精度来源，也是调参花时间最多的地方。
• 逻辑层：只认"当前有哪些触摸点、每个点的位置和速度是多少"，据此驱动鱼群的游动、躲避、被捕获、计分。逻辑层完全不知道下面是雷达还是触摸屏，这样后面换硬件不用改业务代码。
• 表现层：渲染、水波、粒子、音效、UI 计分板。这一层只消费逻辑层的事件，不参与判定。

分层的价值在联调时最明显。现场出问题，先看采集层有没有包、再看坐标层光点动不动、最后才怀疑逻辑层。三层逐级排查，比在几百行Update里猜要快得多。

3. 雷达数据处理：从点云到投影坐标的完整映射

这一章是整套方案的核心。雷达给出的是"角度 + 距离"，投影机需要的是"画面上的 x、y 像素"，中间隔着坐标系、安装偏差、镜头畸变三层误差，任何一层没处理好，画面上的光点就会和人差半米。

3.1 安装高度与扫描平面的确定

单台雷达的覆盖是扇形，270° 扫描角在 5 米距离上能覆盖十几米的弧长，看起来够用，但实际有效区域是扇形的内圈。斜射到远处的点，角度误差被距离放大，落点会明显偏移。我的做法是把雷达装在投影区的一条边上，让它"正对"投影区，只取正前方 ±60° 的范围参与计算，边缘角度直接丢弃。

多台雷达拼接时，先各算各的，再到坐标层统一。每台雷达在安装位置用一个刚体变换（绕 Z 轴旋转 θ + 平移 tx、ty）映射到统一的"场地坐标系"，场地坐标系的原点定在投影区的左下角，x 轴沿投影区长边，y 轴沿短边。这几个参数现场量一次、写进配置，不要指望在代码里手调。

提示：立杆一定要做防晃。雷达支架被碰歪 2°，在 5 米处就是十几厘米的偏差，表现出来就是"人站着不动，光点在慢慢漂"。支架底部加配重、杆身加斜撑，比事后写补偿算法管用。

3.2 点云过滤、聚类与多目标跟踪

原始点云里什么都有：地面反光、观众手里的包、投影幕布的褶皱。处理顺序是「先砍距离，再聚类，再跟踪」。

# 单帧雷达数据解析：极坐标 -> 直角坐标 # 仅示意帧结构，实际协议以设备手册为准 import math def parse_frame(packet: bytes, angle_step=0.5, max_range_mm=6000): start_angle = int.from_bytes(packet[4:6], 'little') / 100.0 # 起始角，单位 0.01° payload = packet[6:-2] # 去掉帧头与校验位 points = [] for i in range(0, len(payload) - 1, 2): dist = int.from_bytes(payload[i:i + 2], 'little') # 距离，单位 mm if dist <= 100 or dist > max_range_mm: # 贴脸噪点与超量程一并丢弃 continue ang = math.radians(start_angle + (i // 2) * angle_step) points.append((dist * math.cos(ang) / 1000.0, dist * math.sin(ang) / 1000.0)) return points

距离下限 100 毫米是为了滤掉雷达窗口前的灰尘和飞虫，上限 6 米是按投影区对角线给的，超出的点即使是真的也没意义，反而增加聚类负担。

聚类用最朴素的一维相邻点聚类就够了：按角度排序后，相邻两点距离小于阈值就归为一类。阈值取 120 毫米左右，小于成年人两条腿之间的间距，又大于同一个人腿部点云的正常抖动。

def cluster(points, gap=0.12, min_points=3): """相邻点距离小于 gap 归为一簇；少于 min_points 视为噪声""" if not points: return [] pts = sorted(points, key=lambda p: math.atan2(p[1], p[0])) groups, cur = [], [pts[0]] for p in pts[1:]: if math.dist(p, cur[-1]) < gap: cur.append(p) else: groups.append(cur); cur = [p] groups.append(cur) result = [] for g in groups: if len(g) < min_points: continue cx = sum(p[0] for p in g) / len(g) cy = sum(p[1] for p in g) / len(g) result.append((cx, cy)) return result

单帧聚类只能给出"这一瞬间有几个人"，帧与帧之间还得接上，否则同一个人的 ID 每帧都在变，逻辑层就没法算速度。跟踪用最近邻匹配加指数平滑：对上一帧的每个目标，在本帧中找距离最近且小于 0.6 米的簇，匹配上就沿用 ID，并用new = 0.7 * old + 0.3 * measured做平滑；连续 5 帧匹配不上就销毁该 ID。这套逻辑比卡尔曼滤波简单，但在这个场景下足够稳，代码量还少一半。

平滑系数 0.3 是折中值。调大跟手但抖动，调小平滑但拖影。如果在现场看到光点"粘手"，先把系数往上调到 0.5 试，通常就顺了。

3.3 单应变换：把雷达坐标落到投影画面

雷达坐标系是米，画面坐标是像素，中间是一个透视变换。不要用简单的线性缩放，因为投影机偏轴安装时，画面近端和远端的比例不一样，线性缩放会在远端越偏越多。

正确做法是四点单应。在投影区地面上贴四个标记点（四角或内缩 30 厘米的位置），量出它们在雷达坐标系下的坐标，同时记下它们在投影画面里的归一化坐标，用 OpenCV 离线解一次矩阵，把 9 个数字写进 Unity 的配置文件。

# 离线标定：求单应矩阵，输出 9 个数给 Unity 用 import numpy as np, cv2 radar_corners = np.float32([[0.0, 0.0], [6.0, 0.0], [6.0, 4.0], [0.0, 4.0]]) # 米 screen_corners = np.float32([[0.0, 0.0], [1.0, 0.0], [1.0, 1.0], [0.0, 1.0]]) # 归一化 H, _ = cv2.findHomography(radar_corners, screen_corners, 0) print(H.flatten().tolist())

Unity 侧只需要做一次矩阵乘法，把归一化坐标再乘上渲染目标的分辨率即可：

// 单应变换：雷达坐标(米) -> 画面归一化坐标(0~1) // h 的 9 个分量按行存入 Matrix4x4 的 m00,m01,m03 / m10,m11,m13 / m20,m21,m23 public static Vector2 ApplyHomography(Matrix4x4 h, Vector2 p) { float x = h.m00 * p.x + h.m01 * p.y + h.m03; float y = h.m10 * p.x + h.m11 * p.y + h.m13; float w = h.m20 * p.x + h.m21 * p.y + h.m23; return new Vector2(x / w, y / w); // 齐次坐标归一化 }

投影机做过梯形校正之后，画面还会有轻微的非线性弯曲，四点单应在边缘可能仍有 3～5 厘米误差。要更准的话，用 4×4 的九宫格标定点做双线性插值补偿：先按单应算出大致位置，再找它所在的小格，用四角残差做插值修正。除非投影距离特别短或者偏轴角度特别大，一般四点单应已经够用。

4. Unity3D 互动逻辑实现：鱼群行为、命中判定与视觉反馈

坐标层算出的是"人在画面上的哪儿"，逻辑层要把它变成"鱼怎么跑、抓没抓到、加分还是不加分"。这一层的设计目标是：换一套美术资源，逻辑代码一行不用改。

4.1 输入抽象层：把雷达目标变成可用的触摸点

先定义一个和硬件无关的输入结构，雷达、触摸屏、鼠标调试全部转成它。这样在办公室没接雷达的时候，用鼠标也能把玩法调到能看。

public struct TouchPoint { public int Id; // 跟踪 ID，同一个人在整个过程中保持不变 public Vector2 Pos; // 画面归一化坐标 0~1 public Vector2 Velocity; // 米/秒，用于判断"快速挥手" public float Radius; // 目标点云宽度估计，用于区分大人与小孩 }

Radius这个字段看着可有可无，实际很有用。成年人的点云宽度大约 0.4～0.6 米，儿童在 0.25 米左右，用它可以把鱼的躲避半径做成动态的：大人靠近时鱼跑得早，小孩靠近时鱼反应慢一点，让小朋友也能抓到。这是提升体验最便宜的一招。

收包线程与主线程的交接必须干净，不能让渲染等网络：

// 后台线程收包，主线程消费；Update 里绝不做阻塞式 Receive using System.Collections.Concurrent; using System.Net; using System.Net.Sockets; using System.Threading; public class LidarReceiver : MonoBehaviour { public int listenPort = 8100; private UdpClient _client; private Thread _thread; private readonly ConcurrentQueue<byte[]> _frames = new ConcurrentQueue<byte[]>(); private volatile bool _running; void Start() { _client = new UdpClient(listenPort); _running = true; _thread = new Thread(Loop) { IsBackground = true }; _thread.Start(); } private void Loop() { var ep = new IPEndPoint(IPAddress.Any, 0); while (_running) { try { _frames.Enqueue(_client.Receive(ref ep)); } catch (SocketException) { break; } // 关闭 socket 时抛异常属正常退出路径 } } void Update() { int budget = 4; // 每帧最多处理 4 帧，防止积压导致卡顿 while (budget-- > 0 && _frames.TryDequeue(out var raw)) TargetRegistry.Instance.PushFrame(raw); } void OnDestroy() { _running = false; _client?.Close(); _thread?.Join(200); } }

每帧处理帧数设上限这一条，是我在被"积压帧拖垮帧率"坑过之后加的。雷达 15 Hz、渲染 60 Hz，正常情况下不会积压；但一旦主线程卡了 2 秒，队列里就会堆 30 帧，恢复的瞬间全部灌进逻辑层，直接再卡一次，形成雪崩。加上budget之后，旧的帧被自然丢弃，画面只会"跳一下"，不会崩。

4.2 鱼群的对象池与状态机

鱼的数量一般按投影面积算，每平方米 3～5 条，20 平方米的地面就是 60～100 条。这个量级用Instantiate/Destroy会持续产生 GC，表现为每隔十几秒卡一下，非常明显。必须用对象池。

鱼的行为用一个四状态机就够了：巡游、躲避、被捕获、回池。

public enum FishState { Swim, Flee, Caught } public class Fish : MonoBehaviour { public FishState State = FishState.Swim; private Vector2 _target; private float _speed = 1.2f; // 米/秒，比人走路略快 public void Tick(float dt, IReadOnlyList<TouchPoint> touches, Rect pond) { Vector2 pos = new Vector2(transform.position.x, transform.position.z); foreach (var t in touches) { float safe = 0.35f + t.Radius; // 躲避半径随目标体型变化 if (Vector2.Distance(pos, t.Pos) < safe) { State = FishState.Flee; _target = pos + (pos - t.Pos).normalized * 3f; break; } } if (State == FishState.Flee && Vector2.Distance(pos, _target) < 0.1f) State = FishState.Swim; if (State == FishState.Swim && Vector2.Distance(pos, _target) < 0.1f) _target = new Vector2(Random.Range(pond.xMin, pond.xMax), Random.Range(pond.yMin, pond.yMax)); Vector2 dir = (_target - pos).normalized; transform.position += new Vector3(dir.x, 0, dir.y) * _speed * dt; transform.rotation = Quaternion.LookRotation(new Vector3(dir.x, 0, dir.y)); } }

_speed定在 1.2 米/秒是有讲究的。人的步行速度约 1.0～1.4 米/秒，鱼比人略快，人追不上但差距不大，才有"差一点就抓到"的手感。调成 2 米/秒，鱼永远抓不到，观众三秒就放弃；调成 0.8 米/秒，一抓一个准，也没有乐趣。

4.3 命中判定、计分与视觉反馈

判定逻辑放在鱼自己身上还是放在管理器上，取决于要不要做"连击"。我的做法是管理器每帧拿所有触摸点对所有鱼做一次距离检测，命中就发一个OnFishCaught事件，鱼的动画、粒子、音效、计分都订阅这个事件。这样加新的反馈（比如震动、灯光联动）不用动判定代码。

命中半径不要用鱼的碰撞体。鱼是 2D 贴图，碰撞体要么太大要么太小，直接用一个可配的圆形半径（通常 0.25～0.35 米）更可控，也方便按投影面积换算。

反馈的层级按重要性排：水花粒子最重要，它是"抓到了"的第一信号；鱼的下潜动画次之；音效第三；计分数字最末。现场噪声大，音效经常听不见，所以不能把"抓到了"的反馈只押在声音上。粒子发射器的位置要跟着命中点走，不能固定挂在鱼身上，否则鱼跑远了水花还在原地。

5. 现场避坑与常见问题排查：五个最容易翻车的点

调试间里跑得好好的，搬到现场就出问题，这是互动投影项目的常态。下面这五条是按"现象→原因→解决"整理的，基本覆盖了现场八成以上的故障。

5.1 安装与标定类问题

光点与人的位置整体偏移，越靠边偏得越多。现象是人在中间站着还行，走到角落就偏出半个身位。原因是只做了两点标定或者直接线性缩放，没有处理透视关系。解决是按 3.3 节的四点单应重做一遍，并且四个标定点要尽量拉开、贴在地面实测，不能拿卷尺量个大概就填进去。边缘误差仍然大的话，再上九宫格插值补偿。

人站着不动，光点自己缓慢漂移。现象是静止的人对应的光点在画面上画小圈。原因是雷达支架刚性不足，或者投影机被碰过、梯形校正参数变了。先在支架底部加配重和斜撑，然后每天开场前用标定工具跑一遍四点复标，两次结果的差值超过 5 厘米就重新调支架。标定这件事没有一劳永逸。

5.2 数据与算法类问题

两个人靠近就只剩一个光点。现象是单独走都正常，两人并肩或者交叉时目标合并成一个。原因是聚类间距阈值按单人调的，两人腿部点云间隙小于阈值就被并成了一簇。解决是把阈值按距离分层：近处（3 米内）用 0.10 米，远处用 0.16 米，因为远处角分辨率对应的实际间距更大。再不行就上按距离分段的自适应阈值。

小孩完全检测不到。现象是成年人进去有反应，一米二以下的孩子踩上去毫无反应。原因是扫描平面高度是按成人调的，小孩身高不够，平面从头顶扫过去了。解决是把雷达安装高度降到 40 厘米左右，或者用两台雷达做上下双平面，取并集。降高度会带进更多地面噪声，所以距离下限要同步收紧。

5.3 运行时与交付类问题

连续跑两三个小时，帧率从 60 掉到 30。现象是刚开场流畅，越到后面越卡，重启就好。原因是特效对象没有回收、每帧new出临时 Vector2、贴图没有压缩，导致托管堆持续增长和 GC 抖动。解决是用 Profiler 抓 5 分钟看内存曲线，确认是托管堆在涨就上对象池，把每帧的临时分配清掉；纹理统一改成压缩格式，粒子系统的Max Particles设上限而不是无限。这类问题在调试间跑十分钟是发现不了的，必须做烤机测试。

断网或者雷达重启后，画面再也不动了。现象是拔一下网线再插回去，程序就再也收不到数据。原因是 socket 异常后没有重建，线程已经退出了。解决是在收包循环外层加一个重连逻辑，捕获异常后 sleep 1 秒重新创建UdpClient，并且把"最近一次收包时间"打到屏幕上，超过 2 秒没数据就显示红色告警。现场运维的人不需要看日志，看颜色就知道是不是雷达掉了。

6. 验收与答辩：用一套可复现的演示脚本证明方案跑得通

这套东西最怕的情况是：演示的时候恰好正常，评委一问"多人怎么办""跑久了会不会卡"就答不上来。所以验收不能靠"看一遍觉得还行"，要有一张可以逐项打勾的表，并且每一项都能当场复现。

答辩时的讲解顺序，我建议按"一条数据怎么走完全程"来讲，而不是按模块罗列。从雷达发出一帧扫描数据开始，讲它怎么被解析成点、怎么聚成目标、怎么经过单应矩阵落到画面上、怎么驱动一条鱼逃跑、怎么触发水花和计分，一条线讲完，评委自然就明白你的架构为什么这么分。中途被打断提问也不要紧，因为任何一环你都能单独拎出来讲。

有一个容易被忽略的加分点：主动说明精度和延迟是怎么测的。很多人只报"延迟很低"，但说不出怎么量的。你能说清"用 240 帧录像数帧、扣掉投影机本身的 16 毫秒刷新"，这个方案的可信度立刻不一样。

从那以后我每次进场做这类装置，都强制自己走一遍流程：四点复标、4 小时烤机、拔网线测试，一项不落。血泪经验是，省掉的每一项，都会在开幕当天以另一种方式找回来。希望帮到你。

本文还有配套的精品资源，点击获取