加快程序纹理的生成
最近，我开始研究在程序生成的太阳系中进行的游戏。经过一番学习之后（之前都没有使用Scala，OpenGL 2 ES或Libgdx进行过学习），我进行了一个基本的技术演示，您将围绕一个程序化纹理的行星旋转： 我遇到的问题是纹理生成的性能。我正在做的事情的简要概述：行星是已变形为球体的立方体。每一面都应用anxn（例如256 x 256）纹理，该纹理捆绑在一个8n xn纹理中，并发送到片段着色器。最后两个空格未使用，它们仅用于确保宽度为2的幂。使用在'Simplex'论文中链接的2012年更新的单纯形噪声算法，当前正在CPU上生成纹理。噪音消失了。我用来测试算法的场景包含两个球体：行星和背景。两者都使用由六个八度的3D单工噪声组成的灰度纹理，因此，例如，如果我们选择128x128作为纹理大小，则有128 x 128 x 6 x 2 x 6 =约120万个噪声函数调用。 您最接近地球的是屏幕快照中显示的内容，并且由于游戏的目标分辨率为1280x720，这意味着我希望使用512x512纹理。结合这样的事实，实际的纹理当然比基本噪声要复杂（白天和黑夜的纹理，将基于阳光和镜面反射的片段着色器混合在一起。我需要大洲的噪声，地形颜色变化，云层，城市的灯光等），而我们正在寻找的是512 x 512 x 6 x 3 x 15 =仅此星球就需要7,000万个噪声的东西。在最终游戏中，行星之间旅行时会有活动，所以等待5或10秒（可能是20秒）是可以接受的，因为我可以在旅行时计算背景纹理，尽管显然速度越快越好。 回到我们的测试场景，我的PC上的性能并不是太糟糕，尽管考虑到最终结果将比原来差60倍，但仍然太慢了： 128x128 : 0.1s 256x256 : 0.4s 512x512 : 1.7s 这是在我将所有对性能至关重要的代码移至Java之后的事情，因为在Scala中尝试这样做要差得多。但是，在我的手机（三星Galaxy S3）上运行它会产生更成问题的结果： 128x128 : 2s 256x256 : 7s 512x512 : 29s 已经太长了，这甚至没有考虑到最终版本将是分钟而不是秒的事实。显然需要做些事情。就个人而言，我看到了一些潜在的途径，尽管我并不特别热衷于其中任何一种： 不要预先计算纹理，而是让片段着色器计算所有内容。可能不可行，因为有一次我将背景作为具有像素着色器的全屏四边形，并且手机上的速度约为1 fps。 …