实时光线追踪工程 2026:DXR、ReSTIR 与 Lumen 混合架构
把硬件 RT 作为几何遍历骨架、ReSTIR 作为样本复用放大器、Lumen 风格的 surface cache + voxel/surfel/SSR 作为视觉连续性的兜底、OIDN/OptiX 降噪器作为质量守门员,把 4K 60fps 实时光追从 GPU demo 推进到 AAA 游戏主路径。
约 46 分钟阅读13,673 字11 次阅读博主
把硬件 RT 作为几何遍历骨架、ReSTIR 作为样本复用放大器、Lumen 风格的 surface cache + voxel/surfel/SSR 作为视觉连续性的兜底、OIDN/OptiX 降噪器作为质量守门员,把 4K 60fps 实时光追从 GPU demo 推进到 AAA 游戏主路径。
从 2018 年 NVIDIA Turing 架构引入消费级 RT Core 到 2026 年,八年间实时光线追踪在游戏引擎里的角色发生了根本性变化:它不再是 NVIDIA 旗舰显卡演示 demo 里的"金字塔反射"或"光滑金属球",而是 GPU 驱动管线、屏幕空间后处理、全局光照三大体系的第四条纵向支撑——任何一个面向 2026 年发布的 3A 端游或 AAA 手游,如果不把硬件光追作为质量预算的一部分规划,它的渲染管线就要在后续 18-24 个月内被迫重构。这并不是夸大:Unreal Engine 5 在 5.0 推出 Lumen、5.3 把 Lumen 与 Nanite 深度耦合、5.5 全面默认开启 Hardware Ray Tracing fallback、5.7 引入 ReSTIR 风格的稳态辐照度缓存;Unity 6 的 HDRP 通过 RTAS (Ray Tracing Acceleration Structure) 与 Adaptive Probe Volumes 联动提供两条可选路径;自研引擎如 CryEngine、Decima、id Tech 在主机平台都已把 DXR / Vulkan Ray Tracing Extension 列入核心 schedule 而非可选模块。
把这一切说成"实时光追终于成熟了"是对工程现实的简化。真实的情况是:硬件 RT Core 在消费级显卡上给出了约 1.5-3 倍传统光栅化的几何处理吞吐,但单条光线在场景中的 bounce 数和反弹深度仍受到 RT Pipeline 状态切换与 BVH 遍历 cache miss 的双重约束——直接拿 DXR 去做 naive path tracing 在 4K 分辨率下要 50-80ms / frame,远远超过 16.6ms 的 60fps 预算。所以工程化落地的核心问题,不是"用不用硬件光追",而是"用硬件光追负责哪个子任务、用 ReSTIR 等样本复用技术补偿 bounce 深度、用 Lumen 风格的 hybrid 架构对接剩余的光栅化部分"。这三件事在 2026 年的引擎源码里是耦合在一起的——单独讨论 DXR 的指令发射或单独讨论 ReSTIR 的数学都失之片面,本文以混合架构的工程装配为切入点,从指令层到画质守门员层全程覆盖。
读者画像不是"想了解 RT 是什么"的科普读者,而是要在引擎渲染管线里实装某个模块的图形程序员、需要评审 RT 项目里程碑的 tech lead、或要把传统延迟渲染管线升级到 RT 感知的资深工程师。文章默认读者熟悉光线求交、辐照度积分、BRDF 采样,不需要再赘述 PBR 基础;重点放在状态机、缓存布局、降噪器联动、性能预算这些"看了几份 SIGGRAPH 论文也未必能直接落地"的工程细节。
把实时光追在 2026 年游戏引擎里的形态做一个最简形式化,可以归纳为**辐照源(S)、传播算子(T)、采样规则(Ω)、输出空间(X)**四元组:
S/T/Ω/X 四元组选择的笛卡尔积给出 100+ 种实时光追变体,但 2026 年引擎工业实践收敛到 "DXR + ReSTIR 风格的样本复用 + Lumen 风格 hybrid + OIDN-class 降噪" 这一主线。本文其余八节沿着这条主线展开,每一节对应四元组中至少一个元素的工程细节。
把这套四元组放到引擎源码的视角看:UE 5.7 的 Lumen 模块对应 S=surfel+probe+hardware、T=hybrid propagation、Ω=ReSTIR-style、 X=surface radiance cache;Unity 6 HDRP 的 RTAS 同样落到四元组但 X 偏 deferred 表面;CryEngine 与 Decima 的自研方案在 Ω 上更多采用 screen-space reuse 而非 pure ReSTIR,但 IRCD (incremental ray-traced diffuse cache) 模块与 S/T 选择高度一致。理解四元组之后,任何"换一套实时光追实现"的工程问题都可以归约到"在四元组中改哪个元素"的明确决策——这是本文后面所有讨论的形式化基础。
硬件光追在引擎里落地的第一步不是 math 而是指令发射。DXR (DirectX Raytracing) 在 12 之后被纳入 DirectX 12 Ultimate,Vulkan 通过 VK_KHR_ray_tracing 与 VK_KHR_ray_tracing_position_fetch 把同样能力暴露给跨平台;Metal 在 Apple GPU 上通过 Metal Ray Tracing API 提供对等能力但在移动端的可用性受限。这一层看似"各家 API 差不多",实际工程差异极大,主要体现在以下五处:
3.1 Acceleration Structure (AS) 的组织:AS 在 DXR 里分为 Bottom-Level AS (BLAS) 与 Top-Level AS (TLAS)。BLAS 由一组几何(顶点+索引)构造,可以是 vertex format index buffer 也可以是 procedural AABB;TLAS 是 BLAS 的 instance 容器,每个 instance 可以带 transform。引擎层面要决定 BLAS 是 per-mesh 还是 per-clustered-meshlet:per-mesh 简单但大场景内存膨胀(一个 10000 mesh 的关卡 BLAS 总和可达 GB 级),per-clustered-meshlet 通过 Meshlet 把同一 mesh 切成多个 BLAS,TLAS instance 数爆炸但内存受控。Nanite 选 per-clustered-meshlet,UE 大世界分区(WP)进一步把 TLAS 按 chunk 切分并流式加载。
3.2 AS 重构建(refit vs rebuild):每帧顶点动则需要 refit(只在原 BLAS 上更新顶点 BBox),重构建(rebuild)只用于几何拓扑变化。refit 在 DXR 是 O(N) 单线程瓶颈,Vulkan 通过 parallel refit 缓解但仍受 AS 容量上限约束。一帧 16ms 的预算里,AS 更新要控制在 2-4ms 以内——这是个比 ray trace 本身更紧的硬约束。
3.3 RayGen / Miss / Hit Shader 的绑定模型:DXR 用 shader identifier 绑定 RT pipeline state,但 binding overhead 在每个 shader 之间需要重新 launch RayQuery;Vulkan 用 ray query 嵌入到 compute shader 内可避免 explicit launch。这是 DX12 RT Pipeline State Object 与 Vulkan ray query 在 PSO 状态切换开销上的根本差异——也是为什么一些跨平台引擎在 PSO cache 上要专门为 RT 路径做去重。
3.4 指令发射宽度:每 thread / wave 发几条光线合适?NVIDIA Ampere / Ada 给出每个 thread 1-4 条光线的吞吐曲线,RT Core 单周期可处理一次 box-tri intersect。工程经验值是每线程 2-3 条 太低浪费 RT Core,太高则 BVH 内部 node 切换造成 TLB miss。脚本化阈值常常 4-8 条,但引擎内 batch 调度要按 GPU wavefront 重排,实际写时按每 thread 1-2 primary ray + 1-2 shadow ray + 可选 1 reflection ray的 mixed 策略展开。
3.5 与现有光栅化管线的复用:deferred pipeline 已经写了 G-Buffer,RT 路径是否复用?UE 选择 RT 仅写入 Radiance Cache 而不重写 G-Buffer,Unity HDRP 在 Reflection Pass 重写 G-Buffer 但引入额外 RT pass。判断准则:G-Buffer 已经是 RGB16F + Normal + Roughness,RT 写入若能 spec 合到 Surface cache 则省一帧带宽;否则就要单独 RT pass 成本。Shader Permutation 爆炸是另一个隐性成本:同一 RT raygen shader 在 DX12 与 Vulkan 双平台上要 DXIL + SPIR-V 双套输出,光追降噪分支、阴影/反射分支一起算下来 permutation 矩阵可超过 200 种,某 AAA 项目在 shader compile time 上一度撞到 35 分钟 cook 长尾。修复手段:一是用 DXC + SPIRV-Cross 的交叉编译流水线把 200 个 permute 压缩到 60 个 master + kernel override;二是把次要的 RT 路径优化(LOD aliasing 等)放到 dynamic branch 内部,而非静态 permute。
把这五处都按字节落地到引擎模块的话,典型代码量是:AS 管理 3000-5000 行、shader identifier 工厂 800-1500 行、PSO cache 集成 1500-2500 行、RayGen shader 200-600 行 per pass。这背后是 6000-10000 行引擎代码与 1-2 名图形程序员 6-12 个月的工作量——这就是为什么 2026 年 RT 不是一个"小特性",而是引擎源码级别的主线工程。
实时光追在硬件 RT 上能给到 bvh 遍历吞吐但 bounce 深度受限,真正把 bounces 推到视觉可接受的办法不是堆更多光线,而是把已发的光线样本在时间帧之间、空间像素之间、辐射源之间复用——这是 ReSTIR (Reservoir-based Spatio-Temporal Importance Resampling) 家族的核心思想。
ReSTIR 的形式化起点是一篇 2020 SIGGRAPH 论文 (Bitterli et al.)。它把渲染方程的蒙特卡洛估计改写为稳态分布的增量估计,通过 reservoir sampling 在相邻像素与历史帧之间交换权重,在每个像素上维护一个小容量(典型 32-128 个样本容量,但实际只用 1 个 weighted sample 输出)的 reservoir。每个像素用这一对 reservoir 进行 final shading,然后输出到 G-Buffer 或 surface cache。直觉:如果相邻像素看到的几何与材质相似,他们的 radiance 估计也应该相似;复用比独立采样更高效。
ReSTIR 在 2026 年的工业变体已经远远超过原论文:
ReSTIR GI — 用于漫反射全局光照,用 spatial reuse + temporal reuse 双层 reservoir。一帧内 spatial neighbors 的 reservoir 互相 sample-tap,temporal 上做 heuristic 拒绝来抑制重影。typical implementation cost 1.5-3ms per 1080p,1 pass RT。
ReSTIR PT — 把样本复用推到 path tracing 全 bounce,不仅 diffuse 还包括 specular、glossy、transmission。这是 ReSTIR 家族里计算上最贵的版本,2026 年初主流引擎只在最贵的配置下用,中端 GPU 走 ReSTIR GI 即可。
ReSTIR DI — 用于直接光,包括面光、点光、方向光,在每像素的可见光集合上做 importance sampling。ReSTIR DI 的 spatial reuse 让数千盏动态光的引擎仍能保持 sub-ms 级直接光 sample 数。这是为什么 R6 Siege、Fortnite 这种大场景同时点光源多的游戏能保持 60fps。
Adaptive ReSTIR — 跨像素变种:屏幕静止区域用 1 sample,边缘像素用 4-8 sample,残差过阈值的像素触发 fallback 到 ReSTIR PT。Nvidia 在 2024-2025 几篇技术博文都给出 Adaptive ReSTIR 在 RTX 50-series 上的 throughput 数据,显示平均 sampler 数下降到 2-3 个/pixel 的水平。
工程实现 ReSTIR 的几个常见坑:
把 ReSTIR 落到引擎源码,典型 workload 是:每类 ReSTIR pass 写 ~1500 行 RTX/DXR shader + ~600 行 C++ reservoir 管理 + ~300 行 history buffer + ~200 行 debug/profiler。三套全做(GI + DI + Adaptive)是 ~5000 行 shader 与 ~3000 行 C++ 增量的中等模块,通常 2 名图形程序员 4-6 个月。这是实时光追最重要的 ROI 杠杆——同样的硬件 RT,加 ReSTIR 可以把同等画质的帧时间从 30ms 压到 8ms。
Lumen 是 Unreal 在 5.0 推出的 hybrid 渲染管线:它用软件光追(software ray tracing)与硬件光追二选一做 surface cache,再用屏幕空间 fallbacks 处理边缘 case,最后用 SSGI-style denoiser 把结果合成到 G-Buffer。Lumen 不是单一算法,而是数据结构 + 传播算子 + fallback 策略的三合一架构。本节把 Lumen 拆开看,以便其他引擎能迁移其思想。
5.1 Surface Cache as Lumen's Heart:Lumen 的核心数据结构是 Surface Cache — 8x8x8 cm (cm 级精度,参数化可调到 4-32cm) 的 3D 网格,覆盖摄像机周围约 200m 半径。每个 cell 存:从该 cell 中心向六面方向 trace 一段 distance field 得到的最近交点的 primitive ID + 距离 + 法线 + albedo + emissive。这是一张"屏幕外辐照度缓存表"——给到任意 3D 位置加上方向参数,做 trace lookup + shade 就能直接得 radiance 而不必从零发 ray。
5.2 Hybrid Trace:软件光追与硬件光追二选一:Lumen 默认走 software ray tracing (mesh SDF based),在支持的硬件上 fallback 到 DXR/Vulkan RT。software 方案的好处是不依赖硬件 RT Core 也能跑,在 Switch、PS4、老 Xbox One 上仍可用;坏处是 bounce 深度受限,SDF 大尺度不准确时会漏 ray。Hardware 方案在 30-series 与 Radeon 6000+ 上加速 2-3 倍但有 AS rebuild 开销。Lumen 5.7 的策略 是:Surfel + Software 作为默认路径,Hardware RT 作为高端配置可选 fallback。
5.3 Voxel 与 Surfel 的双 fallback:在 Surface Cache 之外,Lumen 还维护两层补充结构 — Voxel Cone Tracing (VCT) 用于 mirror/glossy 反射,Surfel Cache 用于动态物件辐照。Voxel 是一张 mip-chain 体素图(典型 256³ 至 1024³)做 cone trace;Surfel 是附着在动态几何表面的辐照点云。每帧增量更新,代价是 0.5-1.5ms per pass。
5.4 Mesh SDF 与屏幕空间回退:几何距离场用 SDF bake + 运行时 BVH update,屏幕空间回退用 SSR (Screen Space Reflection) 接管镜面反射。Lumen 在渲染线程 dispatch 时,按**(DepthPriority:Software>Hardware>VCT>Surfel>SSR)** 顺序择优,哪个先返回有效结果就用哪个,保证视觉总有 fallback。
把 Lumen 移植到自研引擎需要做的工程量:Surface Cache + Mesh SDF 大约 6000 行 shader + 4000 行 C++;Voxel Cone Tracing 约 2000 行 shader;Surfel 维护约 1500 行 C++ + 500 行 compute。整体模块 size 1.2-1.5 万行,需要 3-4 个图形程序员 9-12 个月,是任何想做 hybrid 实时光追的引擎的必做工作量。
但 Lumen 不开源,Unity 6 HDRP 的 Adaptive Probe Volumes (APV) 是另一种 hybrid 方案:probe grid + sky occlusion + baked lightmap + runtime update,probe 半径参数化 4-12 米。APV 与 Lumen 在工程实现上有 60-70% 的相似度,但 probe grid 替代 surface cache 的设计哲学更接近 GI cache 而非 full-path-tracer。
RT 路径输出通常是每像素 1-4 sample 的低样本 radiance 估计——这意味着每个像素都带显著 noise,远远达不到出版画质。降噪器 (denoiser) 是 RT 渲染管线里仅次于 RT 本身与 ReSTIR 之后的第三大工程模块,预算通常占总帧时间的 1.5-3ms,在 RT-heavy 场景里甚至更多。
主流降噪器选项:
6.1 OIDN (Open Image Denoise):Intel 开源降噪器,基于深度学习的 CNN 模型。输入是 noisy radiance + albedo + normal,输出是 denoised result。优点是开源免费、CPU/GPU 双实现、CPU fallback 友好;缺点是逐帧独立不感知时序。
6.2 OptiX Denoiser:NVIDIA 自家方案,基于 4-frame temporal accumulation 的 DNN 模型。优势是 temporal stability、4-sample 输入已经能给出近乎无噪结果;缺点是绑死 NVIDIA 生态,在 AMD/Intel GPU 上要么用 fallback 路径要么不用。
6.3 自研时域降噪:很多引擎选择自研 — UE 的 PostProcess 中 TemporalAA + RT 专用 PostPass、Unity 的 HDRP AOV-based denoise、id Tech 的 motion-vector-aware reprojection + 5x5 bilateral blur。自研的优势 是能完全控制带宽、保 stable motion vector、避免 ghosting;劣势是 1-2 名图形程序员 3-6 个月的精修。
6.4 高斯泼溅与神经辐射缓存:2024-2026 年快速兴起的方案是用 Gaussian Splatting 或 neural radiance cache 作为降噪替代品 — 它们不是"denoise noisy image",而是**"直接拟合 radiance function"**。Google 的 NeRF-style cache 在 1080p 下用 2-4ms 给出近乎 SOTA 渲染质量,但需要离线预训练。对游戏引擎来说,神经辐射缓存目前还不算成熟 — 适合作为内部 R&D 项目而非主路径。值得注意的是 NVIDIA 的 NGX Neural Radiance Cache 在 2025 年下半年公布 SDK 给合作伙伴测评,Unity 与 Epic 都在评估是否纳入主流版本;预计 2027-2028 才会成为可选主路径。
6.5 OIDN 工作流集成细节:OIDN 在引擎里的集成通常做三件事:首先,把 albedo + normal + depth + motion vector 从 G-Buffer 拼成 RGB Float32 输入纹理,这一过程自身耗时 ~0.3-0.5ms,常见做法是合并到 Denoiser Prepass 而非独立渲染;其次,OIDN DNN 在 GPU 上用 SYCL 或 Vulkan Compute 跑,FP16 输入 / FP16 输出,带宽上对 1080p 是 ~70MB 一帧的临时存储;第三,结果输出到 denoised radiance texture 供后续 Composite 采样。集成最难的部分 是与时域 TAA buffer 的合并逻辑——OIDN 输出应该与前几帧 temporal AA 累加器 blend,blend ratio 决定 flicker 抑制与 ghosting 程度,典型值是 0.15-0.25 历史帧权重。
降噪器工程里最容易踩的坑:
把第三到第六节的内容拼成一台完整的 RT-capable 渲染管线,2026 年的工业实践收敛到 "Surface Cache (Lumen-style) + ReSTIR GI/PT (样本复用) + Hardware DXR/Vulkan (硬件 RT) + OIDN/OptiX (降噪守门)" 四件套。下面描述典型装配在引擎中的落位:
7.1 Frame Timing Budget (以 60fps / 16.6ms 为基准): G-Buffer 1.5-2.5ms → RT Acceleration Structure refit 1.5-2ms → ReSTIR GI / DI 3-4ms → Lumen Surface Cache lookup 1.5-2ms → Down-sample + SSGI 0.5-1ms → Denoiser pass 1.5-2.5ms → Composite to HDR target 0.5-1ms → Upscale (DLSS / XeSS) 1-1.5ms。合计 12-16ms,在 60fps 预算内留 0.5-4ms slack 给 CPU bottleneck or frame pacing。
7.2 数据流图:
7.3 平台分级:
7.4 资产与 Mesh SDF:Lumen 的 SDF bake 离线完成,运行时只需做 mesh dynamic change 的 incremental update。ReSTIR 需要的 history buffer 在显存预算里 1-4 MB per resolution tier,可忽略。
7.5 Debug 与 Profiling:这套架构必须配套 RT 专用 profiler — RenderDoc 加 PIX for DXR 都能 capture BVH traversal 与 RT 状态;但 ReSTIR 的 weight chain 调试必须用 inline NSight compute shader trace;Lumen 的 surface cache 用 UE 自带的 Lumen Visualizer。预算周期通常需要 1-2 周专做 profile-to-budget。
把整套装配作为一份工程计划:scope = 1.5-2 万行新代码 + 0.5-1 万行 mesh SDF 工具 + 0.3-0.5 万行 profiler 集成。Workload = 4-6 名图形程序员 12-18 个月 + 1 名 tech artist 6-9 个月 + 1 名 TA 6-9 个月。这是当前 AAA 引擎从零搭出 RT-capable 渲染管线的真实工作量,低估这项 cost 的项目通常 24+ 个月才能稳定 release,行业经验。
实时光追不是"加一个开关就行"的特性,它在项目立项早期就要做决策。最严重的工程失误是在 ship 前 6 个月才决定启用 Lumen——因为它会影响资产管线、美术工作流、shader 编写约束、性能预算四方面。立项时的 5 个关键决策:
8.1 立项时是否承诺实时光追? 默认 yes,但要给非 RT path 留出完整降级方案(baked GI + SSR)。预算陷阱:承诺了 RT 但没承诺降级 = mobile 与 Steam Deck 玩家投诉;承诺了 RT 但只做最贵的 RTX 4080+ 才开 = 90% 玩家用不到。
8.2 资产管线是否用 Nanite/Virtualized Mesh? Lumen 深度依赖 surface cache,要求 mesh 不能有 micro-geometry,必须 Nanite-style 或 baked LOD。
8.3 美术规范是否允许 MeshShader / RT-aware material? 一些美术常规(超出场景包围盒的 sky dome、跨多 mesh 的 blended material)在 RT path 下要重做或加 patch。artist pipeline 培训成本 6-8 周。
8.4 Profiler 与 Budget 文化:每个 shader pass 必须有 nsight trace budget,每帧 16ms 必须分解到具体 pass 上 RT-aware profile。没有这个文化的团队开 RT 后会严重超 budget。
8.5 Frame Pacing:RT 帧时间方差大,30fps 时 frame time 32ms 比 60fps 16ms 更难调。Adaptive Scaler (DLSS / XeSS / FSR) 是 frame pacing 的事实标准;DLSS Ray Reconstruction 3 在 2025 年发布后,把 denoise + upscale 合二为一,中端 GPU 上能腾出 0.5-1ms 给别处。PlayStation 5 Pro 的 PSSR(PlayStation Spectral Super Resolution)在 2025 年底公布 SDK 后也加入这条赛道。
8.6 Memory Bandwidth 预算:ReSTIR history buffer 在 4K 分辨率是 ~64MB / frame,Surface Cache 在 200m 半径内是 ~32MB,Voxel 在 1024³ 是 ~512MB。总 RT 相关显存 600-800MB 对 RTX 4080 (16GB) 不算压力,但对 8GB 主流卡就需要 LOD swap 或者降级到 720p。Resource Residency Manager 是必备的子系统——把 RT cache 按 visibility 排序加载,Lumen 在远处关卡迁移时会做 evict + bake on demand,但 bake 通常比运行时 trace 慢 5-10 倍,所以 eviction policy 要尽量保守。
写到这里读者可能会问:"我的引擎是中等规模团队,资源不可能像 3A 一样搭,这条路走得通吗?" 答案取决于团队规模。5 人图形组的 indie 工作室 只能做 ReSTIR DI + 简单 Lumen-lite(缩减版 surface cache)+ OptiX/OIDN 降噪,10-20 人 AA 工作室 可以做完整 Lumen + ReSTIR GI,50+ 人旗舰工作室 才走得通完整 Lumen + ReSTIR PT + 自研降噪 + 神经缓存。中间配置建议先做 DI + GI + 简单降噪,把 PT 与神经缓存推到后续 milestone。
8.7 与 Build Pipeline 的耦合:RT 启用的项目对 build pipeline 的影响经常被低估。Shader Permutation 用于 DXIL 与 SPIR-V 双套交叉编译,RT shader 的 permutation 数比常规 shader 多 3-5 倍——这意味着 build server 时间和 CI cycle 都拉长。Project Settings → Rendering → Shader Compilation Pipeline 必须显式启用 DXC + SPIRV-Cross 链路,cook time 预算要比 non-RT 项目多 1.5-2.5 倍。Asset Cooker 要能把 BLAS 的输入 mesh data 离线预签名,运行时只做 BLAS refit 而非完整重建。这些是 ship 前才发现的硬性约束——立项即决定,不要 ship 前半年再补。
把全文的核心 takeaway 凝成一份可落地的实践清单,按 ROI 优先级排列:
一句话摘要:实时光追在 2026 年已经从"GPU demo 特性"升级为"主流渲染管线的第四条纵向支撑",工程化路径收敛到"DXR/Vulkan 硬件 RT 负责几何遍历 → ReSTIR 家族负责样本复用放大 bounce 深度 → Lumen 风格的 surface cache + voxel/surfel/SSR fallback 保证视觉连续性 → OIDN/OptiX 降噪器作为质量守门员"的四件套装配,任何要在这条主线上做工程的图形程序员应当按 ReSTIR DI 优先 → Lumen-Lite 缩减缓存 → 跨平台降噪器选择 → Mesh SDF 资产管线这一顺序落地 ROI 最高的模块。
Conversation
0 条