简介：一套围绕OpenCV、Python、Mediapipe与Unity3D构建的计算机视觉动作捕捉实践资料，面向希望掌握人体姿态估计、多关节运动跟踪以及三维模型驱动的开发者或学习者。压缩包内共10个文件，整体约15.47MB，主要包含Python编写的摄像头视频采集与姿态检测程序、Unity3D端C#脚本、txt与md格式的配置说明、PDF附赠资料以及mp4效果演示视频，覆盖从视频采集、关键点识别、实时数据传输到三维骨骼驱动的完整链路。目前已有190人学习下载，适合计算机视觉、虚拟现实或游戏开发方向的项目参考。具体来说，Python程序会调用摄像头读取实时画面，基于深度学习模型估计人体关节位置；C#脚本在Unity3D中接收数据并映射到三维角色；说明文档整理了环境配置、运行流程与常见错误，演示视频则能直观看到动作捕捉与模型驱动效果，便于读者对照复现并继续扩展。
1. 一套能跑起来的实时动捕链路：从摄像头到 Unity3D 驱动模型
拿到这份「计算机视觉与动作捕捉」资源的时候，我先确认了一件事：它不是一篇论文或者一套 PPT，而是一条从摄像头采集视频、Python 端做姿态估计、再把 33 个关节坐标实时扔给 Unity3D 驱动三维模型的完整链路。基于深度学习的 Mediapipe 负责人体姿态估计和多关节运动跟踪，OpenCV 负责采集视频帧，Socket 负责实时数据传输，Unity3D 负责最后的三维模型驱动。适合谁？给毕设加实机演示的人、想做虚拟角色动作原型的人、以及第一次接触姿态估计和跨进程通信的开发者。下面按我复现时的顺序拆，每一步都能单独验证。
2. 环境搭建与整体架构：先把数据流的分工想清楚
拆这套资源时我习惯先不看代码，而是先确认数据流：摄像头画面在 Python 端被 OpenCV 读进来，交给 Mediapipe 做姿态估计，得到 33 个关节点的归一化坐标，再通过 Socket 实时传输到 Unity3D，由 C# 脚本解析后驱动三维模型。这一节把链路拆成四层，每一层能单独验证，后面出问题才知道该查哪一段。
2.1 链路设计：采集、估计、传输、驱动四层
| 层 | 运行端 | 职责 | 关键组件 |
|---|---|---|---|
| 采集 | Python | VideoCapture 读帧、镜像、设分辨率 | OpenCV |
| 估计 | Python | 输出 33 个关节点的 x/y/z/置信度 | Mediapipe Pose |
| 传输 | Python → Unity3D | 序列化、UDP 发送与接收 | socket / UdpClient |
| 驱动 | Unity3D | 解析、坐标转换、骨骼映射、插值平滑 | C# 脚本 + Transform |
四层之间只通过「关节坐标数组」这个协议通信，所以每层都能单独调试：采集层看 imshow 出不出画面，估计层看画出来的关键点准不准，传输层用抓包工具或者直接在两端打印端口收发情况，驱动层先喂一组假数据看模型动不动。这套资源把 Python 端和 Unity3D 端分成了两个工程，就是这个用意。我一般先把采集和估计跑通，再开传输，最后才碰模型，避免一次引入太多变量。
2.2 环境准备：Python 版本与三个关键包
Mediapipe 对 Python 版本比较挑剔，这是第一个容易翻车的地方。我用的组合是 Python 3.8~3.10 配 OpenCV 4.x 和 Mediapipe 0.10.x，这套组合在 Windows 和 Linux 上都稳定。安装用一条命令解决：
python -m pip install opencv-python mediapipe numpy装完先跑一段版本验证，确认三个库都正常导入，再去动摄像头：
import sys print(sys.version) import cv2 print("OpenCV:", cv2.__version__) import mediapipe as mp print("Mediapipe:", mp.__version__)注意：
import mediapipe报TypeError或 protobuf 相关错误时，常见做法是降级 protobuf：python -m pip install protobuf==3.20.3。这类冲突在旧版本 Mediapipe 上出现概率很高，属于必踩项。
Unity 端我用的 2021.3 LTS，脚本后端选 .NET 4.x，C# 代码用 Visual Studio Code 或者 Rider 都行。这里有个容易忽略的点：Unity 工程里如果用了System.Net.Sockets，需要在 Player Settings 的 Api Compatibility Level 里确认是 .NET Standard 2.1 还是 4.x，后者对UdpClient支持更完整。
2.3 摄像头采集最小验证：OpenCV 打开与镜像
先不接 Mediapipe，只验证摄像头。这段代码解决两个后续问题：一是 Windows 下打开摄像头可能黑屏，二是动作画面和坐标方向的对应关系。
import cv2 cap = cv2.VideoCapture(0, cv2.CAP_DSHOW) # Windows 下推荐 DSHOW 后端 if not cap.isOpened(): cap = cv2.VideoCapture(1, cv2.CAP_DSHOW) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) while True: ok, frame = cap.read() if not ok: break frame = cv2.flip(frame, 1) # 镜像，动作对照不别扭 cv2.imshow("capture", frame) if cv2.waitKey(1) & 0xFF == 27: break cap.release() cv2.destroyAllWindows()VideoCapture(0)的 0 是摄像头索引，笔记本内置摄像头通常是 0，外接 USB 摄像头可能是 1，两个都不行就换成 -1 让系统自动挑。CAP_DSHOW是 Windows 下的 DirectShow 后端，能绕开很多默认后端打不开摄像头的问题，但它在部分机器上会强制 640x480，所以后面统一用set指定宽高。flip(frame, 1)做水平镜像，因为摄像头拍出来的是反的，这一步不做，后面手势对照会很难受。到这里如果画面稳定在 30 帧左右，采集层就算通了，接下来进姿态估计。
3. Mediapipe 人体姿态估计：33 个关键点的提取与参数调优
这一章是整条链路的算法核心。Mediapipe 的 Pose 模型基于深度学习的 BlazePose 拓扑，对使用者来说是个黑匣子，我们只需要调它暴露出来的参数，拿到 33 个关节点的坐标。但参数怎么调，直接影响后续 Unity3D 端的驱动效果，所以我把选型和调参单独拎出来讲。
3.1 模型选型：为什么 Mediapipe Pose 够用
做人体姿态估计，常见的候选有 OpenPose、PoseNet、Mediapipe 三种。OpenPose 精度高，但依赖 Caffe 和 GPU 环境，安装部署重，CPU 上跑不到实时；PoseNet 偏移动端，关键点只有 17 个，缺脚部信息；Mediapipe 是两者的平衡点：pip 一键安装、CPU 上能跑 30 帧、自带 33 个关键点，包含左右手、脚踝甚至脚跟。对「摄像头采集 → 姿态估计 → 三维模型驱动」这个场景，33 个点已经超过驱动一个人形模型所需的最少关节数，这也是这套资源选它的原因。
这里插一句：这类基于深度学习的模型，和传统机器学习手工提特征做关键点检测的路子完全不同，不需要我们自己去算 HOG 或者光流，训练和推理都封装在包里。代价是可控参数只剩置信度和模型复杂度，所以调参阶段难免有点玄学，后面 3.3 会把常用参数的实际效果讲清楚。
| 方案 | 关键点数 | CPU 实时 | 安装成本 | 适用场景 |
|---|---|---|---|---|
| OpenPose | 18/135 | 难 | 高（Caffe/GPU） | 学术研究、多人姿态 |
| PoseNet | 17 | 中 | 中 | 移动端轻量需求 |
| Mediapipe | 33 | 好 | 低（pip） | 实时驱动、原型开发 |
3.2 姿态估计核心代码：从 BGR 帧到 landmark 坐标
import cv2 import mediapipe as mp mp_drawing = mp.solutions.drawing_utils mp_drawing_styles = mp.solutions.drawing_styles mp_pose = mp.solutions.pose cap = cv2.VideoCapture(0, cv2.CAP_DSHOW) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) pose = mp_pose.Pose( static_image_mode=False, model_complexity=1, smooth_landmarks=True, min_detection_confidence=0.5, min_tracking_confidence=0.5, ) while cap.isOpened(): ok, frame = cap.read() if not ok: break frame = cv2.flip(frame, 1) rgb = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) results = pose.process(rgb) if results.pose_landmarks: h, w, _ = frame.shape lm = results.pose_landmarks.landmark # 以左肩 11、右肩 12 为例，归一化坐标转像素坐标 for idx in (11, 12): x_px = int(lm[idx].x * w) y_px = int(lm[idx].y * h) cv2.circle(frame, (x_px, y_px), 6, (0, 0, 255), -1) mp_drawing.draw_landmarks( frame, results.pose_landmarks, mp_pose.POSE_CONNECTIONS, landmark_drawing_spec=mp_drawing_styles.get_default_pose_landmarks_style(), ) cv2.imshow("pose", frame) if cv2.waitKey(1) & 0xFF == 27: break pose.close() cap.release() cv2.destroyAllWindows()pose.process(rgb)的入参必须是 RGB，因为 Mediapipe 内部按 RGB 处理；如果直接传 BGR，关键点位置会偏移甚至错乱，这是我第一次跑通后最直观的坑。landmark里的 x、y 是 0~1 的归一化坐标，原点在图像左上角，x 向右、y 向下，所以转像素坐标要分别乘 width 和 height；z 是深度信息，量纲和 x 大致一致，但需要实验确认。visibility是每个点的检测置信度，后面驱动模型时我会拿它做过滤——低于 0.3 的点直接不驱动，避免模型乱动。mp_pose.POSE_CONNECTIONS定义了哪些点连成骨架线段，draw_landmarks 直接按这个拓扑画线即可。
提示：
pose.process(rgb)返回的results.pose_landmarks在检测不到人时是None，所以代码里先判空再访问。
3.3 参数调优：model_complexity、置信度与平滑
| 参数 | 取值范围 | 影响 | 我常用的值 |
|---|---|---|---|
| model_complexity | 0 / 1 / 2 | 0 是 lite，1 是 full，2 是 heavy；越高越准但越慢 | CPU 用 1，GPU 用 2 |
| min_detection_confidence | 0~1 | 检测阶段的置信度门槛，调高减少误检但容易丢帧 | 0.5 |
| min_tracking_confidence | 0~1 | 跟踪阶段的门槛，调低让已跟踪的点更「顽强」 | 0.5 |
| smooth_landmarks | True / False | 时间序列滤波，减少逐帧抖动 | True |
实际调参时，先看可视化再动参数。如果画面里骨架和身体明显对不齐，先检查是不是 BGR/RGB 传反了，而不是急着调复杂度。如果静止时手部关键点在小幅抖动，先开smooth_landmarks，再把min_detection_confidence往上抬到 0.6~0.7，抖动通常会明显收敛。如果想让手臂动作更快跟手，把model_complexity降到 0 换帧率，但会损失一下精度，表里那个权衡值基本够用。多关节运动跟踪在这一步就完成了：33 个点和连接关系都是模型一次推理给出的，不需要自己写匹配逻辑。
4. 实时数据传输：Python 到 Unity3D 的 UDP 通道与帧率控制
姿态数据在 Python 端算出来后，要跨进程传给 Unity3D。这一步的选型直接决定延迟和稳定性，也是最容易被忽视的一环。我见过不少人在这里用 TCP，结果稍微动一下就卡顿，原因不是网络问题，而是协议选错了。
4.1 传输方案选型：为什么 UDP 而不是 TCP
TCP 可靠，但自带重传和粘包处理，在局域网或本机传输时这些特性反而是负担：网络抖动一次，TCP 会等重传，导致后续帧排队，延迟像锯齿一样跳。动捕场景丢一两帧无关紧要，下一帧马上补上，人眼根本感知不到，所以单向、无连接的 UDP 是更合适的方案，代价是要自己处理丢包——在姿态数据这个场景里，丢包的代价远低于重传带来的延迟。
| 对比项 | TCP | UDP |
|---|---|---|
| 可靠性 | 可靠，自动重传 | 尽力而为，可能丢包 |
| 延迟表现 | 抖动时排队阻塞 | 稳定，丢帧即弃 |
| 连接管理 | 需要建立/断开连接 | 无连接，直接发包 |
| 适用场景 | 文件、消息类 | 实时姿态、音视频 |
同一台机器上跑 Python 和 Unity3D，直接用127.0.0.1回环地址，数据不走网卡，延迟稳定在 1ms 以内。跨机器传输时，Python 端要绑到局域网 IP，Unity 端监听0.0.0.0，并确保防火墙放行 UDP 端口。帧率策略上，姿态估计跑 30fps，传输也按 30fps 发，不必每帧都发——人做动作的最高有效频率远低于 30Hz，隔帧发送既能降负载，也避免在 Unity 端堆积旧数据。payload 大小是 33 个点 × 4 个 float 加头部，约 1~2KB，单个 UDP 包完全装得下，不需要拆包。
4.2 Python 端发送端：序列化与帧率控制
import json import socket import time import cv2 import mediapipe as mp mp_pose = mp.solutions.pose pose = mp_pose.Pose(model_complexity=1, smooth_landmarks=True) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) UDP_IP, UDP_PORT = "127.0.0.1", 8888 cap = cv2.VideoCapture(0, cv2.CAP_DSHOW) last_send = 0.0 while cap.isOpened(): ok, frame = cap.read() if not ok: break rgb = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) results = pose.process(rgb) now = time.time() if results.pose_landmarks and (now - last_send) >= 1.0 / 30: lms = [ {"x": lm.x, "y": lm.y, "z": lm.z, "v": lm.visibility} for lm in results.pose_landmarks.landmark ] payload = { "frameId": int(now * 1000), "timestamp": now, "landmarks": lms, } data = json.dumps(payload).encode("utf-8") sock.sendto(data, (UDP_IP, UDP_PORT)) last_send = now pose.close() sock.close() cap.release()1.0 / 30做发送节流，last_send记录上次发送时刻，只有间隔超过 33ms 才发，避免 Unity 端被同一帧数据轰炸。timestamp用time.time()写入，Unity 端拿到后可以算端到端延迟，这是后面第 6 章验证「实时」的依据。frameId用毫秒时间戳，用来判断哪帧丢包了。序列化用 JSON，因为可读性好、带字段名，抓包调试时一眼能看出问题；如果后续要压带宽，把 landmarks 从字典数组改成二维数组[[x,y,z,v], ...]，字符串体积能缩小一半，我一般等到确实卡了才做这步优化。
4.3 Unity3D 端接收：C# 解析与坐标系转换
using System; using System.Net; using System.Net.Sockets; using System.Text; using System.Threading; using System.Collections.Concurrent; using UnityEngine; [Serializable] public class Landmark { public float x, y, z, v; } [Serializable] public class PoseFrame { public int frameId; public double timestamp; public Landmark[] landmarks; } public class PoseReceiver : MonoBehaviour { public int listenPort = 8888; private UdpClient udp; private Thread recvThread; private ConcurrentQueue<PoseFrame> queue = new ConcurrentQueue<PoseFrame>(); void Start() { udp = new UdpClient(listenPort); recvThread = new Thread(ReceiveLoop); recvThread.IsBackground = true; recvThread.Start(); } void ReceiveLoop() { IPEndPoint remote = new IPEndPoint(IPAddress.Any, 0); while (true) { try { byte[] bytes = udp.Receive(ref remote); string text = Encoding.UTF8.GetString(bytes); PoseFrame frame = JsonUtility.FromJson<PoseFrame>(text); queue.Enqueue(frame); } catch (Exception e) { Debug.LogWarning("UDP receive error: " + e.Message); } } } void Update() { PoseFrame frame; while (queue.TryDequeue(out frame)) { // 这里拿到最新帧，后续驱动逻辑消费 } } public bool TryGetLatest(out PoseFrame f) { f = null; PoseFrame candidate; while (queue.TryDequeue(out candidate)) { f = candidate; // 只保留队列里最新的那帧 } return f != null; } void OnDestroy() { if (recvThread != null) recvThread.Abort(); if (udp != null) udp.Close(); } }UdpClient.Receive是阻塞调用，所以必须放独立线程，否则 Unity3D 主线程会被卡死，这是新手最容易踩的坑。ConcurrentQueue做线程间安全移交，收到帧先入队，Update里读队列，避免在子线程直接碰 Unity API。JsonUtility.FromJson<PoseFrame>要求数据结构是一个类对象，不能直接解析顶层 JSON 数组，所以我把整个 payload 包成PoseFrame，这也顺带解释了 5.3 里那个解析失败的坑。
坐标系转换是 Python 端到 Unity3D 端最需要统一的一步。Mediapipe 的图像坐标系原点在左上、y 向下，Unity3D 是左手坐标系、y 向上，常见做法是：
Vector3 ToUnityPosition(float x, float y, float z, float scale) { float mx = (x - 0.5f) * scale; // 中心对齐 float my = (0.5f - y) * scale; // y 轴翻转 float mz = z * scale * 0.5f; // 深度压缩，避免模型被拉成条 return new Vector3(mx, my, mz); }(x - 0.5f)和(0.5f - y)把归一化坐标平移到以中心为原点，再乘scale缩放到模型体长量级。z 深度通常要乘一个小于 1 的系数，因为 Mediapipe 的 z 噪声比 x/y 大得多。这个映射没有标准答案，不同模型骨架长度不同，scale 要重新标定，这也是第 5 章里避坑的重点。
5. Unity3D 三维模型驱动与避坑记录：骨骼映射和延迟处理
数据到了 Unity3D，最后一步是把 33 个关节坐标变成模型的动作。这一步的表面逻辑不复杂——把坐标赋给对应骨骼的 Transform——但真正做起来，骨骼映射、插值平滑、置信度过滤三个细节缺一不可。
5.1 骨骼映射：33 个关键点到模型关节的对应
Mediapipe 的 33 个关键点里有 17 个是上半身和下半身的主要关节，其余是脚部、面部等辅助点。驱动模型时不需要全用，但映射表必须按索引建好，后面驱动脚本才可控。
| Mediapipe 索引 | 关键点名称 | 对应模型部位 |
|---|---|---|
| 0 | 鼻尖 | 头部 |
| 11 / 12 | 左/右肩 | 上臂根部 |
| 13 / 14 | 左/右肘 | 大臂末端、小臂起点 |
| 15 / 16 | 左/右腕 | 小臂末端、手掌 |
| 23 / 24 | 左/右髋 | 骨盆左右 |
| 25 / 26 | 左/右膝 | 大腿末端、小腿起点 |
| 27 / 28 | 左/右踝 | 小腿末端、脚掌 |
映射的常见做法有两种。第一种是建 33 个空物体，按POSE_CONNECTIONS的层级关系排成骨架，再把每个空物体指定到模型对应部位，纯位置直驱；第二种是模型走 Humanoid 骨骼，用Animator.GetBoneTransform(HumanBodyBones.LeftUpperArm)拿到骨骼 Transform，但位置直驱和骨骼旋转会冲突，需要配合 Two Bone IK 反算旋转。我刚上手时用的第一种，因为空物体层级不受模型绑定方式限制，换个模型只要重新指定一遍映射就行。
5.2 动作驱动：插值平滑与置信度过滤
public class RigDriver : MonoBehaviour { public PoseReceiver receiver; public Transform[] joints = new Transform[33]; public float scale = 1.8f; public float smooth = 8f; void Update() { PoseFrame frame; if (!receiver.TryGetLatest(out frame)) return; for (int i = 0; i < frame.landmarks.Length; i++) { if (frame.landmarks[i].v < 0.3f) continue; // 低置信度不驱动 Vector3 target = new Vector3( (frame.landmarks[i].x - 0.5f) * scale, (0.5f - frame.landmarks[i].y) * scale, frame.landmarks[i].z * scale * 0.5f); joints[i].position = Vector3.Lerp( joints[i].position, target, smooth * Time.deltaTime); } } }TryGetLatest只取最新帧，丢掉的旧帧直接不处理，保证模型跟的是当前动作而不是排队积压的数据。visibility < 0.3f的跳过条件很关键：手背到身后、脚从镜头里消失时，Mediapipe 仍会输出猜测坐标，不过滤的话模型会出现「手穿身体」或者「脚拖地」的诡异动作。Vector3.Lerp的smooth * Time.deltaTime是标准一阶平滑，smooth取 8 左右时跟随性好且不明显滞后；如果模型抖动，先降smooth而不是降帧率，因为降帧率会同时放大动作突变感。
提示：位置直驱的模型脚部容易滑步。要缓解的话，把骨盆（23/24 中点）作为 Root 随动，手脚位置只做形状匹配，这一步会明显改善观感，算是最低成本的「防滑步」手段。
5.3 避坑记录：五条踩坑记录
1. Mediapipe 安装后 import 报错。现象：pip install mediapipe成功，但import mediapipe直接崩溃，报 protobuf 相关错误。 原因：Python 3.11+ 和旧版 Mediapipe 的 protobuf 版本冲突。 解决：降回 Python 3.8~3.10，或执行pip install protobuf==3.20.3。装完先跑一遍 2.2 的版本验证再继续。
2. 抬手模型抬另一只手。现象：人举右手，Unity3D 里模型举左手，左右完全镜像。 原因：图像坐标系和 Unity3D 左手坐标系差异，加上摄像头镜像后没有统一。 解决：Python 端确认cv2.flip(frame, 1)之后再做姿态估计；Unity3D 端 x 方向取反，即(0.5f - lm.x)或-(lm.x - 0.5f)，和 y 轴翻转一起做。
3. 静止时手部关键点抖动。现象：人站着不动，模型手在 5~10 厘米范围内晃动。 原因：landmark 噪声被直接赋给 Transform，没有平滑。 解决：开smooth_landmarks=True，驱动端加Lerp平滑，并对低visibility的点直接跳过。这两件事缺一不可。
4. Unity3D 收不到任何数据，Python 端发送正常。现象：Python 端sendto不报错，Unity 端队列一直为空。 原因：UdpClient 子线程异常崩溃，或 Windows 防火墙拦了 UDP，或端口被占。 解决：ReceiveLoop 里加 try/catch 并Debug.LogWarning，先看有没有异常日志；同机测试用127.0.0.1，跨机测试先关防火墙或者放行对应 UDP 端口。
5. JsonUtility 解析出来的字段全是 0。现象：Unity 端收到字符串长度正常，但frameId、landmarks全是默认值。 原因：JsonUtility.FromJson不能直接解析顶层 JSON 数组，必须包在一个类对象里。 解决：按 4.3 的做法定义PoseFrame包装类，字段名要和 Python 端 payload 的键完全一致，大小写不匹配也会静默置零。
6. 延迟量化与可视化验证：先证明数据对了再换模型
6.1 用时间戳量化端到端延迟
我判断这套链路能不能算「实时」的方法很简单：Python 端把time.time()写进 payload，Unity3D 端收到时取当前系统毫秒，两者做差得到端到端延迟。注意两个时钟存在偏移，我在 Python 端启动时额外打印一次系统时间，Unity3D 端用同一个基准做初始偏移修正。
double epochMs = (DateTime.UtcNow - new DateTime(1970, 1, 1)).TotalMilliseconds; double latencyMs = epochMs - (frame.timestamp * 1000.0) - clockOffsetMs; totalMs += latencyMs; if (++count == 120) { Debug.Log($"avg latency: {totalMs / count:F1} ms"); count = 0; totalMs = 0; }同机127.0.0.1回环，我实测正常在 30~60ms 量级，其中大部分是 Mediapipe 推理时间。如果稳定超过 100ms，先去查 Python 端是不是每帧都发、Unity 端是不是在Update里做了重操作，而不是急着怪网络。
6.2 先驱动线框小人再套模型
我踩过的最亏的一次是：模型完全不动，折腾半天以为是骨骼映射写错了，最后发现是 z 方向缩放大了十倍，坐标全跑到镜头外。从那以后我每次接新模型，都强制先跑一遍线框验证——在 Unity3D 里把 33 个点按POSE_CONNECTIONS连成 stick figure，直接挂到相机前，确认抬手、下蹲、转身三个动作都对，再套 skinned mesh。这一步把「数据错」和「模型错」彻底分开：线框对，问题就在模型绑定；线框不对，回去查坐标转换和缩放。希望帮到你。
本文还有配套的精品资源，点击获取
