OpenGL地形系统CPU与GPU高度值读取存在微小偏差问题问询

快速概述 #

开发了基于四叉树的地形渲染系统，地形贴片生成后在顶点着色器中采样高度图确定顶点高度，CPU侧执行完全相同的计算用于物体放置等逻辑。
加入程序化物体放置系统后发现物体存在微小错位，调试时在地形上方渲染十字标模型：十字标高程为CPU侧读取的高度值，地形网格顶点位移由着色器计算。为排除简单偏移问题，为每个高度值添加了奇偶间隔，因此调试画面中突兀的悬崖是预期效果，沉入地形下方的十字标是问题所在。
明确使用了GL_NEAREST采样模式获取原始高度值，测试中仍存在十字标沉入地形下方、与实际地形高度不匹配的问题，CPU和GPU侧的高度图均为float类型数组。

数据存储方式 #

CPU侧使用vector<float>存储高度值，上传到GPU时使用GL_RGB32F格式的GL_FLOAT缓冲区。浮点数未做归一化处理，地形高度值通常在-100到500之间。

着色器侧数据访问逻辑 #

初始实现如下：

vec2 terrain_heightmap_uv(vec2 position, Heightmap heightmap)
{
    return (position + heightmap.world_offset) / heightmap.size;
}

float terrain_read_height(vec2 position, Heightmap heightmap)
{
    return textureLod(heightmap.heightmap, terrain_heightmap_uv(position, heightmap), 0).r;
}

顶点着色器核心逻辑：

void main()
{
    vec4 world_position = a_model * vec4(a_position, 1.0);
    vec4 final_position = world_position;

    // 顶点对齐到网格
    final_position.x = floor(world_position.x / a_quad_grid) * a_quad_grid;
    final_position.z = floor(world_position.z / a_quad_grid) * a_quad_grid;

    final_position.y = terrain_read_height(final_position.xz, heightmap);

    gl_Position = projection * view * final_position;
}

为排除位置计算方式差异的影响，使用与C++读取高度完全一致的硬编码值测试，结果完全一致：

return texelFetch(heightmap.heightmap, ivec2((position / 8) + vec2(1024, 1024)), 0).r;

应用层数据访问逻辑 #

C++侧高度读取代码如下：

inline float get_local_height_safe(uint32_t x, uint32_t y)
{
    // 该宏仅将x和y裁剪到高度图边界，不会影响结果
    BB_TERRAIN_HEIGHTMAP_BOUND_XY_TO_SAFE;

    uint32_t i = (y * _size1d) + x;

    return buffer->data[i];
}

inline float get_height_raw(glm::vec2 position)
{
    position = position + world_offset;

    uint32_t x = static_cast<int>(position.x);
    uint32_t y = static_cast<int>(position.y);

    return get_local_height_safe(x, y);
}

float BB::Terrain::get_height(const glm::vec3 position)
{
    return heightmap->get_height_raw({position.x / heightmap_unit_scale, position.z / heightmap_unit_scale});
}

已尝试的排查方案 #

• 缓冲区对比：导出vector中前数百个数值，与通过Nvidia Nsight抓取的GPU侧上传的浮点缓冲区数据对比，两者完全一致，无舍入/精度误差
• 采样方式测试：先后尝试texture、textureLod和texelFetch三种采样接口排除采样问题，三者返回结果完全相同
• 舍入测试：对所有高度值做舍入处理后，两者完全对齐，大概率为浮点精度问题
• 位置对齐测试：先后尝试对位置做round、floor、ceiling处理，确保位置始终映射到同一个texel；尝试添加epsilon偏移排除位置精度误差
• 高度图尺寸测试：尝试多种不同尺寸的高度图，问题依然存在
• 高度图图案测试：创建带特定图案的高度图，确认不存在位置偏移问题

核心原因 #

1. 取整规则不一致：C++中static_cast<int>对正数是向零截断，而GLSL的坐标转换、整数构造逻辑在部分驱动下，对刚好处于整数边界的浮点值处理规则和CPU侧存在差异，微小的浮点误差就会导致两端取到不同的texel索引。
2. 浮点运算精度差异：CPU通常用80位扩展精度做中间浮点计算，GPU普遍使用32位单精度，坐标缩放、偏移的运算顺序差异会导致最终映射的索引不一致。
3. 冗余纹理格式引入的开销：用GL_RGB32F存储单通道高度数据，部分驱动会对GB通道做填充处理，可能引入不必要的精度损耗。

修复方案 #

1. 统一两端取整逻辑：将C++侧的static_cast<int>替换为明确的floor运算，保证和GLSL侧取整规则一致：

uint32_t x = static_cast<uint32_t>(floor(position.x));
uint32_t y = static_cast<uint32_t>(floor(position.y));

同时确保CPU和GPU侧坐标缩放、偏移的运算顺序和参数完全相同。
2. 更换为单通道纹理格式：把高度图存储格式从GL_RGB32F替换为GL_R32F单通道浮点格式，避免冗余通道带来的潜在问题。
3. 添加边界偏移：在坐标转换为整数索引前，两端都添加极小的固定偏移（比如1e-5f），避免浮点精度误差导致的边界取整错误。
4. 统一浮点精度：CPU侧所有高度计算强制使用32位单精度浮点，所有常量都添加f后缀，避免双精度隐式转换带来的差异。

内容的提问来源于stack exchange，提问作者Mario