Merry Christmas and Happy New Year!
If you don’t celebrate any of those two, then don’t worry. Best wishes to you too!
We’re not dead. Just been busy, and very busy.
First of all, I need to clarify that Ogre 2.1 is very stable. Several users in our forums have been under the impression that 2.1 is unstable (both in terms of crashes or codebase constantly changing) and that is not true. Several teams are actually using 2.1 in production. We’re still away from an official release because we don’t run on Android, iOS and OS X yet; which for some, it can be a deal breaker. But if you work on Windows or Linux (or support for these other platforms can come later), then you can clone the repo and start working on 2.1
Beware most of the CMake option configurations haven’t been checked. Stick to defaults at first, and once you get the samples compiling and running, start experimenting with the other CMake options.
Also bare in mind the wiki and most plugins/addons are for 1.x; your starting point would be the samples (select OGRE_BUILD_SAMPLES2 in CMake) and the porting manual. (Recommended to view in OpenOffice or LibreOffice, then export to PDF. MS Word can open it, but it tends to screw the formatting).
Second, a community user, miki3d, has suggested a new logo/rebranding. What do you think? Don’t forget to stop by.
So… what’s new?
1. Added TagPoints to the new Skeleton system! This has been a sort of unfinished business for me. I’m glad it’s finally done!
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.
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 🙂 …
With all the crazy news about many high-profile game engines either dropping their prices or getting rid of them completely (with a royalty catch of course), we want to highlight one new game engine that uses Ogre as its rendering component: Skyline by Aurasoft.
The just entered the public beta stadium and published their new website.
Thanks to your awesome Ogre3D rending solution we can focus on leveraging superb visuals and cannot wait to see what we can do with Ogre V2.0.
Skyline has now been released as a public beta with both a free and retail version. The retail version is fully commercial with no royalties or earning restrictions and is a low cost game development solution. We have a new website and forums complete with an asset store (which still under dev): http://www.chi-ad.com/Skyline/Site/
Below a few screenshots of their editor and some sample scenes. More can be viewed directly on the engine’s website.
They were also featured some weeks ago in the IGM. Check out the article here.
Skyline main site: http://www.chi-ad.com/Skyline/Site/
Skyline forums: http://www.chi-ad.com/Skyline/Forum/
Skyline asset store: http://www.chi-ad.com/Skyline/AssetStore/index.php?route=common/home
This is dark_sylinc writing again…and: Oh boy! We’ve been busy!
1. Light list generation for forward lighting was threaded. Turns out, we were spending a lot of time building the light list when there are tons of objects on screen. Frame time was reduced from 10 ms to 4.5 ms on my Intel i5-4460 for 50k draws (AMD Radeon HD 7770).
2. Ported DX11! It’s not as thoroughly tested as the GL3+ RenderSystem, so I’d stick with GL3+ if you want stability. But it’s booting up, it can take advantage of most of the AZDO enhancements, and all the samples are running. Performance benchmarks against GL3+ are inconsistent: It highly depends on the driver (different cards, different bench results) and some samples run better on GL3+ others on D3D11, but often only by a slight margin.
Since the samples are GPU bottlenecked, my theory is that it depends on how well the driver compiles and optimizes the GLSL shader versus how well the driver optimizes and reinterprets the HLSL IL that the D3D runtime throws at the driver.
Now cards that are supposed to be supported but were not due to driver issues (i. e. Radeon HD 2000 through Radeon HD 4000) are now being supported! Intel cards weren’t tested, but in theory they should be supported too. Feedback is appreciated in this area (both Windows, Linux, and D3D vs. OpenGL).
3. We’ve been working on an experimental branch with a new technique called “Forward3D“. Sounds exciting but it’s not really ground breaking.
I don’t want to use deferred shading as default because it causes a lot of problems (transparency, antialiasing, multiple BDRF). Besides, it uses a lot of bandwidth. Forward+/Forward2.5 is great, but requires DX11 HW (needs UAV) and a Z-Prepass. This Z-prepass is often a turn off for many (even though in some cases it may improve performance, i.e. if you’re heavily pixel shader or ROP [= raster operation] bound).
I came up with an original idea for a new algorithm I call “Forward3D“. It’s not superior on all accounts, but it can work on DX10 hardware and doesn’t require a Z-prepass. The light list generation algorithm is now being generated in the CPU, however I think it should be able to run on Compute Shaders on DX10 hardware just fine (though, I don’t know yet if generating the light list is expensive enough; it may not even be worth doing on CS or perhaps it will).
The result is a nice generic algorithm that can run on a lot of hardware and can handle a lot of lights. Whether it performs better or worse than Deferred or Forward+ depends on the scene.
These are early screenshots. The algorithm has actually improved since then (particularly for bigger lights, it can handle a lot more lights now):
4. The community seems to be eager to compare how Ogre 2.1 fares against commercial engines. Remember that Ogre is a rendering engine while most of these engines are game engines (which means they provide much more than graphics, like physics, sounds, logic, scripting and level editors). Nonetheless Ogre seems to be doing very well!
We highly appreciate the faith you put in us!
5. Reported two Linux driver bugs to AMD. AMD has already confirmed that they will be including a fix for one of their bugs in the next Linux release. Their engineers are still working on the second bug, which has been much harder to isolate.
6. Merged all changes from:
- 1.9 → 1.10
- 1.9 & 1.10 → 2.0
- 1.9 & 1.10 & 2.0 → 2.1
Now, all enhancements that were made to 1.10 (particular to RenderSystems) are available in 2.0 as well. We still recommend that on 2.0 you stick to D3D9 though, since it’s the fastest and most stable one. On 2.1 we recommend GL3+, but you’re now encouraged to also try out the D3D11 RS as well.
7. Fixed tons of bugs as they’ve been reported or been found.
Well. There’s a lot of work that remains to be done. Ogre3D is well and alive! I’m /signing off for now.
Hello everybody, Murat (wolfmanfx) here:
Last year at CodeRabbit GmbH (my own company), we started a project called “Distributed Viewer”.
Distributed Viewer is an editor where users can upload models and edit materials in real time from any browser and instantly preview the changes not only in the browser, but also in all connected devices such as desktop PCs, Android and iOS devices at the same time.
Early in the development cycle we have realized that the current Ogre material system was too limiting and too complicated to do something like this. So after many discussions we came to the point where we decided to fund the initial development of the Ogre HLMS “High Level Material System”. More details about the HLMS can be found in this post from Matias.
With HLMS in our bag we have created PBS (Physically Based Shading) materials for the uploaded models. Our PBS shader is based on this moving-frostbite-to-pbr (the HLMS files will be released with the upcoming backport). The following image shows a screenshot from the material designer.
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.
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.
With this year’s Google Summer of Code already slightly being visible at the horizon it was time for us to get things started again: We are hoping to find a group of capable and motivated students that will help us move Ogre even further. In order to guide this effort, we created a list of potential GSoC projects that we deem most relevant for this year and consider manageable in the given GSoC time frame: GSoC 2015 Project Ideas. There is also a dedicated idea discussion thread that might yield further insights and ideas.
We also collected all the relevant information about how to apply, where to find additional Ogre related information for this year’s GSoC, etc. in this forum thread. Additionally, we have a GSoC wiki section with a dedicated page for this year that we will update as new information becomes available.
We welcome everyone to chime in either with additional ideas or comments regarding potential projects and join the combined efforts to make this one important cornerstone for a successful Ogre year 2015.
On a related note: The so far private Ogre Hlms/AZDO branch will most likely be made publicly available around the end of this week. This of course is needed for the related GSoC idea to be possible.