Ogre资源管理的设计缺陷

1、由于文件不带路径，所以一个资源组里的资源不能重名，不在一个文件夹也不行。这个限制非常恶心，项目开发中引发了很多问题，必须写工具检查是否有重名，极大降低了迭代开发的速度。主流商业引擎都是带相对路径的。

2、资源分组会带来很大的复杂性，例如代码会很臃肿，还有每个资源对象在内存中都至少有三个索引：ResourceGroupManager里面一个、ResourceManager的子类里面一个、实际应用的地方一个。分组并不是必须的，需求都可以用其他非常简洁的方法替代，例如可以使用Paging来解决关卡的整体卸载问题。

3、引擎启动时调用了Ogre::ResourceBackgroundQueue::getSingleton().initialiseResourceGroup()将指定资源组里面的所有脚本读进内存进行解析，涉及的资源都实例化出来（不加载）；并将已经声明的资源（实际上看SampleBrowser启动时并没有声明任何的资源）实例化出来（也不加载）。资源的declare，和在初始化中解析脚本并实例化资源对象都是多余的操作，因为这些脚本不一定在场景中会用到。如果是真正的商业项目，会有大量的脚本，比如材质文件，一次性都解析出来会急速地增加启动时间，并有不必要的内存开销。所有的资源都应该用到时才去加载到内存中。资源的所有操作都应该限制在prepareImpl()和loadImpl()两个函数里：在prepareImpl中进行IO、解析脚本、编译shader等耗时的操作；在loadImpl里面创建图形API对象和创建逻辑对象等操作。这样，资源状态就只剩下了一组：enum LoadingState，另外一套概念（包含Undefined、Declared、Unloaded、Loaded）就终于作废了，简单明了。

4、目前商业引擎都实现了异步加载，不知道为什么默认情况下不开启。

5、看SampleBrowser启动时，会加载resources_d.cfg，这个配置文件里面有大量的路径，每个对应一个Archive，搞得太繁琐了。建议在开发模式下，使用一个FileSystemArchive来表示资源的总路径（没有见到哪个商业引擎把资源分开多处的），对应的ResourceLocation打开递归。在发布版本中使用几个ZipArchive对象分别代表每个压缩包。如果需要支持边下边玩，需要自己实现一个类，继承自Archive，实现从网上下载的功能。当然会先检查本地是否有，可以使用责任链的设计模式。

当然，Ogre的资源管理也不是没有亮点，个人认为Archive这个接口设计的挺好。

 

欢迎加入QQ群“OGRE研究院 459827826”，一起研究Ogre。