将顶点和索引缓冲区上传到 GPU
我正在创建一个地形引擎，目前我正在将整个地形 VB（顶点缓冲区）和 IB（索引缓冲区）上传到 GPU，因为地形并不大。目前是 256x256。
现在，假设我想创建一个使用柏林噪声来生成高度图的程序地形。
当然，我可以生成“补丁”并将补丁的所有 VB 和 IB 一次性上传到 GPU，但是当玩家移动得很远并且必须生成新补丁时，我将不得不生成新补丁并上传他们到GPU。我脑子里的困惑或者问题是：
上传VB和IB到GPU是不是很慢？数据上传到GPU时，玩家是否会注意到闪烁？
如果我将补丁的 VB 和 IB 逐渐上传到 GPU，而不是一次性全部上传，性能会不会更好？基本上我是在问 VB 和 IB 的大小是否很重要。
任何有关此概念的信息将不胜感激。
谢谢！
I am creating a terrain engine and currently I am uploading the whole terrain VB (Vertex Buffer) and IB (Index Buffer) to the GPU at once since the terrain is not huge. It's 256x256 at the moment.
Now, let's say I want to create a procedural terrain which uses perlin noise to generate the heightmap.
Of couse I could generate "patches" and upload all of the VB and IB of the patches at once to the GPU, but as the player moves far away and new patches have to be generated, then I would have to generate new patches and upload them to the GPU. The confusion or problems that I have in my mind are:
Is it slow to upload VB and IB to the GPU? Would the player notice a flicker when data is uploaded to the GPU?
Would the performance be better if I upload the VB and IB of the patches gradually to the GPU instead of all of them at once? Basically I'm asking if the size of the VB and IB matters much.
Any information on this concept would be greatly appreciated.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常，您会将地形分成几个小块，并在玩家移动时对其进行流式传输。在我的地形引擎中，我从来没有将索引缓冲区放在缓冲区对象中，因为 LOD 机制不断改变绘制的顶点以及绘制的顺序以改进早期 Z。256×256 是一个合理的补丁大小，特别是如果您使用像四叉树这样的结构。
因此，您可以做的是加载 9 个地形补丁，每个补丁的大小以某种方式选择，使可见范围结束于中心补丁周围边界的某个位置。
当玩家在 C 区域移动时，可见范围确保他无法看到装载区域之外的区域。一旦玩家移动到另一个补丁，从另一侧环绕补丁，即将
图块 A、B、C 重新映射到
其中 A'、B'、C' 回收 A、B、C 的内存，但用新内容。由于玩家从远端移动到新的 C 补丁中，即只能看到新补丁的较近部分，因此您可以在多个帧上加载 A'、B'、C' 的内容。
回答你的两个问题：
上传几何图形实际上是一个相当快的过程，所以这并不是什么阻碍。您不会看到闪烁，因为数据上传发生在渲染帧之间，并且只有在数据更新后，绘图命令才会开始。
上传内容的方式不会影响渲染性能。然而，它会影响加载地图本身所需的时间。如果您希望玩家能够穿越广阔的世界，而无需在中间经历烦人的加载阶段，则必须根据需要上传较小的补丁。
Usually you will split up your terrain in several small patches, which you'll stream as the player moves along. In my terrain engine I never put the index buffer in a buffer objects, as the LOD mechanism constantly changes which vertices are drawn, and the order of what's drawn to improve early Z. 256×256 is a reasonable patch size, especially if you employ a structure like quadtrees.
So what you can do is having 9 terrain patches loaded, the size of each patch chosen in a way, that the visible range ends somewhere around the borders around the center patch.
As the player moves around in the C patch, the visibility range makes sure that he can't look beyond the loaded area. Once the player moves into another patch, wrap around the patches from the other side, i.e.
will remap the tiles A, B, C to
Where A', B', C' recycle the memory of A, B, C but fill it with new content. Since the player moves into the new C patch from the far end, i.e. just can see the closer parts of the new patches you can load the contents of A',B',C' over several frames.
To answer your two questions:
uploading geometry is actually a rather fast process, so that's no show stopper. You won't see flicker, as the data uploads happen between rendering frames and only after the data has been updated the drawing commands will commence.
The way you upload stuff has no impact on the rendering performance. However it has an influence upon how long it takes to load a map itself. If you want players being able to traverse large worlds without annoying loading phases inbetween you'll have to upload smaller patches on demand.