WebGL 中的高效 VBO 分配
我正在编写一个通过算法生成几何图形的 WebGL 应用程序。几何图形将由 4-150 个对象组成，每个对象由 16 到 2048 个点组成，通过 drawElements 绘制为 TRIANGLE_STRIP。几何图形在大多数帧中都是静态的，但需要根据用户输入进行动画处理。在这些帧中，当几何体更新时，可以添加或删除点/三角形。在程序的生命周期中还需要添加/删除对象。
在这种情况下分配/更新 VBO 最有效的方法是什么？我很确定我应该使用 DYNAMIC_DRAW 和 bufferSubData 来更新每个对象，但是我是否想要过度分配一些巨大的 VBO（假设每个对象点数的最坏情况）并将每个对象定义为偏移量（对象数量 * 每个对象的最大大小），然后在最好的情况下有大量已分配的未使用的 VBO 内存？或者我应该尝试另一种方法？或者就内存占用而言，这是否足够小，以至于我想太多了？
I'm writing a WebGL application that algorithmically generates geometry. The geometry will consist of between 4-150 objects, each consisting of somewhere between 16 and 2048 points, drawn as a TRIANGLE_STRIP through drawElements. The geometry will be static most frames, but will need to be animated in response to user input. In these frames when the geometry is updated, points/tris may be added or removed. Objects will also need to be added/removed over the program's lifetime.
What's the most efficient way to allocate/update VBOs in this context? I'm pretty sure I should be using DYNAMIC_DRAW and bufferSubData to update each object, but do I want to over-allocate a few huge VBOs (assuming the worst-case in terms of points-per-object) and define each object as an offset (object number * max size per object) and then have lots of allocated un-used VBO memory in the best-case? Or is there another approach I should try? Or is this small enough in terms of memory footprint that I'm over-thinking?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这确实是要走的路。实际上，您希望对对象使用双倍甚至三倍缓冲，即有一个 VBO 绑定用于绘图，同时用新数据更新另一个 VBO 的内容。在glMapBuffer之后，可以从进程中的所有线程访问内存映射，因此您可以让工作线程更新“后”顶点缓冲区，而渲染线程正忙于绘制当前帧。
您是否评估过您正在处理的最坏情况的内存占用？根据你的数字，我打赌它将低于 16MiB（150 个对象 * 2048 点 * 每点 3 个双精度浮点 * 每个双精度 8 个字节 = 7.4 MiB，如果使用单精度浮点则仅为 3.7MiB）。与现代显卡提供的数百 MiB RAM 相比（我的 2006 GeForce 8800GTX 有 768MiB RAM，我的 Radeon HD6570 有 1024MiB(=1GiB)）。
This is indeed the way to go. Actually you want to use double or even triple buffering for your objects, i.e. have one VBO bound for drawing, while you update the contents of the other with the new data. After glMapBuffer the memory map can be accessed from all threads in the process, so you can have a worker thread updating the "back" vertex buffer, while the rendering thread is busy drawing the current frame.
Did you evaluate the worst case memory footprint you're dealing with? Given your numbers, I bet it will be below 16MiB (150 objects * 2048 points * 3 double precision floats per point * 8 bytes per double = 7.4 MiB, only 3.7MiB if single precision floats are used). Compare this to the several hundreds of MiB of RAM modern graphics cards offer (my 2006 GeForce 8800GTX has 768MiB RAM, and my Radeon HD6570 has 1024MiB(=1GiB).