GTAV 五档人体白模/深度/法线与长时前景/背景输出：交接草案

待对齐的方案，不代表已存在的输出或渲染程序。 数据根目录 GTAV_ROOT=/apdcephfs_bjzf/share_303702067/human_video/data/gtav。本次修订以五档为准：1 box；2 动作频率贴近原人的随机积木；3 动作频率不同的随机积木；4 SMPL；5 原始高模。1–3 另加长时「只有前景人物」和「没有前景人物、只有背景」两种条件。

1. 输入与对齐基准

2. 五档的语义（粒度和动作来源分开记录）

建议默认单 clip / 各档输出该档所有有效人物，同帧多人合成并共享 z-buffer；instance_id 来自引擎，不是画框顺序。各档相机和时间索引一致，但 2/3 的动画被刻意更换，不得宣称每帧的人体关节与 RGB 真值完全一致。为避免随机人物飞出画面，建议 2/3 在原始人物的根轨迹/朝向/尺度附近生成积木，只有积木的局部关节动作从动作库抽样；根是否也随机化须先确认并单独改规范版本。

| 档位 / 目录名 | 人体几何和运动 | 可复现要求 | | --- | --- | --- | | 01_box | 每人一个 3D box（六个实体面），随原人物逐帧根位置/尺度更新；尽量不表达局部肢体动作 | 由 55 骨定义构建与 padding 规则；不是 2D 实心画框 | | 02_blocks_freq_near | 随机选一种积木人造型与一段积木动画，使动画动作频率与对应原人物贴近；积木人表示为躯干、头、四肢等若干三维实体积木 | 按人/按长时段固定一次随机选择，避免每帧换风格；根沿用原人物，局部动作来自抽样段；记录积木模板/动作 ID、seed、频率和误差 | | 03_blocks_freq_far | 同一类型积木人，但随机选与对应原人物动作频率不同的动画；可共用 02 的造型以单独比较运动差异 | 尽量与 02 共用积木外形、根轨迹和可见人员；只换局部动画和抽样条件，记录动作 ID、频率差及 seed | | 04_smpl | SMPL 档人体白模，建议明确采用当前代码路径实际支持的 SMPL-X，用与原人物对应的动作进行拟合/渲染 | 元数据写 model_type=smplx、拟合状态及版本。现有 960p 全量多为主角且 betas=0，不能当作 720p 所有人已拟合 | | 05_original_high | 与原 instance_id 对应的引擎原始高模，不加贴图/材质，以统一白模渲染 | 需资产负责人提供可用原始 mesh、LOD、绑定/蒙皮、实例→模型映射和使用授权；当前未在 interface 现有资产中确认可用，缺资产时标 unavailable，不能用 SMPL 冒充 |

2/3 的「动作频率」操作定义（建议先冻结，再选动画）

  1. 采样单位为单个 instance 的连续长时段，而不是逐帧。对原人物 55 骨去根平移并归一到身高，取有效且稳定的四肢末端/肘膝局部位置或关节角，按源时间戳计算速度或能量时间序列；去除低速噪声及相机/根移动后计算主频、有效带宽或单位时间往复次数。积木库里的每条动画用同一关节集/同一算法标注频率，不可把人物跑动的根平移频率与原地挥手的手部频率直接比较。
  2. 先定动作库、频率表、可匹配身体部位、统计窗长、运动强度过滤及 near / far 的互斥阈值。举例（仅待试跑调参）：near 的主频差 ≤ 20% 且强度同量级，far 的主频差 ≥ 50%，中间灰区不采样；对于静止/无可靠周期的人，写 unmeasurable 并采用显式的「静止近似 / 高活动不同」策略或跳过，不可标成满足频率阈值。
  3. 匹配库里随机抽样：如 seed=hash(spec_version, clip_id, instance_id, segment_id, variant) 固定候选次序；若 near/far 无可用动作，不强行随机选一个冒名顶替，记录 unavailable。动作可时间平移对齐段首，但是否允许速度缩放/循环需明确；建议先不缩放频率，若必须循环则接缝做连续性验收。
  4. meta.json 至少写原人/选中动作频率、估计方法/窗长、阈值、动画 ID、积木模板 ID、随机种子、根轨迹继承方式、重定向映射及不可用原因。2/3 用相同的时间采样、同一套相机和不同动作；RGB 与 2/3 的对齐是视角/时间轴/人位置对齐，不是姿态像素对齐。

3. 长时序：1–3 档的前景-only / 背景-only

