Ogre 1.9 及 2.0 更新规划

主要有

1.完善新一代渲染系统

2.对移动平台的进一步支持

3.渲染系统增加一个状态缓存

4.清理OGRE核心将部分功能移至组件或插件

5.重新整理对多线程部分

with the release of 1.8 out of the way, it's time to plan for the future. There have been quite a few comments in the forums and in our user survey about what you'd like to see in coming versions, and it's time to assemble a concrete roadmap. The Ogre team has been discussing internally the steps that we deem critical or important for the next two versions, and we'd like to get your opinion to ensure that we don't accidentally head off in a completely different direction from what you need.
Please bear in mind, though: It's not possible to please everybody, and also we'd like to focus on critical and important items, first. That is to say, the list I'm presenting here is not meant to be complete; merely we would like to get a picture of the bare essentials that have to happen before we can release 1.9 and 2.0. Of course, in addition to those items we are hoping again for your contribution to submit patches and new features (small and large).

So here is what we are currently considering for the "essentials" roadmap:

• Finish our new-generation render systems. This includes the DX11 rendersystem and masterfalcon's work on a new OpenGL renderer targeting GL3+. Also need to complete support for the new-generation additional shader types. This is targeted for 1.9; there's currently a GSoC project for the DX11 rendersystem, so hopefully that one's covered.
• Improved support for current mobile platforms. Most importantly this includes support for the Android platform, but there are other necessary improvements to be made, like using NEON math for ARM platforms. Targeted for 1.9.
• A state cache for the rendersystems to avoid unnecessary state changes. Already working for GLES2, needs to be ported to the other systems as needed. Targeted for 1.9.
• Clean up Ogre core and possibly move features to separate components/plugins. While Ogre is already a modular project in principle, with a number of components and plugins in addition to OgreMain, there is still a somewhat large monolithic core, and its size can be an issue on mobile platforms. We should try to identify features that can be easily moved to separate components, and while we're at it, other parts might benefit from a little restructuring. Features to be moved to separate components could include e.g. overlays and animations. The resource system has also been a request to be removed from the core, but personally I'm not sure this is possible without sacrificing quite a bit of ease-of-use. Either way, the resource system could probably need a bit of an overhaul and perhaps be simplified in the process.
  Also getting rid of string identifiers and string comparisons has been highly demanded in our user survey requests.
  To be targeted for 1.9/2.0 on a per-project basis.
• SceneManager redesign. This is probably the most ambitious undertaking of them all and as such definitely targeted for 2.0. There are several aspects to this, some of which concern very basic performance issues: Our current SceneNode system requires too much memory and is cache-unfriendly. This needs to be reworked, maybe even for 1.9, if possible (without breaking too much of the current interface). But there's also been an ongoing discussion started by sinbad about feature-wise evolution of the SceneManager to better suit large worlds and making multiple SceneManagers work together. The original discussion can be found here, we need to sort through it and assemble a concrete design document for the new SceneManager design.
• Rework multithreading support. I am not an expert on the field, but here's what I have gathered from previous discussions:
  
  • Ogre is generally not considered thread-safe and should be restricted to a single application thread. Yet a lot of code in Ogre is guarded by mutexes and other constructs, in particular our SharedPtrs. Given that Ogre is not meant to be thread-safe, we should get rid of the SharedPtr locks and localise locking to the actual background tasks (resource loading) for performance reasons. Might be doable for 1.9.
  • The current Ogre threading system for background tasks strikes me as overcomplicated and requires rather complex synchronisation primitives that few threading libraries implement (not even std::thread). This should ideally be reworked to be able to use std::thread for threading if available, or ideally even something as simple as TinyThreads. Might be doable for 1.9.
  • The Ogre render loop itself should be parallelised where possible, particularly scene graph updates. From my understanding this would require a structure based on microtasks, and given that these microtasks must take precedence over any background resource loading or similar tasks, we either need a sophisticated task scheduler, or perhaps simply separate thread pools for background tasks and microtasks. We could perhaps prepare the infrastructure in 1.9, but the actual parallelisation is better left for 2.0, because it should probably be done in unison with the SceneManager redesign.

Anyway, this is the short form of what we think Ogre's future should hold. As I said, this is basically only the critical list, so it's not exhaustive - for example, there are a number of GSoC projects running right now that will hopefully make it into 1.9. Do you think we missed something really important? Are you generally happy with this roadmap. Any feedback at this stage is welcome! Some of the items will eventually have to be discussed more in-depth, but this is best done in separate topics once we've agreed on the general outline.

---