Ogre 1.12.11 was just released. This is the last scheduled release for the 1.12 series and contains many bugfixes and new features. The smaller ones are:
- Gamepad Support in OgreBites
- Restructured GPU Program Script documentation
- Added Camera::setSortMode to account for rendering 2D layers instead of 3D geometry (as with 2D games)
The more notable new features will be presented in more detail in the following
Table of Contents
- Support for animated particles
- Software RenderSystem
- Transparent headless mode on Linux
- Improved Bullet-Ogre integration
Support for animated particles
Support for animating particles via Sprite-sheet textures was added. This enables a whole new class of effects with vanilla Ogre that previously required using particle-universe.
On the screenshots above, you see the Smoke demo, that was updated to showcase the new feature. However, the screenshots do not do full justice to the feature. If you are interested, it is best to download the SampleBrowser build and see the effect in action.
See this post (targeting blender) for an overview of the general technique.
For running the animation, the new TextureAnimator Affector was added.
While at it, I fixed several bugs deep in Ogre that prevented ParticleSystems to be properly treated as shadow casters. Now you can call setCastShadows as with any other entity and things will just work (see last image).
Software RenderSystem
Did you ever want to launch a Python Interpreter from your Shader or make HTTP requests per-pixel? Well, the wait is finally over – with the new TinyRenderSystem in Ogre 1.12.11 you can.
This render-system is based on the tinyrenderer project, which implements a full software-rasterizer in ~500 loc. If you are curious on how OpenGL works internally, I highly recommend taking a closer look.
For Ogre this had to be doubled to about ~1350 loc, but compared to the Vulkan RenderSystem from 2.x at ~24000 loc it is still tiny (note that this is already after stripping down the v2.3 implementation).
So what do we gain by having that RenderSystem? First it is a nice stress-test for Ogre, as this is a backend implemented in Ogre itself; each Buffer uses the DefaultBuffer implementation and each Texture and RenderWindow is backed by an Ogre::Image.
This makes it also a great fit for offline conversion tools, that want full access to the resources, without needing to actually access the GPU.
Next, this is really useful if you want to Unit-Test a Ogre-based application. Typically, you would need to set-up a headless rendering server (more on that below) to merely check whether your triangle is centered correctly in the frame. This is super easy now.
The screenshots on top, taken from the SampleBrowser, show you how far you can actually get with the RenderSystem. Note that there is no alpha blending, no mipmapping, no user-provided shaders and generally no advanced configuration of the rasterization. So if you are after full-featured software rasterization, you are better off with OpenGL on MESA/llvmpipe.
However, if you want to experiment with the rendering pipeline without being bound by the OpenGL API, this is the way to go. You actually can do the HTTP requests per pixel ;). Also, for creating a new RenderSystem, this is the least amount of reference code to read.
Transparent headless mode on Linux
Rendering on a remote machine over ssh just got easier! Previously ogre required a running X11 instance, which can be a hassle to come by on a machine without any monitors attached (e.g. a GPU server).
Instead of bailing out, Ogre will now merely issue a warning and transparently fall-back to a PBuffer based offscreen window. See this for the technical background.
To be able to do so Ogre must be using EGL instead of GLX, to do so it must be compiled with OGRE_GLSUPPORT_USE_EGL=1. With 1.13, we will be using EGL instead of GLX by default.
Compared with the EGL support recently added in v2.2.5, the implementation is much simpler and does provide any configuration options – but on the plus side the flag above is the only switch to toggle to get it running.
Improved Bullet-Ogre integration
I added a simplified API to the btogre project.
https://github.com/OGRECave/btogre
If you want to have physics on top of your rendering, it is now as simple as:
auto mDynWorld = new BtOgre::DynamicsWorld(gravity_vec);<br>mDynWorld->addRigidBody(weight, yourEntity, BtOgre::CT_SPHERE);where (as in Bullet) a weight of 0 means static object. Now you can call
mDynWorld->getBtWorld()->stepSimulation(evt.timeSinceLastFrame);and your objects will interact with each other. Of course if you need more control, the unterlying bullet types are still fully exposed.
Oh, and python bindings are now available too.