type
status
date
slug
summary
tags
category
icon
password
前言
总体来说，类似于哈希查表。
因为本质上都一样，都是为了解决 数据范围很大量很大，但是有效数据比较少的场景。(也都是通过一个介质去查找最后的数据)
- 哈希表场景：假设要存储 100 个用户数据，但用户 ID 范围是 0~1000000（大范围），直接建一个 1000000 长度的数组存数据，99.99% 的位置都是空的（浪费空间）。
- VLM 场景：假设场景范围是 1000 米 ×1000 米（大范围），但只有建筑物内部、地面等区域需要存储间接光数据（有效数据稀疏），直接建一个覆盖全场景的 3D 纹理，90% 的体素都是空的（浪费显存）。
存储结构
索引图（t_vlm_indirect）：“地址簿” 纹理，存储 “砖的位置信息”
通常是2D纹理。
每个像素的内容：
float4类型，存储 “当前位置对应的 VLM 砖（Brick）的基础信息”，4 个分量定义为：float4 brick_offset_size = (x, y, z, w);
// x/y/z：砖在“砖纹理”中的起始偏移（整数，范围0~砖纹理分辨率）
// w：砖的“有效体素大小”（如4，表示砖内有效数据是4x4x4体素）
注意：为了节省空间，像素值存储的是0~1 的浮点数（而非直接存整数），因此采样后需要 ×255 还原为原始整数
如下图：
其作用是：作为 “地址簿”，告诉引擎 “世界空间中的某个点，对应到砖纹理中的哪一块砖”。
2.砖（Brick）纹理图
- 纹理类型：3D 纹理，分辨率通常是：
- brick_count_x/y/z ：X/Y/Z 方向的砖数量；
- padded_size ：带 Padding 的砖大小（有效大小 + 1，如有效大小 4→5）。
(brick_count_x * padded_size) × (brick_count_y * padded_size) × (brick_count_z * padded_size)
其中：
就是xyz三个方向的 砖块的数量*砖的长度
- 砖（Brick） 的结构：整个 3D 纹理被划分为多个独立的 “砖”，每个砖是一个小立方体：
- 有效体素：w × w × w（w即索引图的brick_offset_size.w，如 4x4x4），存储实际的 SH 系数；
- Padding 体素：在有效体素外围加 1 层（如 4x4x4→5x5x5），用于避免采样时的边缘误差（硬件插值需要访问相邻体素）。
怎么找呢
这个应该是的 应该！！ 不保真！