简介一套围绕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 链路设计采集、估计、传输、驱动四层层运行端职责关键组件采集PythonVideoCapture 读帧、镜像、设分辨率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 相关错误时常见做法是降级 protobufpython -m pip install protobuf3.20.3。这类冲突在旧版本 Mediapipe 上出现概率很高属于必踩项。Unity 端我用的 2021.3 LTS脚本后端选 .NET 4.xC# 代码用 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 实时安装成本适用场景OpenPose18/135难高Caffe/GPU学术研究、多人姿态PoseNet17中中移动端轻量需求Mediapipe33好低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_modeFalse, model_complexity1, smooth_landmarksTrue, min_detection_confidence0.5, min_tracking_confidence0.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_specmp_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 和 heightz 是深度信息量纲和 x 大致一致但需要实验确认。visibility是每个点的检测置信度后面驱动模型时我会拿它做过滤——低于 0.3 的点直接不驱动避免模型乱动。mp_pose.POSE_CONNECTIONS定义了哪些点连成骨架线段draw_landmarks 直接按这个拓扑画线即可。提示pose.process(rgb)返回的results.pose_landmarks在检测不到人时是None所以代码里先判空再访问。3.3 参数调优model_complexity、置信度与平滑参数取值范围影响我常用的值model_complexity0 / 1 / 20 是 lite1 是 full2 是 heavy越高越准但越慢CPU 用 1GPU 用 2min_detection_confidence0~1检测阶段的置信度门槛调高减少误检但容易丢帧0.5min_tracking_confidence0~1跟踪阶段的门槛调低让已跟踪的点更「顽强」0.5smooth_landmarksTrue / 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 而不是 TCPTCP 可靠但自带重传和粘包处理在局域网或本机传输时这些特性反而是负担网络抖动一次TCP 会等重传导致后续帧排队延迟像锯齿一样跳。动捕场景丢一两帧无关紧要下一帧马上补上人眼根本感知不到所以单向、无连接的 UDP 是更合适的方案代价是要自己处理丢包——在姿态数据这个场景里丢包的代价远低于重传带来的延迟。对比项TCPUDP可靠性可靠自动重传尽力而为可能丢包延迟表现抖动时排队阻塞稳定丢帧即弃连接管理需要建立/断开连接无连接直接发包适用场景文件、消息类实时姿态、音视频同一台机器上跑 Python 和 Unity3D直接用127.0.0.1回环地址数据不走网卡延迟稳定在 1ms 以内。跨机器传输时Python 端要绑到局域网 IPUnity 端监听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_complexity1, smooth_landmarksTrue) 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 ConcurrentQueuePoseFrame queue new ConcurrentQueuePoseFrame(); 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.FromJsonPoseFrame(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.FromJsonPoseFrame要求数据结构是一个类对象不能直接解析顶层 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 protobuf3.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_landmarksTrue驱动端加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()写进 payloadUnity3D 端收到时取当前系统毫秒两者做差得到端到端延迟。注意两个时钟存在偏移我在 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。这一步把「数据错」和「模型错」彻底分开线框对问题就在模型绑定线框不对回去查坐标转换和缩放。希望帮到你。本文还有配套的精品资源点击获取