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
openage dev updates