March 2025 Progress Update

• Fixed an issue that was causing white edges to form when certain clouds passed behind trees/leaves.
• Tweaked several default settings that were suboptimal, such as shadow softness, volumetric cloud samples, vignette strength, and more. All of these effects should see either improved quality, or more reasonable / less jarring visual presentation at default settings.
• Added star options menu (previously seen in Continuum 2.1’s latest Beta), it can be found in atmospheric options.
• Enabled local coverage by default.

And a few screenshots with these changes:

We’ve got some fairly big announcements on the Focal Engine side of things this month (and some updates on RT), but I’ll let the devs deliver those themselves!

First up, dotModded;

This month I’ve still been quite busy with Focal Alpha; after a long slog, we’ve finally figured out how to update past 1.20.1, moving up to 1.20.4 and 1.21.5 in the unified jar with Optifine. Unfortunately, as we’ve mentioned they might before, these updates have essentially broken our GUI, so we’re still working on that before a release…but we’re getting close!

Once we’re up to date though, we’ll continue enacting some of the plans we’ve been working on to make future updates smoother / easier. To start, we have started writing our own versions of the things we’ve been  relying on Optifine for, simplifying our update process in the future. I’ve personally been working on shader preprocessing and half of the setting management, while Jake is taking on the other half with expression evaluations for our eventual custom setting system. This expands the usability and functionality of our shaders offering more performance when on lower settings, along with realtime updates to many of the settings sliders; allowing fine adjustments to be presented immediately instead of waiting for it to recompile and exit the menus just to go through it all again. This will bring a new settings UI that I think will be much cleaner and easier to navigate. To be clear though, these features won’t be in the next release as we’re more focused on getting new version support out the door first.

Our next steps will then be implementing our own shadow map, and we have some ideas on how to make it faster and more aligned with industry standards, but things are still a bit up in the air at this time. Eventually we will implement our own gbuffers as well, and at this point we would be nearing a standalone version of Focal Engine, not requiring Optifine to work. This is a ways down the road though and we may yet decide to do something different due to mod compatibility on both Forge and Fabric. Shader mods are not simple, and require a ton of work to get things compatible with other mods. Often times requiring the mod author to build in compatibility for said shader mod.

Of course with Focal Alpha being closed source and only supporting our shaders, we will take some responsibility to work with other developers when needed to get things working smoothly. We may release source for critical areas where mod developers might want to know what’s going on as well, along with some development tools to test and verify in a development environment.

But yea, overall this is an exciting time for Focal Alpha and for the future Focal Engine, as moving to standalone will better frame what is needed for the Vulkan version and the overall future of the mod!

And now, Jakemichie with an update on his side of the above work, as well as the Continuum RT update he’s been working on!

While I’ve been mostly working on our new expression system for Focal Engine Alpha this month (which is coming along very nicely), I have also been working on RT here and there while brainstorming some ideas for how to optimise it. To quickly recap, I’ve been working on an update for RT that rewrites it within Continuum 2.1’s code base for the last few months. The goal of this update is to bring the improvements that we’ve made with 2.1 to RT and to move RT to a more maintainable code base that we can better iterate upon. While this update is closer to a releasable state, there’s still a number of things that need to be done. I’ve recently gotten stained glass properly rendering (and in a far better state than previous builds of RT), but I’ve still got things like the sun highlight and parallax to add.

Another problem is performance. While this RT update started out with better performance than previous builds of RT, it’s back down to around where previous builds of RT currently sit, and in some cases can perform worse (namely when you’re looking at water, since refraction adds an entire extra ray that branches with each bounce). I had some ideas to try to band-aid fix this that the new expression system allowed, but they consumed too much VRAM and didn’t bring a big enough speedup to make the VRAM hit worth it. So, it’s looking like this RT update will release with its current performance. As far as I can tell, the two performance bottlenecks for us is how divergent the path tracer is (rays fly in wildly different directions so the GPU tends to execute wildly different instructions, which significantly hurts performance), and how much L1 cache/shared memory is used by the path tracer’s ray stack (L1 cache/shared memory is shared by multiple tasks on the GPU, so if one task hogs L1 cache/shared memory, other tasks are unable to be scheduled which significantly hurts performance in cases where the GPU is often stalling and has to swap tasks to not sit idle).

I have some ideas on how to fix both, but it’s not possible quite yet since we’d need settings to do it properly. I can’t get into the details too much, but the gist is that I want to implement a form of multi-pass ray sorting which will solve divergence issues as similar rays are grouped together on the GPU, and this’ll be within an SSBO which will keep L1 cache/shared memory free. I don’t know if this will actually work, there’s some problems that I can see that may make this unfeasible – but there’s also some possible fixes to those problems that I have in mind – so we’ll have to wait and see how it shakes out. On a similar note, I also had an idea for optimising the voxel marcher, though that also requires settings to do properly since we’d need to move our voxel structure into an SSBO/3D texture, and it may not bring as big of a performance bump as I don’t think the voxel marcher itself is the bottleneck right now (it’s probably contributing, but I don’t think it’s the primary contributor).

That’s all I have to share this month, but these are exciting times for Focal and RT, so stay tuned!