【问题标题】:Best CLOD Method for Planet Rendering行星渲染的最佳 CLOD 方法
【发布时间】:2023-03-20 23:21:01
【问题描述】:

我目前正在撰写我的论文,它是一个渲染行星大小地形的引擎。

我仍在完成我的研究,我遇到了很多关于这个主题的东西,问题是我无法决定我应该使用哪种 LOD 方法。

我知道 Ulrich 的 geomipmapping、几何剪贴图 (GPU) 和分块 LOD,它们在大型地形上运行良好,可用于渲染立方体的 6 个面,然后通过 this method“球化”立方体,我了解如何使用 C++/OpenGL/GLSL 在 GPU 上实现所有这些方法(使用 ROAM 之类的方法或任何其他不使用立方体的方法是我无法企及的,因为纹理是一种痛苦)。

所以,我没有时间实施所有方法,看看哪种方法最好,更适合行星规模,我在这里问是否有人进行过这种比较并帮助我决定我应该实施和使用哪种方法(我的导师有点疯狂,想让我用二十面体做一些事情,但除非使用 ROAM,否则我无法理解该方法)

无论如何,如果您能帮助我决定或有任何其他建议或方法,我将不胜感激。一个条件是该方法应该能够实现GPU端(至少大部分)以防止CPU瓶颈。

另一个请求是,我知道在获取大量地形细节时,浮点数的精度存在数值问题,我不知道如何解决,我在论坛上阅读了解决方案,但无法获得了解如何实现,我忘记了那个线程,我想知道如何解决这个精度问题。

PD:对不起我的英语。

[编辑] 我目前正在阅读一些矩阵变换来解决浮点精度、z 冲突问题、使用动态 z 值进行截锥剔除以及块的数据表示(使用带浮点的补丁空间及其在世界坐标为双倍)所以我想我可以很容易地解决精度问题。我仍然需要将 LOD 方法与您的意见和建议进行比较,以决定哪种方法更适合这个项目。考虑实现难度、视觉质量和性能,我想要最好的。

我忘了提到的是,这一代是混合的,我的意思是,我应该能够完全使用 GPU(动态计算的高度)和/或使用基础高度图图像并使用 GPU 添加细节(顶点着色器)。纹理将是我稍后会麻烦的部分,现在我很高兴只使用取决于高度的颜色,或者可能使用在片段着色器上生成的某种噪声纹理。

【问题讨论】:

  • 浮点数非常精确。您需要什么精度?
  • 好吧,我在这里得到了解释 opentk.com/node/491 所以我认为这部分已经解决了:D

标签: c++ opengl rendering terrain level-of-detail


【解决方案1】:

最后,经过大量研究,我可以得出结论,正如之前有人所说,没有普遍“最好”的方法。但是我的研究使我了解了以下内容:

取决于您最终将使用的网格:

  • Spherified Cube: 任何具有四叉树实现的 LOD 方法都可以正常工作,您只需要注意面之间的边界等特殊情况,在这种情况下,您的四叉树必须有一个指向邻居的指针每个级别中的 adycent 面孔。
  • 任何其他:我认为 ROAM(较新的版本 2.0 或任何其他扩展,如 BDAM、CABTT 或 RUSTIC)会做得很好,但是,这些算法很难使用,需要更多内存并且有点比其他使用立方体的方法慢。

有很多 LOD 方法可以很好地拟合,但我个人排名前 5 位的是:

  1. Continous Distance-Dependent LOD (CDLOD)
  2. GPU Based Geomety Clipmaps (GPUGCM)
  3. Chunked LOD
  4. 使用 OpenGL GPU Tessellation 渲染地形(书籍:OpenGL Insight,第 10 章)
  5. Geometrical MipMapping

每一个都提供了一种独特的地形渲染方式,例如,CDLOD 使用着色器(GLSL 或 HLSL)非常容易实现,但也能够在 CPU 上实现(对于传统硬件),但 Planet Rendering 的目标是在现代 GPU 上发挥最佳性能,因此当您想要挤压 GPU 时,GPUGCM 是最佳选择。它们都非常适用于大型地形的基于数据、程序或混合(基于固定数据或高度图的地形以及通过程序工作添加的细节)渲染。

