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.
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!
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.
After 12 months of development and more than a dozen of public betas, Noesis Technologies are proud to announce the next big release of noesisGUI. Highlights in this version are:
- New platforms: DirectX 11, Windows Phone, Windows Store, iOS ARM64, OpenGL ES 3.
- New rendering algorithm that significantly improves performance and reduces draw calls.
- Simplified resource architecture.
- New tool for building XAMLs.
- Hundreds of improvements and bugfixes.
More information can be found in the release notes.
The OGRE bindings were updated to work with this new version. Special thanks to Murat Sari for his invaluable support.
Find more information about noesisGUI on the official website.
This is dark_sylinc writing again! Wanna know what we’ve been up to? Well, here it comes:
1. Improved shadow mapping quality. The PCF code I used was some snippet I had lying around since 2008. I now finally sat down and implemented better approaches.
After (same quality):
After (highest quality):
You can look in the forum thread for more information. Some community members have also posted more snippets with different filters. Some of these other filters may be provided out of the box eventually.
2. Hot reloading of Hlms shader templates: This has been supported for a while, but never publicly mentioned and the microcode cache could get in the way. This is very useful for more productive development, iteration, and debugging of Hlms shader files. In the samples, hit Ctrl+F1 to reload the PBS shaders and Ctrl+F2 to reload the Unlit shaders.
3. Fixed lots, lots and lots of D3D11 errors: Back in the previous report, we’ve described that DX11 had been ported. But there were still crashes lingering around, low level materials weren’t working, lots of texturing and mipmapping errors, huge memory leaks, and many other misc. errors. We’re happy and proud to say they’ve been fixed. There’s probably a few more bugs around waiting to be discovered and fixed…just like everything else.
4. Ogre 2.1 tested on Intel cards! I’ve only tested on an Intel HD 4600 so far and for GL3+ to work you will need the very latest drivers. Intel’s D3D11 support has always been significantly superior, and Ogre is no exception to that rule. If you intend to target the Intel market share of GPUs, shipping with D3D11 is a requirement.
Note: Remember that for other vendors, GL3+ can improve performance significantly over D3D11 as well! Don’t assume one particular API is superior for everybody!
Aside from these features, we’ve been fixing bugs, improving stability, improving documentation and tweaking the engine based on community feedback (thank you guys!). Ogre 2.1 keeps getting better every day.
Two community members made an awesome forum post where they took our PBS shaders and modified them to get a similar look to Marmoset Toolbag 2 (a non-Ogre-related 3rd-party tool for editing physically based materials). We’re looking forward into evaluating their improvements and integrating them into Ogre 2.1. We believe that the interoperability with industry-standard 3rd party tools such as Marmoset is key for the future of Ogre. You’ll probably hear from us about this in the next report, or the next to that one.
Well, that’s all for now. If you’ll excuse me, I need to go back to my cave …