Hello everyone and welcome to another openage monthly devlog. For this month, we are looking at a new renderer feature that adds a common optimization strategy to our rendering pipeline. We will also talk a little bit about the imminent release of the openage version 0.6.0.

Frustum Culling

We are going to start with frustum culling, a feature added by outside contributor @nikhilghosh75 that has finally landed in the main repository.

A frustum in this context is referring to a camera frustum, which basically represents the view cone of our camera in the 3D scene. Objects that are outside of this view cone would not be visible in a rendered frame, even if we told the GPU to draw the object. However, requesting the GPU to draw these objects and letting it figure out where and if they would be on screen can still take a great amount of time. Only once the GPU notices that the object would be drawn outside the viewport, it can skip further calculations.

With frustum culling, we are trying to exclude the objects that are not visible as early as possible, so that they don't even result in a draw call to the GPU. Ideally, we can also skip shader uniforms updates (done on the CPU side) while the object stays invisible. The potential for time saves here can be huge. Imagine a game scene that has 10,000 objects in total but only 500 are visible in the camera view. In this case, the number of draw calls and shader updates would be reduced by 95%!

openage currently supports 2D frustums (for sprite animations) and 3D frustums (for objects like terrain). Since most of our rendered objects are sprite animations, the 2D frustum is the type that would be used most frequently. You can see how the culling works in this small demo:

• Red rectangle: Frustum bounding box
• Blue rectangles: Animation boundary box of an object

As you can see, objects (blue rectangles) outside the frustum boundaries (red rectangle) are not included the render pass. To make the culling effect visible in this demo, the frustum's size is smaller than the actual camera viewport. In a normal game, the frustum would be slightly larger than the camera viewport to ensure that all objects that are visible are displayed. Notice also that frustum culling is not pixel perfect for the animations (e.g. for the leftmost object). Instead, the maximum boundary of all animation sprites are used, so an object may still be drawn if one of its current animation's sprites could be visible during a rendered frame.

Preparing for the Next Release

We have decided that after the last pathfinding improvements have been merged, we want to release the latest state of the project as version 0.6. The engine has improved a lot since the last release, so in our mind it makes sense to publish a minor feature milestone to reflect what we have achieved so far.

Most additions for the next release should already be known to avid readers of our devlogs, so we won't repeat them in detail here. Our major personal highlights are the new flow field pathfinder as well as the massive performance improvements we accomplished. Of course, there are also a bunch of small and big fixes, like getting the engine to work on Windows and macOS again, that are pretty nice.

What's next?

When the release is done, we will focus more on game simulation, specifically game entity interactions. There are also long-term improvements planned for the GUI and audio systems, so maybe we also start on that in the near future.

Questions?

Any more questions? Let us know and discuss those ideas by visiting our subreddit /r/openage!

As always, if you want to reach us directly in the dev chatroom:

• Matrix: #sfttech:matrix.org