Java3D/OpenGL 中角点网格的内存高效实现
假设我在 corner-point-grid 中有 NX*NY*NZ 单元格。我还有一个 NX*NY*NZ 布尔值掩码，它告诉我必须绘制网格的哪些单元格。
我想使用尽可能少的内存在Java3D（或OpenGL，最后没关系，因为下面的概念是相同的）中创建一个高效的索引四元数组。
为了简单起见，我跳过声明每个面的法线，实际上我不需要它们，因为我使用的是平面阴影并且没有照明。
我为每个单元格设置了一种颜色（这是基于每个单元格的属性）。
因此，我列出了需要根据单元格蒙版绘制的面孔。
我发现自己多次重复同一点（属于不同的面孔），以便能够为每个面孔赋予颜色。
您对如何提高效率有什么建议吗？
Say I have NX*NY*NZ cells in a corner-point-grid. I have also a mask of NX*NY*NZ booleans that gives me which cells of the grid I have to draw.
I would like to create an efficient indexed quad array in Java3D (or OpenGL, it does not matter at the end, since the concepts below are the same) using less memory as possible.
For sake of simplicity I'm skipping to declare the normals of each face and really I do not need them since I'm using a flat shading and no lighting.
I have a color for each cell (this is based on a per-cell property).
Thus I'm listing the faces I need to draw based on the cells mask.
I find myself repeating the same point (belonging to different faces) several times to be able to give each face a color.
Do you have any hint about how to make it more efficient?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您有很多选择：
首先，您可以使用几何着色器动态生成顶点，但这只有在您拥有相当高端的系统时才有效。
另一种选择是分多次绘制对象。如果您不关心填充率，您可以只沿着 xyz 平面绘制四边形的集合，这些四边形的集合直接读入体积数组。
遵循同样的推理思路，您还可以对对象进行光线投射以在片段着色器中渲染它，这可能会更快，具体取决于 NX、NY 和 NZ 的大小。
如果必须绘制四边形，另一种可能性是单独存储顶点数据，然后使用顶点着色器从纹理读取来确定颜色坐标。您可以通过多个渲染通道分割绘制整个网格。
如果您需要存储带有顶点的颜色数据，您可以尝试的最后一件事就是存储每种颜色的 4 个副本以及每个顶点在 xz 方向上的坐标的 2 个分量。要绘制整个阵列，您需要执行 6 次遍历，立方体的每个面各一次。通过修剪不可见面的通道可以大大优化这一点。
当然，最终的选择取决于您需要绘制的数据量、您的目标硬件类型以及您希望在该项目上花费多少工作量。
You have many options:
First, you could use a geometry shader to dynamically generate vertices, though this will only work if you have a fairly high end system.
Another option is to draw your object in multiple passes. If you don't care about fill rate, you could just draw a collection of quads along the xyz planes which read into the volume array directly.
Following along the same line of reasoning, you could also ray cast the object to render it in a fragment shader, which could be faster depending on the size of NX, NY and NZ.
If you have to draw quads, another possibility is to store the vertex data separately, then use vertex-shader read-from-texture to determine the color coordinates. You could split up drawing the whole grid over multiple rendering passes.
If you need to store the color data with the vertices, the last thing you could try is storing 4 copies of each color together with 2-components for the coordinate of each vertex in the x-z direction. To draw the whole array you would do 6 passes, one for each face of the cube. This could be substantially optimized by pruning out the passes for the faces which are invisible.
The ultimate choice of course depends on the amount of data you need to draw, the type of hardware you are targeting and how much work you want to spend on this project.