April 2023 Progress Update

A bit late on this one…(it’s been a long week)

First thing’s first, lets talk about one of the main reasons this blog is so late; our recent service interruption and subsequent downtime.

At around 10:30AM PDT on May 10th, our WordPress was compromised via a remote code execution bug, and our server was used in what we believe to be a DDOS attack. Our host detected this, then took the server offline, and we began the process of restoring our site and backend from backups. We do not believe this was a targeted attack, and no account information was accessed.

There should be no lasting effects from this interruption, but we have assessed a few weaknesses in our current setup, and will be addressing them moving forward, hopefully minimizing downtime even more in the future. Sorry for any inconvenience this event may have caused.

The second reason for this blog being a bit…delayed; we have finally decided to announce what our recent ‘pivot’ in Focals design is.

I’m going to let our lead developer, dotModded take it away from here:

After much thought, planning, and testing we have decided to move Focal Engine Core from C++ to Rust. This was a decision that was not taken lightly, as we already had around 80,000 lines of C++ written. After spending much time working out the interactions between the Vulkan and OpenGL render loops we hit a wall where C++ really started to show its age. Even utilizing C++20 features, following RAII principles in a multi threaded context that ends up bloated and prone to mistakes with memory safety. Rust’s borrow checker and procedural/functional coding style lends itself better to such an interconnected complex system.

We’re nearly at feature parity with C++ in the Rust implementation, much of what’s missing has been rethought and delayed to be better integrated with the language. We’ve taken a more modular approach with the internal design. We’ve decoupled the concept of a window from a render entirely, as we have multiple renderers interacting with multiple windows in arbitrary configurations. Focal Engine is now better designed for multi-window, multi-projection, and complex window interactions for shaderpack options and multi-monitor rendering/VR. We’ve also better defined what exactly a renderpack, and assetpack is in concept, and how a developer is meant to interact with them (naming is still pending).

Much of what you’ll be working with as a shader developer is what we’re calling the RenderGraph. This will be defined in Lua (WebAssembly decision still pending, we’re still requesting feedback) the render graph is synchronized to a Vulkan timeline semaphore allowing for complex dependency interactions. The shader developer can request a command buffer of a specific type to the record sequences as well. Sequences are collections of stages, and a stage can be thought of as a Vulkan Pipeline. We’ve added these upper level abstractions to better organize and predict shader intent to optimize execution.

The graph can be considered stateful, and it handles frame-buffering automatically with controls exposed to the developer again for defining intent.

Next up on the Todo list is finishing the event bus for render loop I/O, this allows proper resizing the various allocations shared between Vulkan and OpenGl, being considerate of everything that’s in flight. This system needs to be fast and granular and will likely take some more time. Rust thankfully has sped up the conceptualization and initial implementations, however the fully flushed out version is still going to be large and involved as we’re essentially emulating a portion of the OpenGl state machine to cache and execute later and stay synchronized.

After this system is implemented we will have both OpenGL and Vulkan rendering to the same Vulkan swapchain. Then we begin getting Minecraft moved in little by little, starting with chunks, moving to entities and the various types of in world geometry, as previously stated UI rendering will remain in OpenGL for broader mod support.

We hope to have some screenshots to share soon!!

We still weren’t quite sure we wanted to share news about this move publicly yet, but we are now quite confident that this switch is the way forward, and we wanted to give some context to what has probably looked like a bit of a ‘lull’ in development over the last few months.

As dot mentioned above though, hopefully we will have some visuals to share soon 🙂

As for Minecraft 1.19.4 support for current OpenGL Focal; work on this update is still in progress, but it to has seen some unforeseen delays. We hope to have it available soon, but we have no ETA at this time.

2.1 Build 20 was released last month, fixing a Parallax (POM) bug that was causing visual inconsistency with textures at certain distances, and better representing texture artists intent (before/after screenshots below). This update also added a POM toggle to settings, and updated the wording for the underground light leak mitigation to better convey what users should expect from it.

As always, user reports are invaluable for our continued work to polish 2.1, so please, keep your reports coming
(though we would ask that you check the System Requirements pages Known Issues section before reporting an issue, thank you).

RT also got a small update this month, adding a TAA Sharpening option to it’s shader options menu, much like current versions of 2.1 Beta have.

This option can be found in Shader Options > Post Processing Settings > TAA Settings, and is very useful for use with lower Focal Render Quality levels, as it can offset some of the blur caused by the lower render resolution. It can of course also be used at native, to the users preference.