October 2024 Progress Update

Spooktober is over, but we’re still cooking…

We’ve got a lot of stuff cooking currently, not all of which we are quite ready to share (soon). I’m going to let both dotModded and Jake take it away once again though!

First, dotModded’s personal update for October:

This month I’ve been working on many of the same things as last month; primarily getting our development environment set up for 1.21, Continuum 2.1’s little SSR issue, and re-evaluating AMD support for 2.1 on their latest graphics drivers.

My work with 1.21’s development environment is making some decent progress progress. I finally have the game launching, though there are many bugs to work through. Our upcoming update here will likely require us to move away from the universal jar for a little while, unfortunately. Having to set up a brand new environment, rebasing a lot of code…I hope things will be working soon but I still can’t give a date with all the unknowns still ahead of us.

On another note…I haven’t made as much progress with Continuum 2.1’s SSR as I hoped, I have my notebook out and while the math is simple, getting things to work reliably is something else entirely, most of my ideas have led to worse visual artifacts. Making HiZ SSR behave incorrectly is challenging because normally it’s pixel perfect with a confidence value weighting it. I’ve tried working with the confidence to allow it to hit the lily pads instead of falling back to the sky, but the changes I’ve tried result in flickering reflections off the water. Trying to make the HiZ march skip over the lily’s causes issues with thin geometry like iron bars. If I can’t figure this out soon I’ll move to a typical ray march, this ray march will likely be more demanding than the HiZ march, but it will give us more freedom to make it behave like we want. If we go with this approach, it will likely be an optional toggle for those that are bothered by the lily pad reflection anomalies, while everyone else can continue to benefit from the likely more performant HiZ march.

I’ve also been poking at 2.1 and RT on AMD’s latest drivers. RT has been tested on both our RX 480 and 5700XT, as well as a supporters 7900XTX, and is working on a few of the latest available graphics driver versions (we’ve updated our System Requirements page to reflect this as well) Things are looking good overall for 2.1 as well, though it isn’t functional as of yet. I’ve discovered a bug in Focal Engine that I need to track down, and there’s a number of extensions we need to work around. Overall though I think it’s possible to get 2.1 working without sacrificing performance on Nvidia on these newer drivers, which is what previously held us back.

And now, Jake talks about what he’s been working on in October:

So, this month, much like the last, has been pretty hectic for me as we’re moving to a new place for the next year or so while my parents build a new house. I’ve mostly been busy packing my stuff up and helping prepare for the move, but in my downtime I’ve been starting work on a fairly hefty update for RT, plugging away at small changes and fixes for 2.1 and starting work on a rewrite for 2.1’s depth of field.

We’ve been wanting to push an RT update for a while now, as it’s on a pretty outdated and frankly messy code base that is a pain to maintain long term. Our goal for the RT update is pretty much to move it to 2.1’s code base so that we can share more code between the two shaders, which should net us a decent upgrade for RT’s sky and post-processing stack. At the same time, we’re likely going to look at changing how RT works in a couple key areas, such as cleaning up and optimizing both the path tracer and the denoiser, and cleaning up the compositing pass which takes the denoised path tracer output and applies it to the actual image. So far I’ve been focusing on adapting 2.1’s code base in a side branch to make it easier for us to drop RT into it, primarily by cutting out 2.1 passes that we don’t need such as our screen-space reflections or ambient occlusion passes, and refactoring our gbuffer to use a single RGBA32UI texture instead of the mishmash of RGBA8, RGBA16UI and RG16UI textures that 2.1 currently uses.

As for 2.1, I recently realized that we need to rewrite 2.1’s depth of field when pushing a change to add anamorphic distortion to DOF. 2.1’s current DOF is quite messy and features quite a few magic numbers that none of us really remember the reason for anymore, plus it’s technologically quite poor and has pretty bad quality. As such, I’ve decided to rewrite it in two separate rewrites: a smaller one that focuses mostly on just cleaning the code up, and a larger one that focuses on improving the quality. The smaller rewrite should go live in the next 2.1 update, and pretty much brings DOF in line with modern shaders such as Spectrum or Kappa, by changing our DOF to be more physically-based as it will use physical camera properties such as the aperture radius, focal length and sensor size.

At a later date, the larger rewrite will go live which will completely redesign DOF from the ground up, ideally bringing it in line with how the rest of the real-time graphics industry typically handles DOF. The goal of this larger rewrite is to switch our DOF from a pure gather algorithm (where each pixel gathers DOF samples from all nearby pixels within the DOF radius) to a scatter-as-gather algorithm (where each pixel gathers DOF samples from nearby pixels if and only if the nearby pixel has a large enough radius itself to cover the center pixel), which will bring it in line with Unreal Engine or Frostbite. The hope is that this should fix the hard outline along the edge of foreground objects, and will also make our DOF more physically plausible as the pure gather algorithm we currently use technically breaks physics. This is a pretty large rewrite, though, so I can’t give any hard dates for it.

Next up, here’s a quick overview / changelog for the Continuum 2.1 Beta Build 32 release we managed to get out this month: