Physics with Warm-Starting (@fallenatlas)

Continuing the work from the previous release, we finished warm-starting for our physics simulation. Warm-starting uses the information stored in the contact manifold between two bodies, especially the total impulses applied to each contact point in the previous frame, and applies it before solving begins. It works based on the assumption that the impulses applied in the previous frame are a good estimate for the impulses that will also be applied in the current frame. Therefore, by applying them to the body before solving the collision constraint, the body should already be closer to its ideal position. Over time, these impulses will stabilize (since our solver is a "dirty" solver), resulting in less jitter. This is particularly effective for stacks of bodies, where the bodies push against each other, creating instability. However, if they're already closer to their ideal position, this instability will be reduced. With warm-starting, we can stack more bodies, and when the stack isn't fully stable, it stays together for longer.

Here you can see how, in our complex physics sample, the stack holds for much longer than before, although it still falls in the end.

However, if we increase our physics update rate to 60 times per second (rather than our current 30), and the substeps performed in each update to 8 (instead of our current 4), we can see that a stack of 8 blocks holds mostly stable.

Unfortunately, our collisions are not optimized to the point where we can have 60 updates per second with many bodies, but the door is open for this upgrade in the future!

Toggleable SSAO and Resolution Scale (@tomas7770)

Some time ago, we profiled Cubos's graphics engine to determine the main performance bottlenecks. SSAO stood out as the graphics plugin that took the most frame time. However, due to the way the rendering pipeline was implemented, disabling it to get better performance wasn't possible without breaking rendering altogether. Starting with this release, the SSAO component can be removed from a render target to disable this feature.

In addition, we found that other game engines often default to rendering SSAO textures at half the width/height of the screen resolution, which greatly improves performance without major loss in quality. To implement this, we added a resolution scale option to the SSAO component, which defaults to 0.5, but can be set to any value up to 2.0.

Conditional Shader Compilation (@tomas7770)

Another major bottleneck in the graphics renderer is the render picker, which allows finding out which entity is visible at a given pixel. As explained in the Modular Renderer section of the 0.2 blog post, we attempted to mitigate performance loss with Pixel Buffers and double-buffering. But despite this, it remains a demanding feature.

Just like what happened with SSAO, disabling the render picker wasn't possible. Unlike the former, though, this one required the ability to change shaders' source code at runtime. To solve this, we added new methods to the Shader class to prepend #define macros and recompile the shader.

auto vs = vsAsset->shaderStage(); // unmodified shader
vs = vsAsset->builder().with("RENDER_PICKER").build(); // shader with #define RENDER_PICKER
vs = vsAsset->builder().with("MAX_CSM_SPLITS", "5").build(); // shader with #define MAX_CSM_SPLITS 5

Unfortunately, the actual ability to toggle render picking didn't make it to this release, but it should make it to the next one!

Added Frustum geometry and intersection utilities (@mkuritsu)

A new geometry object was added, the frustum, and additionally, two new intersection functions to check if a box or a capsule intersects a frustum. This new geometry utility will be useful for frustum culling in a future release, potentially improving graphics performance when rendering large scenes with Cubos.