New team member: Pavel Rojtberg

The new year has just started and already we have good news for the Ogre community: Pavel Rojtberg officially joined the development team. Many of you will already be familiar with him and his work in his Ogre 1.10 fork. Many / most / all of his changes will step-by-step make their way into the official 1.10 branch for which Pavel took over the maintenance. Some of you might already have noticed that based on him having commit/merge privileges now in the repository and him already making use of those since a few days.

Since most of the team resources are currently locked up in Ogre 2.x development, Pavel’s support is most welcome to make sure that the current Ogre 1.x versions don’t get left behind.

So, welcome on board Pavel!

Ogre 2.1 FAQ

Since we often get questions about the new Ogre versions in general and more specifically about the state of Ogre 2.1, Matias took the time to prepare an FAQ article in the wiki that provides answers to the most frequently asked questions. Over time we will expand this article to include new questions.

Link: Ogre 2.1 FAQ in the Ogre wiki.

For a more general overview about the Ogre versions, we also have our existing “What version to choose” page to provide guidance.

New team member: Eugene Golushkov

As many have already noticed, we have a new Ogre team member for already a few weeks now, so it is finally time to official announce this great news: Eugene Golushkov (forum account: Eugene) has joined the ranks of the core team and is currently focusing on the DX11 implementation efforts.

Eugene is actively working on a commercial application using Ogre and therefore is able to provide a lot of crucial insight into the implementation’s state and is able to directly tackle issues as they get uncovered by his day-to-day work. He already contributed a lot of fixes and additions to the DX11 render system and is overall doing great work.

More details on the updated team page.

Ogre Steam Sales List

Getting actual sales numbers for game titles is often difficult and unfortunately, we haven’t found a magic divining rod to get those numbers (yet), but with services such as SteamSpy it is at least possible to get a rough estimate for the leading game sales platform.

Our community member “bronzebeard” took it upon himself to compile a list of known Ogre-based Steam titles and their estimated sales numbers. He also promised to update the list approx. every month.

Check it out: Ogre3D Steam Game Sales List

PS: If you are aware of any missing Ogre-based application and their sales numbers (either from Steam or some other source), let us know in this forum thread. Thanks!

Ogre Progress Report: June 2015

A little late report. We know we missed April & May in the middle. But don’t worry. We’ve been busy!

So…what’s new in the Ogre 2.1 development branch?


1. Added depth texture support! This feature has been requested many times for a very long time. It was about time we added it!

Now you can write directly to depth buffers (aka depth-only passes) and read from them. This is very useful for Shadow Mapping. It also allows us to do PCF filtering in hardware with OpenGL.

But you can also read the depth buffers from regular passes, which is useful for reconstructing position in Deferred Shading systems, and post-processing effects that need depth, like SSAO and Depth of Field, without having to use MRT or another emulation to get the depth.

We make the distinction between “depth buffer” and “depth textures”. In Ogre, “depth textures” are buffers that have been requested to be read from as a texture at some point in time. If you want to ever use it as a texture, you’ll want to request a depth texture (controlled via RenderTarget::setPreferDepthTexture).

A “depth buffer” is a depth buffer that you will never be reading from as a texture and that can’t be used as such. This is because certain hardware gets certain optimizations or gets more precise depth formats available that would otherwise be unavailable if you ask for a depth textures.

For most modern hardware though, there’s probably no noticeable performance difference in this flag.