Between January 20th and February 25th, we gathered 54 responses. Among these, only one person mentioned using the pip package, whereas the ogre-python package was downloaded 3000 times. Although the findings are informative, they may not accurately reflect the broader picture due to these disparities in response patterns.
A notable observation is the duration that users have been working with ogre. The most popular choice, representing over 27% of the total, has been using it for more than 11 years. However, the group with less than 2 years of experience accounts for 42% of the overall user base. This suggests that Ogre continues to attract new users effectively.
Regarding RenderSystems, we observe a considerable decrease in usage for legacy systems (D3D9, GL). This trend allows us to explore new techniques for enhancing performance, which are not compatible with these older APIs. However, considering the absence of RTSS support for Metal, I question whether users understood that the survey was only for Ogre and not Ogre-Next.
As always statistics are lies though, so better take a look at the actual numbers yourself.
Specific replies
Following the #MeanTweets idea I also wrote some short replies to the criticism, that you can read below:
Poor documentation, limited capabilities in many areas (triange sorting, for example). Very few shaders/techniques for transparent meshes.
The documentation is flawless – I dare you to prove me wrong! For transparency/ sorting there is WBOIT since Ogre 13 (as shown in the transparency sample).
PBR
This already came up in the Ogre 13 survey. PBR support was added in Ogre 13.3 and exporting arrived in blender2ogre shortly after. Also you can just import gltf files using the assimp plugin.
Should introduce a new rendering pipeline using compositors like Ogre Next
You can already use the compositors to customize the pipeline for a z-prepass etc. A simple example is given as reversed-depth. A complex example is given in deferred shading.
No easy way to do modern game resolution option, like SDL SDL_RenderSetLogicalSize (keeping a fixed screen resolution and rendering at wanted resolution)
Dynamic Resolution is quite easy to do with Compositors.
Streamline the media folders(textures/models etc are all over the place), some sort of way of generating(or maybe just documentation/How-to) a minimal SDK that has only the core shaders/materals/scripts.
If you set OGRE_INSTALL_SAMPLES=OFF in CMake, you get exactly that. The minimal set of assets is in Media/, while additional samples are in Samples/Media/.
Some sort of roadmap for the future. What’s planned, what’s being worked on
The closest to that are the milestones. Where 14.x denotes what can be done without breaking the API, while 15 requires API breaks and thus is farther away.
Unnecessary depreciation. (Some things could probably be moved to a “legacy” components system.)
All deprecation was totally justified and you will not find one example where it was not 🙂 Also there already is a OgreDeprecated.h.