也存在对基本几何剪辑图方法的球面扩展,但存在一些问题,因为必须使用球坐标对高度图的平面样本进行参数化。

另一方面,分块 LOD 非常适合传统硬件,不需要任何 GPU 端计算即可工作,非常适合大型数据集,但无法实时处理程序数据(可能经过一些修改,它可以)

使用 Tessellation 着色器是另一种技术,非常新,自从 OpenGL 4.x 出来以来,在我看来它可能是最好的,但是,我们正在谈论行星渲染,我们遇到了一个其他方法可以很容易处理的问题它是关于精度的。

除非您只希望顶点之间的精度为 1 公里,否则请使用曲面细分着色器。使用这种方法处理非常大的地形的问题是抖动有点难以解决(或者至少对我而言,因为我是曲面细分着色器的新手)。

Geomipmapping 是一项很棒的技术,它利用了四叉树并且具有较低的投影像素误差,但是,对于行星渲染,您需要设置至少 16 级以上的细节,这意味着您需要(用于拼接图)一些额外的补丁来连接不同的关卡并照顾你邻居的关卡,这可能很难解决,尤其是使用 6 个地形面。

还有一种方法,自己很讲究:"Projective Grid Mapping for Planetary Terrain" 非常适合可视化,但也有缺点,如果想了解更多,请前往链接。

问题:

  • 抖动:当今的大多数 GPU 仅支持 32 位浮点值,这 不能提供足够的精度来操纵行星尺度地形中的大位置。当查看器放大并旋转或移动时会发生抖动,然后多边形开始来回反弹。

    最好的解决方案是使用“Rendering relative to Eye Using” GPU”方法。该方法在“3D Engine”一书中进行了描述 虚拟地球仪的设计”(我相信你可以在互联网上找到它 以及)基本上你必须在其中设置所有位置 在 CPU 上加倍(补丁、剪辑图、对象、截锥体、相机等) 然后 MV 通过设置其翻译以查看者为中心 到 (0, 0, 0)T 并且双精度数以定点编码 使用两个浮点数的小数(尾数)位表示,低 并且通过某种方法高(阅读有关使用 Ohlarik 的实现 和 DSFUN90 Fortran 库)。

    虽然顶点着色器只需要额外的两个 减一加,GPU RTE 使顶点数量翻倍 位置所需的缓冲存储器。这不一定加倍 内存需求,除非只存储位置。

  • 深度缓冲精度:Z-fighting。由于我们正在渲染非常大的地形,在这种情况下:行星,Z-buffer 必须是巨大的,但你为 znear 和 zfar 设置的值并不重要,总会有问题。

    由于 Z-buffer 依赖于一个浮点间隔,而且它也是 线性(尽管透视投影是非线性的)值接近 由于缺乏 32 位精度,眼睛遭受 Z-fighting 花车有。

    解决此问题的最佳方法是使用“对数深度” 缓冲” http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

    对数深度缓冲区可提高深度缓冲区精度 通过使用 zscreen 的对数分布来观察远处的物体。它 用近距离物体的精度来换取远处物体的精度。 由于我们使用 LOD 方法进行渲染,因此远对象需要的更少 精度,因为它们的三角形更少。

值得一提的是,由于四叉树为基础,列出的所有方法(投影网格除外)在进行物理(主要是碰撞)时都非常好,如果您打算制作游戏,这是强制性的。

总之,只需检查所有可用选项并选择您感觉更舒适的选项,我认为 CDLOD 做得很好。不要忘记解决抖动和 Z 缓冲区问题,最重要的是:玩得开心!

有关 LOD 的更多信息,请查看this link

有关球化立方体的完整演示,请查看this link

有关解决抖动和 Z-Buffer 精度的更好说明,请查看this book

希望这篇小评论对您有用。

【讨论】:

  • 您有博客或开发日志或类似的东西吗?我有兴趣了解有关您的项目的更多信息。
猜你喜欢
  • 1970-01-01
  • 2015-10-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-10-12
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多