长时不能简单把已有 169 帧短 clip 延长/循环。 优先按一个连续 raw/<capture> 的 metadata.jsonl 顺序构造不跨 capture、不跳过已知帧的长时序，依据真实时间戳选择播放方式（建议保留源帧顺序、输出 24 fps，若原始采样不均则记录原 t_ms，不要悄悄重采样）；长时输出独立的 sequence_id、起止 source_frame、源时间与帧数。在现有短 clip 路线上，只能用同一 capture 中时间上相邻、source_frame_indices 连续且相机参数一致的片段拼接，并严查 169 帧窗口/源间隔是否真的无缺帧；不满足则标 gap，不跨越假装连续。

建议前景定义：这两个模式里「前景人物」= 这段画面中所有要渲染的人的集合（可为 0/1/N 个），与 raw/masks.z 的 protagonist class 1 不同。每个 sequence_id 记录纳入的 instance_id 列表；遇到入画/出画随帧更新。需讨论是否要过滤远处路人；若要过滤写固定规则，不能悄悄只挑主角。

| 模式 / 输出目录 | 1–3 的交付内容 | 白模/深度/法线约定 | | --- | --- | --- | | foreground_only | 只保留全部选中人物、不显示背景，背景黑色（如需要透明 alpha，另给无损 mask 而非在 H.264 里假装透明） | 对 01/02/03 均有 white.mp4、depth_vis.mp4、normal_vis.mp4 和精确 depth.z、normal.z；人像区域三者用同一次光栅化的最近可见面 | | background_only | 没有前景人物，只有背景：必须明确是重建无遮挡背景，还是仅把原 RGB 的人像涂黑（后者不等于只有背景） | 推荐 background.mp4 + background_depth.z/.json（若真有场景深度），没有人体法线真值；如果合同上要求每个模式都交三视频，则可统一导出 white.mp4、depth_vis.mp4、normal_vis.mp4（人体通道全黑）及人体 depth/normal 全零，同时另外交真正的 background.mp4，元数据注明「人体通道为空」，不能用全黑帧代替背景 |

关键限制：当前 RGB 的被人挡住的区域没有天然的无遮挡 RGB；现有场景 depth_z 的该区域通常也是可见的人表面，不能把它自动解释为无遮挡背景深度。真 background_only 必须有游戏引擎重新渲染（关掉人）、已记录的干净背景层、或者单独经批准的时序补全方案。时序补全是估计而非 GT，应标 inpainted、保留不确定区域掩码/方法版本，不得宣称逐像素真值。原始视频已经有行人但无其逐实例运动/掩码时也不能声称场景完全无人。资产未到位时先完成 foreground_only，background_only 登记 unavailable；不可用不拖垮其他产物。

如果「只有背景」实际指的是**只渲染无人物的游戏几何（背景白模 + 场景深度 + 场景法线）**而非「无人 RGB」，那是另一份资产需求：场景 mesh/material 可见性、法线、引擎去人重渲，当前目录不能保证；不要复用人体全零法线冒充背景法线。

4. 目录与文件：短时五档、长时 1–3 独立索引

不改源 crop_* 文件。建议新建 GTAV_ROOT/human_render_720p_v2/（v2 表示本次五档规范与旧七档草案分开），clip_id 和 RGB 一致；sequence_id 可由 <capture>_frames_<first>_<last> 确定，避免用小数秒猜帧界。

GTAV_ROOT/human_render_720p_v2/
├── spec.json                          # 版本/相机、频率口径、光照、编码和遮挡
├── short_manifest.jsonl              # clip_id -> 源池/状态/五档路径
├── long_manifest.jsonl               # sequence_id -> 连续源帧/状态/前景背景路径
├── short/<clip_id>/
│   ├── source.json                    # 源 RGB、相机、source_frame_indices
│   ├── 01_box/
│   │   ├── white.mp4                  # 所有人白模
│   │   ├── depth_vis.mp4              # 人体 z 可视化，不是米制真值
│   │   ├── normal_vis.mp4             # 人体相机系法线可视化
│   │   ├── depth.z + depth.json        # 数值米制人体 z
│   │   ├── normal.z + normal.json      # 数值人体单位法线
│   │   └── meta.json                  # 有效实例、造型/动作/种子/覆盖/状态
│   ├── 02_blocks_freq_near/           # 同名五件 + meta.json
│   ├── 03_blocks_freq_far/
│   ├── 04_smpl/
│   └── 05_original_high/              # 缺资产时 meta.json 标 unavailable
└── long/<sequence_id>/
    ├── source.json                    # 连续性/源时间戳/相机与 RGB 片段
    ├── foreground_only/
    │   ├── 01_box/                    # 同短时的三视频 + 数值数据 + meta
    │   ├── 02_blocks_freq_near/
    │   └── 03_blocks_freq_far/
    └── background_only/
        ├── background.mp4             # 真无人 RGB / 明确注明 inpainted
        ├── background_depth.z          # 仅有可信无遮挡背景深度时提供
        ├── background_depth.json
        └── meta.json                  # 场景来源、无效/补全区域、状态

