【问题标题】:Uploading Vertex and Index buffer to the GPU将顶点和索引缓冲区上传到 GPU
【发布时间】:2011-06-09 11:57:23
【问题描述】:

我正在创建一个地形引擎,目前我正在将整个地形 VB(顶点缓冲区)和 IB(索引缓冲区)一次上传到 GPU,因为地形并不大。目前是 256x256。

现在,假设我想创建一个程序地形,它使用柏林噪声来生成高度图。

当然,我可以生成“补丁”并将补丁的所有 VB 和 IB 一次上传到 GPU,但是当玩家移动很远并且必须生成新补丁时,我将不得不生成新的补丁补丁并将它们上传到 GPU。我心中的困惑或问题是:

  1. 将 VB 和 IB 上传到 GPU 是否很慢?当数据上传到 GPU 时,玩家会注意到闪烁吗?

  2. 如果我将补丁的VB和IB逐步上传到GPU而不是一次全部上传,性能会更好吗?基本上我在问VB和IB的大小是否重要。

任何有关此概念的信息将不胜感激。

谢谢!

【问题讨论】:

    标签: opengl gpu terrain vertex-buffer


    【解决方案1】:

    通常你会将你的地形分割成几个小块,随着玩家的移动,你会流式传输这些块。在我的地形引擎中,我从不将索引缓冲区放在缓冲区对象中,因为 LOD 机制不断更改绘制哪些顶点,以及绘制的顺序以改善早期 Z。256×256 是一个合理的补丁大小,特别是如果您使用类似四叉树的结构。

    所以你可以做的是加载 9 个地形补丁,每个补丁的大小以某种方式选择,可见范围在中心补丁周围的边界附近结束。

       |   |
    ---+---+---
       | C |
    ---+---+---
       |   |
    

    当玩家在 C 补丁中四处移动时,可见范围确保他无法看到加载区域之外。一旦玩家移动到另一个补丁,从另一侧环绕补丁,即

     A |   |
    ---+---+---
     B | X-> C
    ---+---+---
     C |   |
    

    将图块 A、B、C 重新映射到

           |   | A'
        ---+---+---
           ->C | B'
        ---+---+---
           |   | C'
    

    其中 A', B', C' 回收了 A, B, C 的内存,但是用新的内容填充它。由于玩家从远端移动到新的 C 补丁中,即只能看到新补丁的较近部分,因此您可以将 A'、B'、C' 的内容加载几帧。

    回答你的两个问题:

    1. 上传几何图形实际上是一个相当快的过程,所以这不是显示停止器。您不会看到闪烁,因为数据上传发生在渲染帧之间,只有在数据更新后,绘图命令才会开始。

    2. 上传内容的方式对渲染性能没有影响。但是,它会影响加载地图本身所需的时间。如果您希望玩家能够穿越广阔的世界而无需在中间进行烦人的加载阶段,则必须按需上传较小的补丁。

    【讨论】:

    • 太棒了,我今晚会做一些测试,看看效果如何。谢谢你非常详细的回答。但是关于“加载地图本身需要多长时间”,让我们假设 VB 和 IB 已准备好上传(缓存在 vram 上),在上传到 GPU 时,VB 和 IB 的大小无关紧要,如果VB可能有1000x1000顶点的补丁,那么我应该注意到快门,对吗?越少,上传到 GPU 的速度越快?
    • @raRaRa:vram 是什么意思?显卡上的RAM?好吧,这就是 GPU RAM,这就是缓冲区对象的全部意义所在。如果它已经加载到系统 RAM 中:是的,它越大,上传时间越长。但最终重要的是上传的顶点总数,无论它们是多个小块还是一个大块,都没有太大区别。如果您渲染的场景需要所有视觉细节,则无论哪种方式都必须上传,然后才能绘制任何内容。
    • 我的意思是系统内存。但是,是的,我的意思是逐步上传许多小补丁而不是一次上传所有小补丁。
    • @raRaRa:逐渐上传也称为流式传输,相当普遍。例如,这就是 Google 地球的工作原理。只要您上传/替换看不见的几何图形就可以了。您不会看到闪烁,最糟糕的情况是帧率下降。但只要你保持在 40 FPS 左右,没人会注意到,大多数人直到低于 20 FPS 才会看到眼前的幻灯片。
    猜你喜欢
    • 1970-01-01
    • 2018-11-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-08-23
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多