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!
2.1’s TagPoints are superior to their 1.x counterparts. The TagPoints from v1.x had many issues: they didn’t follow RenderQueue, visibility rules, nor LOD rules correctly (they were subordinated to the settings from the main entity/skeleton they were attached to). The v1 TagPoints also belonged to an Entity. If the Entity was destroyed, it took down its TagPoints with it. Meaning if you wanted to still keep the attachments, you had to iterate through them, detach them from their TagPoints, and add them to a new SceneNode. Ugh!!! Personally, I gave up trying to use those in my projects a long time ago.
In Ogre 2.1; TagPoints are much better: they are exactly like regular SceneNodes, except they occupy a little more RAM (a few more bytes per node), and can be attached to Bones. Other than RAM consumption, there is no performance penalty for replacing SceneNodes with TagPoints (*).
You can make a TagPoint child of a SceneNode, a SceneNode child of a TagPoint, and a TagPoint child of another TagPoint. The only thing you can’t do is make a SceneNode child of a Bone. You must use a TagPoint for that.
If you want, you can use TagPoints throughout your entire codebase and forget about having to deal with whether an Item/Entity was attached to a TagPoint or a SceneNode and get downcasts correctly.
(*)When a SceneNode or TagPoint is attached to a TagPoint that is child of a Bone, the performance is slower because these nodes need to support non-uniform scaling. But if the TagPoint is child of the Root SceneNode (instead of a bone) like all regular SceneNodes, then there’s no performance penalty.
2. Added PSOs (Pipeline State Objects). This brings us one step closer to Vulkan, DX12 and Metal support. We’ve also noticed some minor performance improvements since there are less hoops now when tying shaders with input layouts in the D3D11 RenderSystem. Overall it simplified our workflow. It also fixed a rare culling winding bug in GL3+ as a nice side-effect.
This work is in the branch 2.1-pso. It’s ready. It hasn’t been merged yet back to main 2.1 branch because I am waiting to test it on a big engine (since it was a big change) in case there are edge cases to fix.
3. Added alpha tested shadows and transparency to PBS! These have requested by many. Alpha tested shadows are useful for grids, leaves and other alpha tested objects.
We offer two transparency modes: Transparent and Fade. The former is physically based and still emits some specular light even at alpha = 0; the latter is good old alpha blending; and becomes invisible when alpha = 0.
Comparison pics:
Transparency = 0.3
Fade = 0.3
Transparency = 0.3
Fade = 0.3
4. Added Metallic and Specular workflow options. We’ve been working hard and closely with other teams and artists, tuning the BRDF settings. We now have 3 workflows: specular_ogre, specular_as_fresnel (what most popular engines do when they say “specular” workflow) and metallic.
For the tech-curious, specular_ogre maps the specular texture to the coefficient “kS”, whereas specular_as_fresnel maps the specular texture to the fresnel, colouring it. And metallic uses the slot reserved for the specular texture to control the metallness.
John Hable has an interesting discussion about the topic. Long story short specular_ogre allows more variety in the amount of materials that can be represented; but the specular_as_fresnel is more intuitive and is what most artists are used to.
5. Optimized vertex buffers for shadow mapping! If you’ve got VRAM to spare, you may want to enable this option to generate vertex buffers optimized specifically for shadow mapping.
Normally, GPUs require us to split a vertex when two triangles can’t share it (i.e. it has a different normal, it has got an UV seam, etc). But shadow mapping only requires position, and these cloned vertices (alongside fatter vertices) reduce performance unnecessarily. This new feature creates a vertex buffer with position data exclusively, thus reducing bandwidth requirements, fitting the cache better; and reducing the vertex count by avoiding duplicates.
Performance improvements vary wildly depending on scene and model complexity.
To enable it, set the global variables:
Mesh::msOptimizeForShadowMapping = true; v1::Mesh::msOptimizeForShadowMapping = true;
Note that this will increase loading times. For large meshes (i.e. 300k vertices), it is better to do it offline and save it to disk using the OgreMeshTool. If you do this, then there is no need to set msOptimizeForShadowMapping to true.
Also bare in mind this optimization will not be used for meshes using materials with alpha testing, as we require UV data for alpha testing; and not just position data.
For more information, visit the forum thread.
6. Updated and merged OgreMeshUpgrader and OgreXMLConverter into one tool: OgreMeshTool. This new tool supports many similar options and most of the same functionality the other two provided; with the addition of new v2.1 features like exporting to v2 formats, optimizing vertex formats to use half floating point and QTangents, generate optimized vertex buffers for shadow mapping.
7. Compositor improvements. Finished UAV (texture) support, finished resource transition/barriers project (needed by OpenGL, Vulkan and D3D12) see what are barriers and why they are needed, Compositor now allows for rendering to 3D and texture 2D arrays, also declaring cubemaps.
Automatic generation of mipmaps was added for RTTs (useful for cubemap probes). See section 4.1.3.2 generate_mipmaps from the porting manual for more information.
With proper UAV support, compute shaders are around the corner!
8. Added JSON materials. The previous script syntax was not scaling well. JSON rocks! Drop on the forum thread for more details. It was our latest addition so there may still be things to polish. The old hlms material script system will continue to work while we iron out the issues and finish DERGO as a material editor.
Other:
Fixed mesh LOD issues. Thanks xrgo for the help!
Lots of misc and minor bugfixes.
DERGO project is a Blender plugin that renders the scene using Ogre instead of a raytracer with realtime preview and a material editor. It’s still in early stages, but it’s showing a lot of potential!