January 2022 Progress Update

We hope everyone had a Happy New Year!

We would like to remind all subscribers that RT is still on hold until Focal 2.0 is ready to go. So if anyone wants to cancel their subscriptions until updates for RT resume, we completely understand, and we appreciate any and all support either way. Continued subscriptions will go directly into the continued development of Focal Engine.

Speaking of Focal, instead of the another overarching update with snippets of info about Focal, this month we are sharing an update from dotModded himself, which was originally posted in the #focal-updates channel on our Discord (be sure to join our server to see stuff like this even sooner).

This is gonna be fairly long winded and technical though, so strap in.

Few things to start with; plans!

Focal is still being written in C++ using the Vulkan API. It’s is designed in a way that’s actually agnostic to Minecraft. Surprisingly this improves compatibility with mods in comparison to replacing the renderer in place.

Furthering compatibility there are a lot of mods with custom rendering using OpenGL. Translating calls from OpenGL 2.1 to Vulkan sounds unenjoyable and likely buggy/inconsistent. So the better option is to just have a cross API renderer.

We end up in 2 “main” threads, focal’s thread and the game thread, each obviously can and do spawn their own. Focal’s thread handles the native process, this has the Vulkan context, our Lua engine, the Vulkan accelerated web based ui, memory management, and data caching. This is the core of focal and this is where the bulk of the code is. Focal Native creates 2 other API instances (OpenGL and DXGI) that can be shared to the game thread for uncaught render calls. We use GPU shared memory to accomplish the sharing between the API’s and remove the game threads ability to completely lock the render thread. This makes client lag look like server lag, being able to look around you but unable to move, entities frozen, game events just kinda freeze.

The original game UI’s are always still rendered in the original game using original calls, this is for mod support reasons, so if the client is lagging the UI may stutter even though your actual framerate is high. This is highly unlikely though as the renderer makes up the bulk of Minecraft’s processing next to lightmaps (use lithium for the love of God please) and should always outpace the vulkan renderer. The only case where this may become apparent is in a large modpack with a mod that has in world direct OpenGL custom rendering. It’s possible for the 2 threads to be running at different framerates it could desync. Frametearing shouldn’t happen though.

Latency is a huge concern. We have glfw shared between them to give Minecraft raw access to window information, (includes io, keyboard, mouse), with the removal of most of the renderer most of the CPU time for Minecraft (a solid 40-90%) depending, it allows focal to always be able to use the most readily available information. Reducing JNI calls is essential for cutting latency, and I’m proud to say by cutting the renderer we kill the majority of them in Minecraft. A mod may be able to increase the tick-rate because of this? Would improve PVP dramatically by having more than 20 tps. 

We have hunkered down on the Lua pipeline for programming non UI related stuff for shaderpacks. We rely heavily on EmmyLua for type enforcement and autocomplete/filling of tables. The reason Lua is the ideal case is because we wanted every parameter to be controlled by a function, tracked value, or setting from the UI in a threaded fashion that’s just in time compiled.

So if you want to have a setting that scales the resolution for a set of textures, you can create a tracked value with a function to scale tracked/constant inputs. Then use the tracked value as an input to any texture resolution variable. This will associate the texture to the tracked value, and will be updated when the tracked value updates, if the tracked value is based on other tracked values, it will run it’s function when it’s inputs have updated, then pushes down through the graph. Functions are only run when it’s parents have been updated, care should be taken when values update every frame. 

This system allows you to create very tightly integrated settings and gives the ability to offload work to the CPU. With the use of LuaJIT we’re not reinterpreting or compiling, everything is native bytecode that can just be called. This makes it INCREDIBLY fast in comparison to JS, these functions can also be called from many threads.

This creates a dependency graph of functions so updates cascade down and properly update all associated objects. 

With the Lua engine the goal is to reduce repeated logic to a bare minimum, tables all act as templates and can be extended. If you know you’re going to have a lot of textures with the same settings but you just want different names, you can make a texture/textureTemplate and just reuse it, change its name or any other parameters you’d like to modify from it. Hopefully this gives you complete full control over the renderer without having to worry about the intricacies of Vulkan until you need them.

We decided on a web based UI mostly because of how flexible they are, we will likely be using ultralight with a custom renderer for focal, this also gives you JS that can share tracked values with the Lua system, there is no thread safety, only memory safety between the web-ui and the Lua engine. It should NOT be used to make functions that interact with the tracked value system without user interaction. JS will only run when a UI is open, otherwise the thread is locked, the web-ui is not meant to be anything more than passing state data, and when the UI is closed whatever is in the tracked value is cached until the JS is run again. If you need to process this data every frame, bring what you need in from JS and create the logic in Lua, we will have bare math libraries exposed and Lua wrappers over them for simplicity.

Focal Engine will act as a listener for geometry and game state data, and when an update is received it propagates and is managed accordingly. For geometry and textures we largely will be following nanites geometry streaming and caching. As texture and geometry data is passed into focal engine it caches and processes them incrementally; mostly from the CPU to keep the GPU free for shaders. This should allow you to cram as much geometry as you really want into it, that doesn’t mean the game will keep up or the cache baking, if too much geometry is loaded too fast it can overwhelm the cache and processing (it relies on disk) things will enter a queue and may take longer to show up in game, this only applies to unique geometry like chunks, you could spawn 10 thousand pigs and the only thing that would die would be the AI. Instancing will be used where possible, vanilla or modded particles/entities/tile entities using vanilla rendering will be instanced.

Work on 2.1 Build 13 continues, with dot still working on some higher level finishing work, and Jake and Robo working on adding some smaller, but still important effects and features; the first of which is the return of Custom LUT support!

If you aren’t familiar with this feature, the simple explanation is that LUTs (Look Up Tables) allow you to radically change the entire tone of the shader, not entirely unlike an image filter you might use on say, Instagram. This feature currently functions exactly the same as it did in Continuum 2.0, using standard LUT files that you can swap out for any LUT they like, be it existing ones, or your own creations. We also still have a collection of LUT files for users to try over on our Discord server, so those will be ready and waiting for you all when Build 13 arrives with this feature!

Here’s a before / after comparison of the current implementation, using the Skyfall LUT on the Chéile éadrom map.

Now, some of you might be thinking that the before looks better than the after in the above shot, and that’s okay! Not everyone will like the same LUT’s, and many will certainly prefer to stick with the default experience. It’s all preference!