Recently there were several updates around the Ogre infrastructure and ecosystem. This post will outline the highlights for you.
Ogre 1.10.9 released
While this is actually core, there were several updates that also improve the Ogre ecosystem. Maybe the most prominent one is that ApplicationContext will now fall back to the installed plugins.cfg and resources.cfg if it does not find any it the working directory (or any previously searched locations).
While this sounds trivial it means that your
ApplicationContext based application will just run ™ – no need to worry about the RTSS resources or where the plugins are located. Ok, to load custom resources, still have to provide a resources.cfg, but in most cases you will not need a plugins.cfg. By default all enabled plugins will get loaded automatically.
Related to this change is the deprecation of
SceneType enum (i.e.
createSceneManger(ST_GENERIC)). Most of the time it only gave you the right SceneManager Plugin by chance. See this thread for details. Instead you are now supposed to call
Next, basic tutorials 1 & 2 were ported (thanks to Bohdan Kornienko) from the wiki to the new Doxygen documentation and to 1.10 (ApplicationContext). The code is no longer copy pasted into the page, but rather referenced from a real project that can be built and tested. Obviously the tutorial porting is an ongoing effort that you are invited to join.
-Wmissing-declarations warnings were enabled and fixed the code. These warnings help us ensuring that internal functions are correctly marked static and that our preprocessor branching is sane.
Of course there were many more changes. For the details – as usually – refer to the github tag.
Many addons ported
If you take a look at the OGRECave group on github, you will find many of the addons, that make up the Ogre ecosystem. The ones inside the group, were ported to 1.10. Due to the internal reorganization in 1.10, this allowed dropping lots (like lots) of code: e.g. FindOGRE.cmake and BaseApplication could be safely dropped.
But particularly, the documentation was regenerated and now even correctly references any external Ogre classes. Take a look:
You might notice that some information is outdated or find some typos. Take the chance and and create a pull-request on github. Most of this is just some markdown inside the according repository.
Ogre visualisation module in OpenCV
There have been Augmented Reality demos using OGRE and OpenCV for a long time. However the new Ogre Visualisation module, short ovis, provides a far better and easier integration. This allows you to write an AR demo in just 35 lines of code.
Regular visitors might have noticed some downtime of the Forums and the Wiki. This was due to the migration of our Webserver to Bytemark that are kindly providing us with free hosting. This was quite a leap forward as the old server was still running Ubuntu 12.04 with PHP software versioned at around that time. To me it is a miracle that the server still was under our control..
Anyway…the new server is now running Ubuntu 16.04 with automatic security updates. Furthermore we moved from phpbb 3.0.8 to phpbb 3.2.1 (~6 years advance) and tiki from 6.4 to tiki 15.5 (~5 years advance). Besides better security, this brings us responsive (mobile) pages and emoji support 🙂
Wiki deprecation and addonforums archival
The migration has shown some problems with our infrastructure though. We had an isolated addonforums phpbb instance where users had to register separately from the main forums. However only a few addons even had post from this year – let alone having responses. Therefore this instance was not migrated. Instead it was converted into a static archive.
Furthermore using a wiki for code is outdated by todays measures. It sits somewhere between Github, WordPress and Doxygen, where each of the alternatives offer a superior experience for the respective use-case. Therefore for contributing text, you should consider the following alternatives:
- for tutorial and sample code use Doxygen, which offers automatic code referencing
- for external projects use github, which offers code versioning and issue tracking
- the rest, which is general information, should probably be on the main page for better discoverability
IRC channel replaced by Gitter
In case you want to chat about Ogre related topics, you can now use our Gitter channel which replaces the #ogre3d IRC channel. The reason we drop IRC is that nobody of the current Ogre Team has admin access to the channel, preventing us to set-up an archival of the chat-logs or even change the headline. Of course we could have mailed back and forth with freenode, and then request botbot.me logging – but then Gitter took just a few clicks to set-up and offers superior code referencing..
Deprecation of node-less positioning
SceneNode::translate) and one big one:
- SceneNodes & Cameras look into (0,0,-1) by default
- whereas Lights look into (0,0,1)
Light::setDirection, which you should call with (0,0,-1) to make Lights behave like the other Nodes.
Compile time switches
OGRE_THREAD_SUPPORT == 3
OGRE_THREAD_SUPPORT==1where resource management is fully threaded, was hopelessly naive. It required too many locks, and also that the rendersystem was multi-threaded.
OGRE_THREAD_SUPPORT==2improved that by not requiring that the rendersystem was threaded, and just doing disk I/O in the background, but still, the whole process is still driven within the Resource class, which means the locks are still in place on Resource and by association SharedPtr and a bunch of other classes too.
OGRE_THREAD_SUPPORT==3option. Setting this, Ogre core objects – most notably Resource – are not thread-safe. However the DefaultWorkQueue is threaded. This allows the Terrain and MeshLOD Components to be multi-threaded without the locking overhead in OgreMain. See #454 for details.
AtomicScalartypes become merely aliases for
std::atomicwhich are both more portable and higher performance alternatives.
std::threadis used as the default threading provider.
O(log(N))lookup, iteration performance is terrible as maps are spread all over the memory and thus trash the CPU caches.
OGRE_NODE_STORAGE_LEGACY=0will use the cache friendly
std::vectorinstead of maps. Naturally lookup by name becomes
O(log(N))and the API changes. However this improves rendering performance by about 20% – bringing Ogre 1.x into 2.0 range when only a few nodes need updates. See #440 for details.
An outlook on Ogre 1.11
OGRE_USE_STD11=ONwill be supported. In other words Ogre will switch to C++11.
OGRE_NODE_STORAGE_LEGACY=OFFwill be supported.
OGRE_THREAD_SUPPORT=3will be the default. Only the
std::threadprovider will be supported.
- OGRE_RESOURCEMANAGER_STRICT=ON will be the default.
- Default Lights direction will be (0,0,-1).
- Lots of the deprecated API will be dropped – better start looking at the deprecation warnings now.
- Custom memory allocators will no longer be supported. You will be able to define C++11 template aliases to set them for STL containers though.
At this year’s Web3D conference in Brisbane a new Ogre based X3D viewer, called x3ogre, was presented.
X3D is an ISO specified file format for 3D file transmission and interchange which is now natively available to Ogre.
The Web3D is a scientific conference concerning technologies like WebGL, X3D and glTF.
The presented viewer is called x3ogre and provides a layer for loading and manipulating X3D files inside Ogre.
Vice versa the Ogre Material and Mesh formats also become accessible inside X3D files.
To put the viewer on the Web the x3ogre leverages Emscripten and the GLES2 RenderSystem to get translated to WebGL2 and WebAssembly.
The MIT licensed implementation is available on github.
We finally tagged the Ogre 1.10 branch as stable (tag: v1-10-4), 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.
This release represents more than 3 years of work from various contributors when compared to the previous 1.9 release. Notably, it includes the following three GSoC 2013 projects:
The ResourceManager redesign GSoC was superceded by the strict mode CMake switch.
Enabling the strict mode is highly recommended, however the default is legacy mode to ensure compatibility with existing projects.
Additionally it includes the changes from the git fork that got merged back into default. The fork formally did the 1.10.0 release, thats how we ended up with 1.10.4 here.
Currently 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 will update the download page as they become available and also try to update the announcement thread in the forums.
For an detailed overview of the new features see the New And Noteworthy Document. Among the highlights are:
- Python bindings as a component
- vastly improved GL3+/ GLES2 renderers with GL3+ now being the recommended choice on *nix systems
- Bites Component for rapid prototyping of applications
- Emscripten platform target – supporting Web Assembly & WebGL2
- improved build system, automatically fetching all required dependencies.
- A new HLMS Component implementing physically based shading
- Unified Documentation: the API docs, the manual and some Wiki pages have been merged and are now managed with Doxygen. As a consequence, the Wiki is outdated when it comes to OGRE 1.10. If you find something particularly missing, feel free to submit an additional tutorial.
Despite the amount of new features OGRE 1.10 provides the smoothest upgrade experience between OGRE releases so far. See the API/ ABI change overview for OGRE 1.7 – 1.10 that is kindly provided by ABI-laboratory.
Note that some components are marked as
[BETA]. This does not mean that they are likely to crash, but that we can not give any API stability guarantees for them right now. You should expect their API to change without a deprecation period while we we iron the warts out as the Component get more exposure.
In turn for the core components, our deprecation list has grown considerably. You can keep using these APIs for now, as we intend to support them until OGRE 1.11. Speaking of which; to make OGRE releases predictable, we will switch away to a feature based to a time based release model for the 1.x branch. This means that you can expect OGRE 1.11 in April 2018.
We would like to thank everyone who helped us make this release possible. The following list shows a list of contributors for 1.10 based on the git logs:
Pavel Rojtberg, Eugene Golushkov, David Rogers, Jesse Johnson, Murat Sari, Lior Lahav, Peter Szücs, Philip Allgaier, Matías N. Goldberg, Sasu Robert, Assaf Raman, Jannik Heller, lunkhound, Juan Borda, Daniel K. O., Jan Drabner, Transporter, Ahmed Allam, Flavien Bridault, Lf3T-Hn4D, J. Edward Sanchez, Mattan Furst, Shenjoku, arkeon, nxgraphics, 0xc0deface, Alexpux, Caleb Bartholomew, Christian Refvik, Harald Reingruber, Stefania Pedrazzi, Unknown, ja0335, threax, Al Reay, Andrew Piper, BAntDit-PC\BAntDit, Bastian Köcher, David Reepmeyer, Inifinity, Joel Croteau, Tomáš Kováč, tangren, Arroy One, Charles Prévot, Chris Burns, Daniel Brall, Daniel Gouvêa, Jean-François Verdon, Joël Lamotte, Matthew Fletcher, Misha, Oleksiy Ivanov, Simon Willshire, al2950, xantares, Alex Peterson, Alexey Knyshev, Andrew Fenn, Arroy, Bruno Sanches, Carsten, Crashy, Dainius Vaiksnys, David Avedissian, Denis CARLUS, Francesco Guastella, Gauthier POGAM–LE MONTAGNER, Glenn Ramsey, Holger Frydrych, J W, James Chen, Joe Brown, Justin Grant, KoenMertens, KungFooMasta, Mako_energy, Marcin Juszkiewicz, Michaël Broutin, Osamu Takasugi, Richard Plangger, Robert Hildebrandt, Robin Norrman, Ryan Thoryk, SNiLD, Sam Hocevar, Steve Peters, TheOnlyJoey, Ziriax, emilie.harquel, mkultra333, philiplb
BTW: if you want to contribute to OGRE, you can now use github as well.
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!
Merry XMas! if you don’t celebrate it, good wishes anyway!
It’s been 9 months since our last progress report. We think it’s time for a new one! Oh boy. So much has been done and still in the works.
In case you didn’t notice: Ogre 2.1 now runs on Apple’s API Metal. And it’s stable! It only works on iOS for the moment, since a few tweaks are required to make it work on macOS as well.
You’ll need to use the 2.1-pso branch in order to use Metal. The 2.1-pso branch is scheduled to be merged with 2.1, once testing of the branch 2-1-pso-cache-legacy finishes (which implements a PSO cache utility meant to help users port their immediate style rendering code such as GUIs to support PSOs without major/significant changes).
MSAA resolving for D3D11
MSAA for Render Textures has been broken on D3D11 since like…forever. Not anymore. D3D11 MSAA targets will now be resolved appropriately, according to our implicit resolve rules (explicit resolve support still pending, but in that regard OpenGL is in the same state).
Parallax Corrected Cubemaps
PCC for short, aka Local Cubemaps, Local reflections, Cube projection.
PCC reflections are very important to achieve accurate local reflections.
Our PCC implementation has two modes of operations: Automatic & Manual. Both have their strength and weaknesses.
Automatic “just works”. Probes get automatically blended together (based on camera position) and applied. However automatic may have trouble showing reflections from distant probes, and in some cases the blending may be too evident.
Manual solves the problem of distant reflections not showing up and the blending issue, but it requires you to explicitly set the probe to the material. Also if you don’t perfectly subdivide the geometry to fit the probe’s bounds, you may see gaps (since there is no blending happening at all).
You can actually mix automatic and manual behaviors.
Once the texture refactor is ready (keep reading) we may provide more powerful and superior automatic methods (by using Clustered Forward to select which probe to use and cube arrays to do the actual selection, which are only supported on DX11 class hardware or better).
For more information and experimentation you can look at our two samples LocalCubemaps and LocalCubemapsManualProbe.
Important note: The samples don’t make it yet too obvious that the PCC system reserves one visibility mask + Render Queue for their internal computations (i.e. it stores its Items into a RenderQueue of your choosing, set with a visibility bit also of your choosing). If you accidentally try to render those items, it will look funny. Keep in mind they may affect other things too, such as ray picking and Instant Radiosity generation (remember to filter those objects out).
Created Ogre 2.1 FAQ in the Wiki
We’ve addressed it in a news post already. We’ve written a wiki resource to address frequently asked questions regarding Ogre 2.1.
Texture Matrix Animation in Unlit
This has been requested a lot. Now you got it!
While we don’t yet provide easy ways to animate textures using material commands like old 1.x materials did, at least it’s now possible to animate them by hand if you need to.
We’re working on a technique called Instant Radiosity. The idea is very simple:
- Trace a lot of rays from the light.
- Generate a point light where the ray hits the surface. We’ll call this point light a VPL (Virtual Point Light)
- Cluster very close VPLs into one by summing their light contribution and averaging their locations.
- Use Forward3D or ForwardClustered (or Deferred Rendering) to use all these VPLs in scene.
The technique is an approximation but the results are very convincing, and lots of knobs to adjust for tweaking the results efficiently.
Instant Radiosity is not a very slow technique but neither a real time technique. When it comes to generating the VPLs, we still need to raytrace. Even if the raytrace takes e.g. 500 ms, it’s not suitable for real time. It was chosen because it was easy to implement and offers a lot of flexibility when compared to other techniques (such as Light Propagation Volumes) due to all the settings that can be adjusted, while also illuminating dynamic objects. In other words, the cost benefit ratio was really good.
This image is only lit by a spotlight + Global Illumination:
And now same scene with VPL debug markers turned on:
Another angle with parameters exaggerated:
Instant Radiosity made it obvious that Forward3D was under-performing. While it was original research done by me (dark_sylinc), it was clear it wasn’t as well as I had estimated and hoped.
So I just went ahead and implemented Clustered Forward. It’s both threaded (slices are assigned to different threads) and SIMD optimized. Also the Frustum vs. Spotlight and Frustum vs. Pointlight intersection tests are much (!) tighter than the ones we use for Forward3D.
In debug builds, having many slices may take a noticeable hit on CPU when compared to debug Forward3D. Though you could just use less slices during debug, or switch to Forward3D.
Clustered Forward allows controlling many slices, which improves GPU speed and the tight frustum tests mean shaders don’t waste precious cycles trying to shade with lights that aren’t actually visible. This leads to an average performance improvement of 33%, though your mileage may vary (it can be 2x faster or 0x if your lights had gigantic ranges).
- Scene passes now have “enable_forwardplus” to explicitly turn of Forward3D and ForwardClustered in passes you don’t need them. This will improve CPU consumption by avoiding wasting cycles in building the light lists on something you won’t be using.
- Compositor workspaces now support more than one input (i.e. not just the “final target”, which was usually but not always the RenderWindow). “connect_output” still exists, but it just does the same as “connect_external 0”. Useful when you want a workspace to produce a lot of results for you, not just one.
- 2D Array textures, cubemaps in compositors: They can now be created via compositor scripts. See the manual for more information.
- UAV Buffers: Instead of creating UAV textures, you can also create buffers. We allow creating buffers of fixed byte sizes, and width x height sizes. You can also create them from C++ and treat them as external buffers for the workspace (they work just like external textures). Useful mostly for compute and some advanced rendering algorithms. See the manual for more information.
- Double-sided stencil: Some parameters have been moved to the “both” block. See Sample_StencilTest and the manual for more information.
Quadratic behavior when loading meshes
User 0xC0DEFACE noticed loading 60.000 meshes was taking more than 15 minutes due to O(N^2) behavior in our code. He fixed it with a very trivial change and brought it down to 4 seconds. Kudos!
Merged PSO branch
PSO had been very stable for a long while now. Plus there had been a bunch of very important bugfixes (like stencil support, some edge case viewport glitches) that were only in PSO branch.
Furthermore I found myself very often merging and cherry-picking between the different 2.1 branches, which is a sign that they needed to be merged. So I did.
The last non-pso commit was 06631aef218d73fdc2ca323da626a53650d941be
New user Hotshot5000 has stepped up to port the GLES3 RenderSystem to Ogre 2.1.
He’s claiming he is starting to see the light. We wish him good luck as we wait impatiently for more updates from him!
In Design: Texture Refactor
The texture refactor was announced. No coding work has been done yet, but we’re solidifying the foundations how texture loading will work in the future.
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.
Whoa! Last time I (Matias) posted, we had a different website 🙂
What I’ve been working on:
I’ve started working on “Compute Shaders” (CS). They have been blocking future progress for far too long. They are required for modern techniques such as Forward+ and come in handy for things like tiled deferred rendering. Originally I started on compute shaders because I wanted them for a new terrain system that could generate the shadow maps in real time (yeah, there’s a new terrain system coming). CS are the only way to do it efficiently.
This has been a lot of work, and is currently under the unstable branch “2.1-pso-compute”. Actually, Compute Shaders are already working. However what we need to support is UAV buffers, which is sort of speak like read & write malloc’ed arrays of GPUs. We’ve already added support for UAV textures, but UAV buffers were missing and they are more flexible.
UAV buffers need to be treated with care though, because you’ll likely want to to create them from C++ (since they’re almost like a GPU malloc), but the compositor needs to be aware of them.
Why, you ask? Because the compositor is in charge of placing memory barriers and resource transitions. In other words: It needs to prevent race conditions. You’ll see … if you run Compute Shader A, and then Compute Shader B, and then render geometry, you have no guarantee that A will be completed before B. In fact, rendering geometry may even finish before A does!
This is great for GPU parallelism (colloquially known as Async Compute), but sucks if there were data dependencies (e. g. B depended on A, or Rendering Geometry depended on A or B). Memory barriers/resource transitions ensure shaders that must be run in order are executed in order while, hopefully, shader executions that are independent can run in parallel without being stalled.
Note: D3D11 implicitly inserts implicit memory barriers between compute shader executions, OpenGL only offers coarse memory barriers, but only Vulkan & D3D12 offer fine memory barriers.
The Compositor is in the best spot for this kind of work because it analyzes dependencies once (during workspace initialization) and can see all input, outputs and data dependencies.
That means that while UAV buffers can be created and managed from C++, some parts must be relinquished or informed to the compositor to ensure proper behavior (whether via scripts or via code). This means I need to be extremely careful with the design to avoid a clueless programmer innocently setting an UAV as input/output from a compute shader directly without the compositor noticing.
To make things worse, D3D11 & OpenGL differ quite greatly in how UAV buffers should be handled.
All in all, progress is steady. Compute Shaders are coming.
Other stuff that has increased in importance has been multiple RenderTarget inputs to compositor workspaces. Right now we only allow defining one “final target” which is treated as the final output (i. e. the RenderWIndow), although it doesn’t necessarily have to. The intention is to support more than just one external RenderTargets being available to a Compositor Workspace, which helps a lot in chaining multiple workspaces together (and are also very relevant for calculating memory barriers correctly).
Compute Shaders defined via JSON and have access to the Hlms
This is something I’ve been wanting to do for a while. Instead of using low level material’s syntax or interface (which was half ill-suited, half well-suited for the job), a new special Hlms is in charge of Compute shaders. We already have a working example (see all possible settings), although beware it’s subject to change. Auto params work, but not all of them since some don’t make sense because they were meant for rendering (and for the moment, attempting to use the unsuitable ones will likely result in a crash).
Why am I excited about the Hlms access? Because of the preprocessor of course!
For example, you can use the Hlms to unroll a loop based on the width of texture, thus reducing loop overhead during execution. Unrolling a loop can be critical in fully utilizing all bandwidth when performing certain tasks (such as parallel reduction), though it can hurt performance in other cases (particularly if the instruction length is too high, or it results in high register pressure).
You can also adapt your code based on the number of threads per group or automatically modify the shader depending on whether the bound texture is MSAA or not (which would normally require defining multiple shader programs and manually selecting the correct one).
Once Compute Shaders are over, I can finish what little remains of this terrain system and release it. Afterwards I may end up resuming on DERGO (a in-Blender live Ogre material editor) or continuing support for GLES3.
I really want to work more on DERGO, but GLES3 working again would mean three platforms being compatible again (OS X, Android, iOS) and once we have that in the bag, we might start talking about an official 2.1 SDK release date. Can’t say that isn’t tempting…
What else was accomplished in the past 2 months:
- User al2950 contributed PlaneBoundedVolumeSceneQuery to Ogre 2.x. This feature has been requested by many. Thanks!
- spookyboo deserves a special mention for reporting a lot of JSON bugs for our PBS materials. He has been severely stress testing our system as he’s been working on a Hlms material editor.
- A major bug involving reading of normal maps was fixed. Thanks to user GlowingPotato for noticing!
- Several fixes affecting the accuracy of our PBS implementation.
- Other minor bug fixes.
Thanks to all community users who have been reporting your issues and helping make Ogre 2.1 more robust every day! Our PBS implementation has been under a lot of scrutiny lately and I like it. It hurts my ego of course, but it results in improved quality. This of course means our users can focus on the important parts and not on the technical details.
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.
In a few hours the deadline for organizations to apply for the Google Summer of Code 2016 will end. And of course we have submitted our application to participate again in this great project.
One part of the application is an ideas list that proposes some interesting topics to potential students. The development core team compiled such a list of project ideas that are deemed very relevant. But of course this list can be extended by ideas from the community. In order to gather and discuss them, we created a thread in the forums and would encourage everyone to chime in and provide feedback either for already listed ideas or new ones.
Looking forward to your ideas!