我正在为我的应用程序使用JOGL（OpenGL for Java），我需要立即在屏幕上绘制大量字符串，而我目前的解决方案太慢了。现在我使用draw3D方法使用TextRenderer绘制字符串，即使是中等数量的字符串（大约300-500），它只会杀死FPS。我开始搞乱在对象纹理上绘制文本，这要快得多，但是它有一些问题。首先，分配所有这些纹理需要大量内存。第二个是我需要找到一种方法来调整纹理的大小，使其仅与字符串一样大，然后将其映射到对象而不进行拉伸。问题在于，所有这些数千个盒子都在使用通过调用列表呈现的单个模型。我不确定在那种情况下是否可以更改每个对象的纹理映射。
我不介意文本看起来是平面还是3D，它只需要放在3D空间中。我更愿意在不牺牲太多速度的情况下以尽可能高的质量呈现文本，因为文本的可读性是应用程序中最重要的部分。此外，几乎所有字符串都不同，重复次数也不多。
所以，我的问题是：我是否在纹理上画出了正确的路径，如果是这样，我怎样才能克服这两个问题呢？还是有另一种方法可以满足我的需求吗？
答案 0 :(得分：1)
根据TextRenderer的确切工作方式，您可以使用显示列表批量处理文本绘图命令。
如果TextRenderer通过具有单个字符字形的纹理并且一次拼接一个字符串字符来工作：它会没事的。只需使用glNewList和glEndList修改您的文字绘图代码即可。定义列表后，只需使用glCallList即可使用它。
但是，如果TextRenderer通过将完整的字符串绘制到纹理中并且每个字符串使用一个四边形来工作 - 显示列表可能不起作用。如果一个批处理中的字符串不能完全适合TextRenderer的缓存，它将删除最近最少使用的字符串以回收一些空间。显示列表只会重新创建所做的OpenGL调用，因此TextRenderer更新字符串缓存纹理所做的工作将会丢失，并且您将得到错误的输出。通过对源代码的快速扫描，我怀疑TextRenderer以这种方式工作。
总结一下：显示列表会大大加快渲染速度，但只有当你没有溢出TextRenderer的字符串缓存纹理并且在定义了显示列表后才使用TextRenderer时才会显示。
如果你不能满足这些限制，你将不得不去做一些硬核并编写你自己的文本渲染器来渲染字形 - 然后它将很容易缓存输出几何并且非常快重新渲染。有一个这样的系统here的示例，其中包含用于创建字体here的工具。它使用LWJGL而不是JOGL，但是如果你想要整合它们，那么两者之间的转换将是你最不担心的 - 它与纹理管理等相关联。