Pondering Ogre v2.0

· by Steve · Read in about 3 min · (621 Words)

I’m spending an awful lot of time thinking right now. I tend to do this after each major release but this time they’re bigger thoughts than usual. Perhaps most significantly, I’m now actively planning Ogre v2.0 - and given how reticent we were to call Ogre v1.0, you can imagine that this has to be something rather significant.

We’ve decided to parallelise the development of the next 2 major versions of Ogre in fact (as well as doing maintainance releases of Eihort of course). So, version 1.6 (‘Shoggoth’) will be going on over the summer and will almost certainly include the outcomes of the Google Summer of Code, so assuming all goes as planned that should appear sometime in the Autumn (or Fall, if you really must call it that ;)). Shoggoth will be another incremental improvement with the chance of some relatively limited interface breaking changes as is usual for a major branch. Earmarked for this release are things like a memory model overhaul and a DirectX10 rendersystem.

Meanwhile in parallel I’ll be working on Ogre v2.0 (‘Tindalos’). The reason the main changes for this won’t be going into 1.6 is because many of the changes I have in mind are extremely interface breaking in the most core elements of Ogre - the scene management interface. Thus, I really don’t want to force people to take this on if they want the other features that are planned for Shoggoth - and besides, the changes are likely to be significant enough that they will warrant the moniker ‘2.0’.

The Ogre scene management interface hasn’t really changed a great deal since 2000/2001 when I originally came up with it, and whilst many of the core concepts have proven to be very sound, I’ve also learned a lot since then, both generally and specifically how people go about using Ogre in their larger systems. There have also been major changes in the architecture of machines, most notably the move towards multicore processors which we’re not taking much advantage of right now, beyond background loading threads, as discussed by a nice bloke at Intel last year.

Ogre v2.0’s key elements will be:

  • Ability to integrate Ogre more cleanly as the ‘View’ component in a Model-View-Controller style setup, echewing our internal scene graph setup if desired
  • Greatly increased ability to utilise multiple cores efficiently to scale to large worlds
  • Support for enormous worlds without precision issues
  • World paging as a first-party feature
  • More explicit framework for supporting simultaneous combinations of SceneManagers

Most of these things are already possible through some effort / extensions, but the key thing is that I’m going to reposition the core such that all of these things are completely natural, designed in from day one. I been doing nothing but design work these last couple of days and I think I’ll be a little while yet - I’ve pretty much bottomed out the high-level design now but there is much to do on the low-level design before I even touch any code. Kinda feels like you’re not getting anywhere but I know how important it is to get this part done right before leaping into code. Delivering this feature set will be a tall order but it’s also quite exciting - for the last couple of years on Ogre I’ve mostly been working on a long sequence of ‘small problems’ - extremely important feature enhancements like vertex texturing, background loading, pose animation etc, but really the chance to tackle a big architectural issue like this one only comes around infrequently. Don’t ask me how long it’s going to take, I have no idea yet. But when it’s done, and assuming it will all works, it should hopefully earn that v2.0 badge.