Hi everybody! It’s me, Matias aka dark_sylinc!
Time to give a progress report:
At the time that I am writing these lines, I am making the final preparations for publicly releasing the AZDO branch aka “Ogre 2.1” (still unnamed as of yet). This doesn’t mean it’s ready / finished, but rather that it becomes public, as there has been a lot of development that has been done behind closed doors.
The relevant pull-request and merge can be found here: Ogre v2-1 branch creation / pull-request
The new branch itself is here: Ogre v2-1 branch
You can also follow my current ToDo list on my trello board.
Good news! We have officially added the v2-0-0RC1 tag to the Ogre repository (commit) indicating that we reached our first Release Candidate milestone for Ogre 2.0!
Our original plan was to tag this release as “CTP” (Community Technology Preview) and the upcoming AZDO (Approaching Zero Driver Overhead) improvements as “final”. However this proved to be very confusing for the community and in fact presented two practical concerns:
- v2-0-0RC1 is actually very stable and relatively easy to port to when coming from Ogre 1.9 or Ogre 1.10 (= current unstable default branch). The external API interface is quite similar, with performance benefits from efficient frustum culling and scene graph management (plus it’s multi-threaded). Several users in the community had already started porting to it.
- The AZDO branch was going to be labelled as “final”. Even though being quite impressive feature- and performance-wise, it is not complete, cannot be considered stable, and is far from actually being final. Furthermore, porting from Ogre 1.9 or even from Ogre 2.0-RC1 to the AZDO branch is not a trivial task as the external API changes are considerable.
Therefore we concluded that:
- The “CTP” branch will be released as Ogre 2.0 and is a good stepping stone for projects that require better performance without the high risk associated with porting when there are big engine changes.
- The “AZDO” branch will be released as Ogre 2.1 at some point in the future. External interface changes are quite significant and porting to this version requires more work and inherently results in more risk.
Our main focus of development will be on Ogre 2.1. We will only be providing basic bug fixes for Ogre 2.0 to be able to dedicate more resources to Ogre 2.1.
Note: While more and more focus will shift to Ogre 2.x, we will not immediately abandon Ogre 1.x. In fact, there is still at least one release in the making (Ogre 1.10). Once we have a more concrete timeline for it, we will announce the details.
Good news! We finally tagged the Ogre 1.9 branch as ‘stable‘, making it the new current and recommended version. We would advise you to update wherever possible, to benefit from all the fixes and improvements that made their way into the new release.
Right now, we don’t have any published SDKs yet, since we still rely on team and community members to help with the building and packaging process and that takes some time of course (we have it on our list to automate that process, but so far there always were more pressing topics to tackle 😉 ). But I have already heard that Windows SDKs are well underway and I expect the other ones to surface soon as well. We will update the download page as they become available and also try to update the announcement thread in the forums.
For an outline of the changes, have a look at the collected Ogre 1.9 change log in the wiki and at our JIRA tracker for all tickets fixed/solved by 1.9.
So what’s next? We are already working on Ogre 1.10 which will contain the changes from three of our five GSoC 2013 projects (details in the planning thread). In parallel, the work on the revamped Ogre 2.0 will continue as well…we’ve also got a related news post upcoming that will support those efforts. But as usual, we heavily rely on you as he community to support us with JIRA tickets, tracking down bugs and creating patches and adding new features. So chime in, whenever possible. Thanks!
BTW: With the release of Ogre 1.9 and the start of development for Ogre 1.10, we took the opportunity to get back to properly using the ‘default‘ branch, meaning Ogre 1.9 has been merged into it as well as Ogre 1.10 (which then was closed off), so ‘default‘ is once again our bleeding edge for development and preparation of Ogre 1.10. Please use it as the target for all pull-requests unless they are specifically meant for either Ogre 1.9 (only bug fixes) or Ogre 2.0.
Some days ago, we have been informed that the guys behind “Coherent:Labs” have released an Ogre3D integration of their CoherentUI solution. This cross-platform solution can be used to handle a wide variety of tasks from complex user interfaces to in-game browsing and in-game shopping systems, to installers and social integration.
With the new integration, Ogre3D joins the list of supported rendering engines that also features other big players such as Unity3D or CryEngine3.
For more details about the UI library, check out their website and read their announcement blog post. Below is the video from that blog post with their R&D head showcasing the new integration from a coding perspective. If you are looking for a new UI solution, give it a try!
Good news! We have just added the v1-9-0RC2 tag (commit) to our repository, indicating that we reached our RC2 milestone. Within the next four weeks we will fix any potential major bugs and will then release it on the the 10th November as “stable” to become the new de-jure Ogre version.
Note: As outlined in this version planning thread, we did not include any results of our GSoC 2013 projects in Ogre 1.9 yet, to not delay it any further. This merge will partially happen in the new version Ogre 1.10 and the rest of it in Ogre 2.0 (see the thread for more details and the reasoning behind it).
Since the Ogre 1.10 branch has now been created (commit), we can also officially share its name: Ogre 1.10 aka “Xalafu”. JIRA has been updated to reflect the new branches and versions as well.