background_only 是同一长时段共享的背景条件，不用在 1–3 下复制相同背景三份；如后续训练加载器硬要求逐档路径，可做 manifest 映射或链接。对于未来要求「白模背景版」，单独添 background_geometry/，不要与 background.mp4 混名。

编码统一约定

| 类型 | 建议规格 | | --- | --- | | white.mp4 | 1280×720，24 fps，帧数与对应 RGB/长序列相同；无音频，H.264 yuv420p，建议 libx264 -crf 18 -preset medium -movflags +faststart；纯黑背景 + 统一柔和光照的白色实体，无贴图、RGB 叠加/字幕/自动 zoom。视频是预览，不是几何真值 | | depth_vis.mp4 | 同尺寸/帧率/帧数；固定统一 0.1–80 m 范围映射，人体空区黑色，调色盘记录在 spec.json；视频不可反推精确米数 | | normal_vis.mp4 | 同规格，OpenCV 相机系 (nx,ny,nz) 映射 round(255*(n+1)/2) 的可视化，人体空区黑色；编码有损 | | depth.z + depth.json | 人体可见面 z-buffer，相机 z、米、float16、(F,720,1280)，无人像/无效=0。逐帧压缩包+offset/size 索引，建议复用 crop_interaction_depth_z.py 的 float16_le_zlib_bytesplit，但内容必须从本档人体渲染器生成 | | normal.z + normal.json | 可见面OpenCV 相机系单位法线、float16、(F,720,1280,3)，背景全 0，正面外法线通常 nz<0。新建且验证 normal_f16x3_planar_bytesplit_zlib_v1 编/解码（逐通道高/低字节平面），不要误用单通道深度解码器 |

两份数值 .json 带 schema_version、clip_id/sequence_id、档位/模式、尺寸、dtype、单位/坐标系、source_frame_indices、每帧 offset/size/source_frame、有效像素约定；序列时间戳记录在 source.json。若 scene-only 无数值背景深度则不要写同名的虚假 background_depth.z。原子写临时文件并通过校验后发布；规格变更另升版本，不静默覆盖。

5. 验收与交接步骤

  1. 先敲定词义/资产：把 2/3 的「积木」确认成有深度和法线的三维分部件实体；确定动作库/频率算法、2/3 是否共用造型、根运动是否保持；确认 5 的可访问性；确认「背景-only」是无人 RGB还是无人场景白模/法线，以及能否重新渲染场景。
  2. 短时试跑：单人+多人至少两条，逐档同一 RGB/相机投影；2/3 同一人的频率统计可复算，样本不同且满足互斥阈值。SMPL 对齐要求720p 相机导出的 cameras.pt 用 K_pix，若只用 960p 的主角导出或 K_pix 缺失不能作为“所有人已完成”。已有 interface/_runs/yup_crop720_all_20261020/export/ 仅两条试跑供参考。
  3. 长时试跑：一个多人的真实连续 capture 片段，记录全部 foreground instance_id、入画出画、原始 t_ms、接缝检查；背景重渲与原片逐帧同镜头。若背景资产尚无，先输出 1–3 的 foreground_only 并说明背景未就绪。
  4. 每条严格校验：视频尺寸、fps、无音频、解码帧数；source_frame_indices 与 RGB 一一对应；单帧 depth>0 与 normal 有效区域及渲染 foreground mask 一致，背景全零、法线长度≈1；多人遮挡用同一最近表面 z-buffer；白模与 RGB 对比位置（2/3 不要求动作姿态相等）。background.mp4 若声称干净背景，必须人区域确实被有依据地重建，不能只抹黑。
  5. 留痕交付：short_manifest.jsonl / long_manifest.jsonl 每样本和每档记录 complete/partial/unavailable/failed 及原因、输入 hash、算法和代码版本、随机 seed 与动作 ID、验收结果；记录试跑产物大小以评估全量存储，按此决定两个 _vis.mp4 是否全量保留。

参考本地实现：interface/DATA_LAYOUT.md、crop_gtav_720p.py、crop_interaction_depth_z.py、export_gtav_clips.py、convert_gtav_yup.py、fit_gtav_keypoints.py、overlay_gtav_mesh.py。当前没有运行渲染，也没有确认原始高模/无遮挡背景的可用性。