在iOS OpenGL ES 2游戏中,使用几个大的纹理图集还是使用许多小的纹理更好?

我正在开发新的游戏,这次移动到更多的3d对象,并打开gl 2.以前(成功)的游戏是开放的1和大多数2d。 对于ES 2,我正在开发自己的3D引擎。

我的3d艺术家提供.obj的每个都有一个底纹纹理贴图和一个凹凸纹(正常)。 我已经有一种方法将它们全部导入到单个vbo中。 但是结合纹理是一个更具挑战性的问题。

在es 1游戏中,我制作了几个大型纹理图集,并且可以一次装载所有图元。 但是因为我所有的几何体都是盒子,所以很容易将它们转移(less量的顶点)以适应。 我堆叠gfx像俄罗斯方块片,以适应一切。虽然这是一个更大的痛苦,结合纹理,因为有很多更多的顶点,他们已经映射到这些个别的纹理。

我有几个办法来解决这个问题的想法:

  1. 保持分离,但更好地管理纹理图像的加载和释放,以便在加载级别时加载该级别所需的对象所需的图像。 如果我这样做了ios实现处理多less图像? iPhone 4等老式设备的性能会受到怎样的影响?

  2. 将多个纹理合并到地图集中,然后将图像部分拼合在一起,然后再合并。 然后将obj加载到我的3d应用程序中,并基本上手动将所有内容重新映射到组合纹理。 这是一个痛苦,基本上是我付给三维艺术家的。

  3. 将多个纹理合并成地图集,但是将4,8,16等较小的地图放入较大的地图中。不要将它们挤在一起,而是均匀地缩小每一个。 然后重映射可以是math的,而不是手动重映射。 (这会在一些子纹理中留下很多未使用的空间)

    1. 事先在导入过程中预先计算math。

    2. 修改我的着色器,使其缩小并以dynamic均衡的方式偏移文本组合。

另外..是最好的结合基础纹理和正常纹理成一个或有2? 将它们结合在一起就意味着着色器会做math运算来移动法线贴图。

通过管道发送纹理数据的时间越less,渲染效果越好。 一个较大的纹理集将比同样内存容量的一千个更小的纹理集效率更高。 在有限的平台上开发人员并不less见,或者开发人员试图推动游戏机的限制(甚至是今天)来打包纹理,并限制纹理集调用的数量。 打包纹理图集是一个相对容易的自动化过程,预先的额外工作减less了运行时间的性能命中。