Hello fellow Brickadians! We've been super busy working on the next version of the game that will have scripting, voice chat, new wires features, performance improvements and more! But first, an announcement:

Brickadia is taking part in the Steam Spring Sale! The game will be 25% off all through the sale. If you want to pick the game up at our lowest ever price of $15, now is the time!

Overall Goals

Brickadia is a great building game, with some of the most robust and advanced tech powering it (in our opinion!) But with it's current feature-set, building is still the one primary way players play the game. It's very rare to see other kinds of servers beyond your classic freebuild server.

Our goal with EA3 is to turn Brickadia from one of the best building games ever to one of the best games ever for building and playing. In other words, give Brickadia gameplay!

We want you to be able to make tycoon games in Brickadia. We want you to be able to make Battle Royales in Brickadia. We want you to be able to make procedural dungeons in Brickadia. We want you to be able to make Prop Hunt. And Trouble in Terrorist Town. And deathruns. And so much more.

While some of these games sort of exist in the current version of Brickadia, they usually employ a ton of tricks and hacks. Most are unfinished due to a lack of tools to let creators cross the finish line.

Like last time, there is a lot we are doing. Let's talk about it!

Proximity Voice Chat

Brickadia will soon have proximity voice chat. Speak to your friends as you would in a Discord call, but in 3D space!

It will be highly configurable. Servers can enable and disable it, players can mute others, and it makes everything just a bit funnier.

New Wires Features

Everyone trying to use wires has the same three problems:

• Wire contraptions take up too much space.
• There is a lack of useful gates.
• They are super annoying to edit once they've been built.

Let's fix all of those at once!

Microchips

You'll soon be able to collapse your infinitely complex circuits into a single brick with Microchips. You can put a microchip anywhere: inside your arcade machine, inside your car, even inside another chip!

We are working on further features for microchips, like inputs and outputs, gamemode integration, and player microchips, prior to release. Stay tuned on this one! It's going to be big.

New Gates

We're adding a bunch of new gates to the game and have a bunch more on the way. Our focus with the gates we're adding is the same as it is for the update overall. We're fully invested in drastically increasing the scope of what Brickadia can do gameplay-wise.

One of the reasons we haven't added very many gates in the past few updates is because it actually involves quite a bit of stuff: Programming a gate involves quite a lot of boilerplate code, and art pass where the final gate was modeled by hand. Over the holidays, we've streamlined this!

We're now procedurally generating our gate models. This has allowed us to speed up our iteration times by decoupling the need for a gate model from the final art pass. We also decided to update the base model for gates to try and make it slightly easier to read connections and layers of gates. It now only requires us to manually add the icon to make the gate shippable!

Icons are now textured icons, rendered using an MSDF-encoded texture. No longer are the icons 3d modeled and baked into the gate mesh!

Vectors are now a supported wire type. All of the existing math gates will support it, and we're adding new gates to complement them!

We're also finally adding support for strings! All of the existing gates that accept a text/string input will be upgraded to have a wire port for the field. We're also adding gates for manipulating strings: formatting, combining strings, etc. And of course, there will be new gates to display text, including one that will let you place text and icons anywhere on your HUD.

So far, a lot of the changes have been back-end changes, but we did still manage to cram in a few new gates. We still plan to add a huge number of useful gates before the update launches, so if you have any suggestions, please let us know through our usual channels!

Moving

The resizer will soon be able to move and rotate bricks. Meaning you can now move and rotate your gates without disconnecting the wiring:

You can even move multiple bricks around at once:

We hope this will make wiring a bit less painful than it is currently!

Scripting with Luau

Scripting has waited long enough, and is now officially in production! The next version of Brickadia will feature Luau, a high-performance scripting language, complete with a REPL accessible via chat and the console.

Luau scripting is intended to have a lot of control over the game. For that reason, we're gating script usage behind a special permission. It is also server-side only, but we will be augmenting it so you can do more client-specific tasks like UI. Worlds and Gamemodes can include scripts, and they can be shared on the Gallery.

This prototype version uses auto-generated bindings based on Unreal Engine's API, so there will be many changes to make scripting easier and friendlier.

Here's some things people have already done with our initial prototype!

There is still quite a bit to do, but even in this state it can do quite a lot.

Performance Improvements

For every major update we try to make your game run a little better, and this one is no exception. Off the top of my head, here's everything we've done so far, and there might still be more to come:

• We've upgraded Unreal Engine to 5.7, which required solving several hundred rebase conflicts to integrate all our custom changes into the new version (it turns out Epic also likes to change the engine a lot!),
• We've fixed a major performance flaw in the Iris replication system that was causing it to poll sleeping and frozen entities every frame, only to discover that they did indeed not change,
• We've implemented a new fast rendering system that makes use of a new engine feature to render meshes while completely bypassing all the overhead that comes from using heavy primitive components to draw them, now in use for brick cluster meshes and character parts,
• We've implemented a new tick manager for brick components that only sometimes require ticks to update every frame, such as wheel engines that can go asleep when no one is driving the car and the steering has returned to idle,
• We've moved the final remaining part of the weapons system that was using Open Alpha-era barely functioning server side hit detection (melee weapons) to the new system of client predicted hits, which then allowed us to completely disable evaluating player animations on servers and only do it when the player is actually visible on clients,
• We've nativized more parts of old character blueprints like updating the nametags on screen that was taking up a lot of time, and optimized some redundant logic for bot controllers,
• We've made buoyancy computations roughly 10 times faster while also parallelizing it, now making it so fast that we could also enable buoyancy for all entities such as wheels,
• We've fixed that light components did not correctly apply the radius clamp from brightness when loading a map in single player or as a listen server (the issue did not occur as a client),
• We've refactored the brick cluster mesh system to now allow merging geometry across chunks when the world contains many sparse bricks over a large area, though it cannot yet combine meshes across different grids,
• We've removed all unnecessary access to physics scenes from background threads, which now allows us to run PhysX without the scene locks on every API call, removing a lot of overhead on basically everything,
• We've started compiling our "shipping" config binaries with Thin LTO, allowing the compiler to remove many unnecessary virtual function calls and inline small functions even across different files and modules,
• We've fixed that physics wasn't parallelized at all on typical cloud servers with two cores, previously it only worked on three cores and up,
• And more that wasn't worth mentioning here...

Client Performance

Wew! That's a lot! So what did we gain? Are we writing all this fluff for 5% performance gains? Well, let's compare EA2 to the current main branch. We'll use a version of the world "Pinkadia" for comparison, which is one of the most complex worlds ever created in the game:

Since most players would see this as a client on a server, we've also joined a server as a client. These screenshots are taken on a system with a RTX 5090 and Ryzen 9950X3D, but relative improvements are similar on other computers.

This world seems to perform terribly on a very high end computer. Let's see if that runs any better in the new version so far.

We've certainly made progress here!

There is more to come for optimizing the client - we'll soon introduce a new kinematic joint to connect multiple grids together rigidly, while allowing it to rotate with interpolation when controlled by a wire. This will allow you to replace slow physics based doors with much faster kinematic grids, and in the case where the angle is not controlled by a wire, we will be able to merge meshes across subgrids, making builds with a lot of rotated decorative grids massively faster.

And we haven't even started optimizing the GPU memory usage yet - the core brick renderer is still from Open Alpha days where builds mostly fit in VRAM and ray tracing was something far off. There are plans for streaming brick clusters so only the ones within the view distance must be resident in VRAM, and a new way to organize brick vertex data that should reduce its size by roughly 5 times (sadly, that will not apply to the separate ray tracing data, but it should help low end computers who will not be using ray tracing anyway the most).

Server Performance

Dedicated servers are now also much faster. Before, most of the time was spent on useless things, which we've now removed. For example, here is a direct comparison of a server frame running Pinkadia with a single client connected. To capture this trace, we have to use an instrumented build, so it's a little slower, but watch the difference in timings of the sections:

Running the server with tracing capability adds a lot of overhead, so let's also just compare the final frame rate the server is able to achieve, by joining it as a client and viewing this beautiful tps counter made out of bricks and gates and wires:

In the proper "shipping" configuration of the server we can now also see the performance impact of using Thin LTO to let the compiler optimize across the whole program, making it even faster than the previous comparison.

A listen server runs both the client and server code each tick, so if you are hosting a large world locally, you should expect performance increases somewhere between the two above.

Oh, and we've also made some tools so you can make your own builds and servers faster rather than waiting for us to find a way to do it by magic!

Performance Debug Views

Previously, whenever we tried to implement debug views in the engine, the performance left something to be desired:

But recently, we've gained a super fast new debug drawer based on the excellent work in the VoxelCore plugin:

So naturally, we had a solution and went looking for problems to solve with it...

For those interested in finding laggy contraptions in your servers and improving the performance of your worlds, we now have several useful debug visualizations you can use, all of which also include statistics for you to look at and use to track down performance issues on your servers.

Entity Debug View

This makes it easy to track down rogue entities, like physics grids, that may be contributing to server tick rate issues. It can be enabled with BR.DrawDebugEntities 1.

Watch out for red entities. Those are actively moving in the simulation and processed by physics and replication.

Light Debug View

A very common performance pitfall many builds suffer from is from overlapping lights, and this visualization makes it very easy to spot. It can be enabled with BR.DrawDebugLights 1.

If you have many overlapping lights at some location, and you get close to that location, all those lights are going to cover your entire screen, which is very slow.

So we thought it'd be useful to show how much overlap there really is, counting up for every light how many others touch it, and coloring them from green to red depending on the number, which ended up being a lot more difficult than expected.

Quiz: How do you determine which of 15,000 lights overlap each other in under 0.5ms on a single core?

Replication Debug View

It can be difficult finding specific contraptions in your world that may be contributing to network performance issues. Thankfully, we have a colorful solution! This can be enabled with BR.DrawDebugClientUpdates 1 in the console.

Collider Debug View

We've had this view before, but it has now been upgraded to visualize the origin, center of mass and intertia tensor of the object, letting you see whether your custom masses had the intended effect. It can be enabled with BR.DrawDebugColliders 1 in the console.

Brick Cluster Debug View

This one shows you how the brick engine groups the brick geometry to render. It can be enabled with BR.DrawDebugBrickClusters 1 in the console.

Other Goodies

Characters are finally present in the ray tracing scene, and the quality of ray traced reflections is also vastly improved with the new engine version.

We've fixed replication of sleeping object positions. No more will you load into a server, approach an object, only to learn that it did in fact not exist at that location, and see your character teleport 50 studs to the side.

We've added a network lag indicator that shows up if your average latency is too high or the server hasn't sent any message at all within a short time frame. There's also a similar warning for getting close to maxing out your system VRAM.

...And more.

There is so much else that we could have covered, but we have to get back to work! If you want to see further highlights, we highly recommend joining our Discord to get the latest and greatest news in one place.

Thanks for reading! Stay tuned.

Hey everyone,

We've been reading all your feedback since the Early Access release, and one thing that's come up very often was the price of the game. Many of you felt that $29.99 was too high a price while the game is lacking the last major features, and was making it difficult for you to get your friends to try it out with you.

We are confident that $29.99 reflects the value of the full 1.0 release, but we want the price to reflect the Early Access journey we’re on together right now. To make it easier for you to invite your friends and grow our community, we’re lowering the price to $19.99 for the duration of Early Access. Regional pricing will apply as before.

To those of you who have already jumped in at the original price point: Thank you! Your early support has been instrumental in keeping development moving at this pace. We've always said that our community is the most important part of this project, and by making the game more affordable now, we hope to see your servers feel a lot more alive.

What's next?

We have a large content update following soon after with many new additions to the logic system, giving you greater control over your gameplay. Stay tuned!

This is our first major update! We've cleaned up all major bugs and fixed a lot of stuff that was broken since EA1. If you encounter issues, please let us know in the bug-reports channel of the Discord or the Steam forums.

Winter Sale

Brickadia is taking part in the Steam Winter Sale! If you haven't bought the game yet, now is a great time:

Major Features

Customizable bots to give life to your maps! Give them any weapon and customize their settings like aggression or 360 degree vision. You can use them without weapons to create wandering NPCs, give them swords to make an army of warriors, or give them all guns to create a deathmatch server. They look the same as a player, and you can give them your avatar settings.

We've fully reworked the prefab system. The new prefabs live in your catalog! Save entire cars, contraptions and other interconnected objects locally for easy reuse. Grab a vehicle from the gallery and place it, instantly, anywhere you have permission. Copy things from the world into your real clipboard, and paste them into Discord or another running instance of the game.

The selector has been completely rewritten with a new connection mode. Grab a complete physics contraption with all connected grids and entities in a single click.

Four separate player collision channels let you create invisible walls that only certain teams can pass through, opening up new possibilities for minigames and maps.

A new component that lets you dynamically change a brick's visibility, collision, and color through wires. Perfect for hidden doors or interactive displays.

The Applicator and Connector now have an X-Ray mode, letting you edit components on bricks hidden behind other bricks and entities.

Full Changelog Since EA1

Gallery

• Renamed "TOP" and "TOP ALL TIME" categories to "HOT" and "TOP".
• The "HOT" category now also shows older files on the next pages.
• The browser page no longer reloads every time the dialog is shown.

Worlds

• You can now save the server world to your client if you have any building permissions.
• You can now upload worlds to servers with extended permissions. The server will be in read-only mode with autosave disabled.

Prefabs

• A new prefab browser is now integrated into the catalog, letting you save your creations and add them to the inventory to place much like bricks and entities.
• Prefabs now have automatically generated thumbnails that look the same as bricks and entities, no longer requiring you to get a nice screenshot.
• A new prefab gallery is also available, letting you share your creations, and browse the ones others shared to use immediately or save for later.
• Copying things now stores a prefab file in your clipboard, letting you paste it in another game client or share it through applications like Discord.
• The legacy prefab system and its associated dialogs were removed, but a button exists in the prefab browser to convert any legacy brs files you may have.
• The Max Selected Bricks default value is now the same as Max Prefab Bricks.

Physics

• There are now 4 separate player collision channels, so you can make invisible walls that only some teams can pass.
• Can choose which channel to use on a per-team basis, as well as which channels players on those teams collide with.

Selector

• The selection system has been rewritten and now supports tracking an explicit selection of bricks and entities.
• When using a selection box, in addition to immediately copying/cutting that box as before, you can now also add/remove the bricks inside to your selection to refine what you have selected in multiple steps.
• The selector now has an alternative connection selection mode that selects adjacent bricks, such as a whole house on its baseplate.
• The connection mode also supports selecting an entire physics contraption including all connected grids and entities.
• Added entity and brick count limits to the selector.
• The mode switch binding has been changed to C.

Applicator

• You can now press R to toggle X-Ray Mode, which will edit bricks that have existing components through other bricks and entities.

Connector

• The connector now also has an X-Ray Mode that only interacts with bricks that have components.
• The gate brick will now be highlighted when hovering a physical port.

Painter

• The painter can now paint and pick the color sections of entities, such as making wheels have differently colored tires.

Building

• High friction tires is now the default for newly placed wheels.

Components

• Added a new component, the Brick Property Changer. Can be used to change the visibility, collision channels, and color of a brick using wires.
• The ancient per-type component quota has been removed. There is now a single per-user quota of active components (lights, audio, item spawns, engines, etc) which can be adjusted in server settings.
• The Seat component can now be manually attached to all bricks, in case you want to fit custom seats in tight spaces.
• All the uncategorized components have been organized in the list.

Bots

• Bots can now be given weapons and use them, attacking with melee weapons or shooting guns, reloading them when appropriate.
• Bots can now wander around freely on the map or walk towards goal points, jumping over obstacles.
• Bots can now be given character skins by copying the current skin from your character.
• Bots can now damage players in the default minigame and join teams by coloring their spawns the same as the team color.
• Bots are now considered for win conditions like last man standing.
• Bots can now spawned and despawned by wires.
• Bots have a lot more settings than we are able to list here.

Weapons

• Return of Crystal Kalis which was accidentally disabled.
• Added Laser Cleaver.
• Added Laser Axe.
• Added Medi-Syringe, an item which quickly heals 50 health when used.
• Added Spear, a melee weapon with a fast underhand stab and a slow overhead stab.
• Added Bandage, a slow self healing item that restores 25 hp.
• Added Basic Claws, Sharp Claws, and Shadow Claws, fast melee weapons intended for zombie bots but also possible to use yourself.

Cosmetics

• Added Twintails
• Added Snout (multiple variants)
• Added Shaggy Swept hair (2 variants)
• Added Wings
• Added Back Valve
• Added Robot Paw
• Added Robobunny Ears
• Added Secured Bag
• Added Employee Card

Sounds

• Tool audio has been reclassified under Item audio.

UI

• The world browser and catalog now remember the last used tab between sessions.
• Pressing Ctrl F in the My Worlds or My Prefabs tabs will now focus the search box.
• Clicking the current folder breadcrumb will now reload the listing to see external changes.
• The pause menu now has a button to open the server list when on a server as a client.
• The unimplemented admin button has been removed from the pause menu.
• Added the ability to search for worlds. Search also includes files in subfolders of the current folder.
• Added the ability to delete worlds.
• Added a dialog when failing to create a folder.
• Removed the defunct controller column from the key binding menu. This never functioned correctly once we began implementing chorded bindings for tools. The intended way to configure controller mappings is to use Steam Input settings.
• Removed the defunct help menu.
• Removed unnecessary "Release-" text from the version display in the top right.
• The folder tiles in the world and prefab browsers now show how many files and folders are inside them.

Servers

• Improved /BrickCount output to include entity counts.
• Removed /DestroyAllGrids, which was an obsolete test command.
• Added /ClearAllEntities, which removes all entities in the world.
• Added /ClearEntities, which removes your own entities.
• Added /ClearEntities [player], which removes someone elses entities.
• Added /ClearAllLooseEntities, which removes all entities not attached to at least one more entity.
• Added /ClearLooseEntities, which does the same but only for your entities.
• Added /ClearLooseEntities [player], which does the same but for someone elses entities.
• Added /ClearAllFarEntities [distance], which removes all entities further away than some distance in studs.
• Added /ClearFarEntities [distance], which does the same but only for your entities.
• Added /ClearFarEntities [player] [distance], which does the same but for someone elses entities.
• Added /BrickCount [player], which shows how many bricks, entities and components a specific player has.
• Updated player admin actions drop down to include Clear Entities, Clear Loose Entities, Clear Far Entities (defaults distance to 10000 studs).
• There is now a permission for whether players can use X-Ray mode, intended for Tutorial but can be used by players too.

Performance

• Optimized building and share zone checks when modifying bricks.
• Optimized zone checks when characters move.
• Optimized manipulator searching for possible joints to attach while holding entity.

Engine

• The experimental Behaviors code has been removed in preparation of integrating the new Lua scripting engine coming in a future update.
• The world boundary no longer instantly vaporizes your vehicles and simply keeps them inside.
• Some improvements to player movement prediction when walking on large frozen physics grids.
• Refactored how the game accesses worlds and prefabs. File handles are now automatically closed and databases unloaded after a few seconds of inactivity, allowing external access to the files.
• The Test executable is now included with the dedicated server deployment.
• Updated PhysX to the newest patch release of version 5.6.1.
• Updated DLSS plugin to version 8.3.0-NGX310.4.0.
• Updated FSR plugin to 4.0.2b, improving performance and stability.

Localization

• Updated Spanish localization with reviewed strings.
• Refreshed strings.

Servers

• The server log file now logs when a user is unbanned.

Bugs

• Fixed crash auto toggling tool with controller.
• Fixed crash joining server while using a controller.
• Fixed crash when creating a very (very) long chain of rerouters or logic gates.
• Fixed several crashes due to unused quickbar ranges legacy code.
• Fixed crash when recreating output wire with a new type.
• Fixed crash when taking a screenshot with HDR.
• Fixed crash when grenades explode after a garbage collection.
• Fixed clients crashing when homing missile hits a physics object.
• Fixed crash when dedicated server is left alone for a while due to iris replication not ticking.
• Fixed crash running out of replicated objects when playing alone in a listen server.
• Fixed crash when loading specifically crafted world file.
• Fixed crash when applicator dialog is viewing a brick component while replicating additional components.
• Fixed crash when equipping a tool while loading into the server.
• Fixed crash when undoing deletion of a brick tried to revive a brick grid that was deleted.
• Fixed crash due to incorrect check for sync state in async serialize function.
• Fixed crash setting minigame inventory size to 0.
• Fixed crash when placing, resizing and deleting bricks too quickly.
• Fixed crash when trying to load an old world file with components that no longer exist.
• Fixed crash when destroying brick grid entity with a building zone attached to it.
• Fixed crashes caused by being able to attach invalid components to bricks.
• Fixed check against NaN object positions not actually working on world load.
• Fixed rare crash due to use after free in legacy save file loader.
• Fixed rare crash in wire type propagation logic related to placing prefabs.
• Fixed brick replication deadlock in rare case where the first component in the update list generates a message of a specific size.
• Fixed trace scene corruption when trying to set the velocity of a frozen entity.
• Fixed broken overlap check allowing certain cases of intersecting micro wedges to be placed.
• Fixed very rare bundle corruption due to background file write tasks executing in incorrect order.
• Fixed being able to pick up multiple pistols.
• Fixed clients not being able to switch to precision mode on paste when copying bricks from physics grids.
• Fixed chance of mysterious 1 unit offset when using switch to precision mode on paste.
• Fixed Painter getting stuck in "Paint Only Material" mode if put away while ctrl is held.
• Fixed selection outlines not rendering in simple shading mode.
• Fixed hologram and translucent plastic brick materials causing Lumen to render an extremely slow ray traced reflection which cannot be seen.
• Fixed broken depth bounds for fog rendering causing it to cut off on surfaces close to the camera.
• Fixed Z fighting of brick previews when overlapped with the original bricks in precision mode.
• Fixed ugly one pixel visual seams along the edges of brick previews.
• Fixed race condition causing the options button on the escape menu to not function sometimes.
• Fixed non-deterministic vehicle behavior due to wheel engines not applying some settings on servers.
• Fixed non-deterministic joint behavior due to not updating average mass on modifying attached objects.
• Fixed contraptions exploding when deleting a set of jointed bodies and undoing the deletion.
• Fixed re-attaching objects to joints not correctly restoring the relative transform if the joint was bent.
• Fixed re-attaching objects to joints not correctly moving further attached child objects.
• Fixed incorrect mass calculation for bricks grids since the ability to disable collision was added.
• Fixed incorrect joint behavior after re-attaching a wheel to a wheel joint connected to an engine.
• Fixed deleting an entity and undoing the deletion not restoring any changed properties.
• Fixed deleting a frozen object and undoing the deletion failing to re-freeze it.
• Fixed having wheel joints connected to an engine preventing idle physics contraptions from sleeping.
• Fixed being unable to create multiple levels of folders for worlds.
• Fixed client predicted hit markers showing for objects that cannot be damaged.
• Fixed extra physics grids and entities attached to the vehicle you are in blocking the camera.
• Fixed loading a world in single player not waiting for meshes to upload before hiding the loading screen.
• Fixed wrong formatting for the message when using /clearbricks [name] as server.
• Fixed distance to target output not working when a teleport target wire is connected.
• Fixed server settings defaulting to the permissions tab.
• Fixed broken "at target" output on servo bearings.
• Fixed various correctness bugs in world serializer.
• Fixed being able to redo undone actions if the permission to do them was since removed from the client.
• Fixed being able to load nan values through presets in the applicator.
• Fixed being able to place more bricks in a single chunk that the world serializer will allow to load.
• Fixed brick grids teleporting into space when attaching a socket to a bearing.
• Fixed firing weapons in first person while crouched not hitting the correct target on the server side.
• Fixed being able to upload to the gallery from the downloads tab.
• Fixed lives counter not updating for clients in minigames.
• Fixed connection not being aborted if client fails to insert a replicated brick into the designated chunk.
• Fixed gallery viewer scaling incorrectly when there are very long titles.
• Fixed long gallery descriptions breaking the layout of the details page.
• Fixed buttons remaining held when clicked too fast.
• Fixed input splitter being shown in add component list.
• Fixed "Failed to insert brick in chunk" log spam.
• Fixed being able to get stuck in freeze camera mode when entering a minigame.
• Fixed not leaving the current seat when trying to use the teleport command.
• Fixed seats showing the sit prompt in third person when occupied.
• Fixed brick delete sound playing in wrong location when removing bricks from physics grids.
• Fixed "Reselect Last Port" on Connector not being rebindable.
• Fixed "Johnny Ledger" music tracks missing in minigame music selector.
• Fixed inaccurate tool traces against wheels attached to wheel joints.
• Fixed aurora setting in environment not functioning.
• Fixed a case of precision mode on paste selecting the wrong grid.
• Fixed water effects and damage not working when standing in low water.
• Fixed Missile Launcher still being able to fire when out of ammo.
• Fixed flying against a wall accumulating velocity incorrectly.
• Fixed gibs and detached hats affecting physics contraptions.
• Fixed being unable to kick gibs around.
• Fixed hitmarkers playing twice on clients.
• Fixed Manipulator not aiming correctly in free mouse mode.
• Fixed wires not respecting render distance limit.
• Fixed additional bugs that were not correctly tracked.

Brickadia is taking part in the Steam Autumn Sale! If you haven't bought the game yet, now is a great time:

EA2 Preview

At the same time, we're releasing a preview version of our first major update on the unstable branch so you can try it a few days early. This has two long-awaited major features:

We've fully reworked the prefab system. The new prefabs live in your catalog! Save entire cars, contraptions and other interconnected objects locally for easy reuse. Grab a vehicle from the gallery and place it, instantly, anywhere you have permission. Copy things from the world into your real clipboard, and paste them into Discord or another running instance of the game.

Customizable bots to give life to your maps! Give them any weapon and customize their settings like aggression or 360 degree vision. You can use them without weapons to create wandering NPCs, give them swords to make an army of warriors, or give them all guns to create a deathmatch server. They look the same as a player, and you can give them your avatar settings.

Watch the video below for a sneak peek:

You can read the full changelog on Steam.

Hello again! After our previous car building tutorial we promised to release a second part dedicated to car tuning, and here it is!

Got a car built and driving, but you're struggling to get it controlling well? Wheels bouncing all over the place, or your car flips over all the time? This tutorial guides you through the most important settings to tune your car properly, providing far better control and stability.

If you're not sure how to build a car in the first place, check out our beginner's car building tutorial.

You may note that we don't give concrete "recommended" numbers in this video to use - this is because everyone's car can be so wildly different! They can be small, massive, super long, super wide, carrying a whole lot of cargo, wielding a massive robotic arm, or even more. So, we encourage experimentation on your specific vehicles to find the right calibration for the kind of handling you'd like.

Thank you all for your feedback on our previous tutorial video - let us know what you'd like us to teach next!

Hey all! We've been loving your enjoyment and feedback of our in-game tutorial. We definitely want to build more in-game tutorials for more specific features, but we've also decided to start a new series of video tutorials too!

Our first video tutorial is on how to build a simple car in just one minute:

The next Brickadia video tutorial will be about vehicle tuning - guidance on how to create cars that are more fun to drive. Our video tutorials are going to always be uploaded in full on our Youtube channel with shorter versions on all of our other social medias, so follow and subscribe to become the most skilled builder around!

So, it happened. After quite a bit of time, Brickadia Early Access is available for people to play! We still can't really believe it.

We've been loving your creations on the Gallery. We saw a concurrent player peak just a little higher than what we had in the free demo, which is amazing for day 1 of the paid release! We also saw a really nice amount of engagement with lots of servers being put up and plenty of players running around doing things.

Short Term Roadmap

Bugs

It turns out the best way to find out how many bugs your Early Access game really has is to launch it! While we've tracked and fixed dozens of bugs during the closed beta, there are still a few more we didn't manage to get to in time.

Notably there are lots of crashes coming in from AMD. For now we've made the game switch all AMD users to DX11 by default as that seems to not crash. We've also bought one of the affected AMD GPUs and began debugging it, but it only arrived today, so it will take a while to fix the DX12 mode.

We're going to address the most critical issues as they pop up while we work on the new features. The first hotfix went out today, with more coming over the next weeks.

Gamemode System

The Minigame system we currently have is causing a bunch of problems and badly needs an update. It was made for Alpha 4, where it wasn't really possible to make any kind of real gamemode, and was meant more to help players mess around together in an otherwise building-focused server.

Over the coming months, we'll be working on a Gamemode system that will replace it. There will only be one Gamemode supported in a server, but Gamemodes will be much easier to use than Minigames and much more powerful. Crucially, they will be much easier not to use incorrectly, resulting in people who downloaded your world spawning outside it and other issues.

It'll be designed for hosts, rather than random players who want to deathmatch in the middle of a server hosted by someone else. In addition, once your Gamemode is done, you'll be able to put it on the gallery alongside all its internal wires, due to a feature called Gamemode Microchips we'll talk about in the next section!

Don't worry for your existing worlds with a default minigame set up - everything should port over sensibly. In fact, due to the removal of the "included bricks" system, many worlds that are currently broken will immediately be fixed!

Wires V2 - Come on... More Stuff!

Wires V2 is an upgrade we made to the wires system for EA. It turns your wire contraptions into a graph that is stored on the server, like this:

Wires are now automatically organized into a dependency graph so we can update all gates in the correct order in a single step. This means you can build arbitrarily complex circuits without having to deal with any of the problems getting multiple signals to arrive at the same time like in the demo! The new system is also massively faster.

This does add a new restriction - the graph can't have cycles, so you need to break your circuit up with delays. But it also means things that were slow in the NextFest demo can suddenly run very very fast:

It also means that there are no more "false" states. Unlike the demo, wire circuits fully update when an input changed, rather than signals taking 1 tick to propagate.

The new system has allowed us to add something called Exec wires. Exec wires make wires into a scripting system, by passing along a pure "update" signal rather than data. Any data passed into an exec port becomes an update signal if it changed to a nonzero value. Unlike the demo, this lets actions run in a chain:

Unfortunately, making the system itself took so long that we could barely include any gates aside from rewrites of the ones we already included in the NextFest demo! Which is a shame - because once those are in, Wires V2 will really start to shine.

Our plans for the following weeks are thus:

• Microchips - compress your logic circuits into a single 1x1f brick. Create entirely custom gates by combining the gates that come with the game!
• Variables and Branching - Store, read and write values when your wire nodes run. No more manually building flip flops or using the blend gate to store data!
• Proper Gamemode Support - MANY more gates for responding to minigame events like new rounds, custom chat commands, entity manipulation and more!
• Gamemode & Player Microchips - Store information on your gamemode/minigame and on players via microchip grids that save and load. Create callable circuits and build a fully reuseable gamemode - just with wires!
• Implicit Input Combining - Wire multiple things into one input. Booleans implicitly OR, numbers implicitly add, execs implicitly union. In some cases, save tens of gates!
• And Much More - Array variables and iteration, queues that can wait for many events with parameters, loops, data displays, strings, kinematic joints, entity homes, and more...

New Prefab System

This sadly didn't make the cut for the initial Early Access release, but we're very close to having our new prefab system completed.

The new prefab system finally replaces our legacy "brs" save files from the first alpha version, which can only store bricks from a single grid in a very inefficient manner, with a completely redesigned one based on the worlds format. We will include a brs -> brz converter with the release so old builds can still be loaded in.

Prefabs will then be able to contain full physics contraptions, properly tuned cars (including their wheels!), logic computers, and whatever else you can think of.

They're going to be integrated with the main catalog UI, so you can put prefabs in your hotbar the same way you do with bricks and entities. And we're adding a gallery for them so you can share them with others.

Bots

This was actually one of the most requested features to the game that we've been able to see, with lots of players having a strong desire to use bots to make zombie servers, or simply adding ambient NPCs that roam about the map. We didn't have strong plans for this, but we think it'll be cool to throw in as soon as we can especially with our focus on adding more gameplay features.

The initial version of bots will be ready soon, letting them hold different weapons, move around randomly, and be controlled through wires. This is only the starting stage, but we'd like to get this out the door quickly so that people can start experimenting with them. Here's a preview:

They will be improved over time, with features like smarter navigation, direct wire controlling, and a special bot type to replace players that disconnect from a minigame. These features might take a while to get to, depending on priorities once the first version is released.

Sounds

A much smaller but still prevalent complaint that was brought up, presumably from the excess of deathmatch servers, was the difficulty of hearing other players when they were walking around. If someone was sneaking up on you, you could barely hear them!

We'll be adding a bunch of smaller features to try to allow hosts to set up exactly how they want such things to work in their server. This requires certain systems to be rewritten first, but we'd like for the game to support dynamically changing how loud and how far certain sounds are on a team basis for minigames. You should also be able to change how a team perceives sound, such as making teammates sound quieter than enemies.

This is one of the lower priority changes, so we have no ETA on when that will happen. In the meantime, more sounds are going to be added to the audio components, as well as the environment settings. If you've got any desires, feel free to suggest them in the Discord!

And More...

• Aircraft - We've been experimenting in the last 2 days with tools for making aircraft. There is nothing that is showable yet but we expect this feature to develop quite quickly, so I've included it here.
• Better Admin Tools
  • Finder tool server admins can use to see a tree view of all entities in the world and find hidden or far-away spam entities.
  • "Home" positions for entities that they return to when respawned, leave the world, or when the gamemode is reset (mentioned with wire changes above).
  • Better, more in depth permissions for players - we've already started on this one!
• Avatars on the Gallery - It's coming, folks! We're just working on what the UI looks like.

Long Term Roadmap

While it's too early to fully get into details, we have quite a lot of other features we're interested in adding to the game, over the next year.

• Editable Voxel Terrain - Building terrain is super hard! It's so difficult and tedious for even experienced builders that it causes them to not try to build things. Unfortunately, if you don't build any terrain, Brickadia currently imposes upon you a very heavy visual punishment - the sight of bare plate as far as the eye can see. Terrain would fix this.
• Destruction - You've probably tried blowing up a wall of bricks with a rocket and noticed that nothing happened whatsoever. So lame! Luckily we're going to do something about it.
• Scripting - We're moving into prototyping for this. Luau is currently on the table, but research is ongoing. Stay tuned.
• Custom Content (Modding) - We have existing plans for how common types of custom content can be added to the game and automatically replicate to players joining servers. It's very much on our minds still!
  
  PS: We have removed all technical measures preventing modification of the game such as package signing and obfuscation. These were leftover from the Open Alpha and never intended to ship in the release. While we don't think this is the correct approach for a multiplayer game in the end, feel free to mess around locally in the interim. There will be no support.

Anything Else?

We'll be keeping our ear to the ground on what our players think is vital to add to the game. The things that we prioritize will change over time, so make sure to provide your feedback on what you think is most important, or if there's anything we haven't yet mentioned you want to see.

That's it for now! If your game doesn't work, let us know and hang tight, we'll fix it. Otherwise, we hope you are having fun! This is just the beginning of our journey.

Hey, everyone!

After this long journey of development, we first want to thank you all for joining us on this incredible adventure that has been the creation of Brickadia. We’re beyond excited to finally announce that Brickadia Early Access is NOW LIVE on Steam! To celebrate, we’ve put together a launch trailer made entirely with in-game footage, check it out below! 👇

This isn’t the typical Early Access release, Brickadia Early Access already feels like a full game, completely polished and content-rich. With constant updates planned based on your feedback, it’s only going to get better from here.

What are you waiting for? The world of Brickadia is yours to shape, one brick at a time. Join Early Access now and unleash your imagination!

https://store.steampowered.com/app/2199420/Brickadia/

As always, thank you for being part of the journey as we build Brickadia together ♥️. 

We can’t wait to see the game in your libraries and your creations on social media with #Brickadia!

Look for Brickadia on Bluesky, Twitter/X, TikTok, YouTube, Instagram and join the always growing community on Discord.

Welcome to a new little blog series we're doing in the run up to Early Access. We currently don't have time to write huge technical dev logs like we did in the past, but there are still a lot of new features to talk about! So, we decided to instead post a bunch of little blogs whenever something is ready without losing ourselves too much in the details.

Today we'll talk about a few optional graphics enhancements you can use if "Ultra" just isn't good enough for you and you would really like to use your GPU for heating your room in the winter.

Introduction

Before we start, you can watch this video demonstrating what it looks like with all the features enabled. We had to wait over a day for YouTube to process the video and actually make the 4k60 HDR option available. Isn't that crazy?👇

HDR Output, Episode 2

If you remember our post from a year ago, we actually talked about this before.

The only problem was that since that previous post, we had upgraded to Unreal Engine 5.5 just before the demo, and naturally Epic had managed to somehow break the HDR in the new engine version. This is what were greeted with after the update when a user enabled HDR and opened any UI:

Luckily, this turned out to be easily fixed after some investigation in RenderDoc. They had merely forgotten to clear a render target before using it, causing all this garbage data to be displayed on screen.

There was also a second issue where having the avatar editor on screen turned the background black. That one was more involved, but is also fixed now - to render the avatar editor we now first blur the background in HDR, render most of the UI, render the avatar background on top of the blurred HDR render target and cut a hole into the UI where it should show, and finally composite everything back together into the final output.

These images were captured in 4k HDR using Xbox Game Bar on Windows 11, which writes a JPEG-XR file, and then converted to AVIF using this tool I found, so they can display in the browser. On my computer, the version in the browser looks exactly the same as the game, but I have no idea if that works for you too.

Some troubleshooting if the images don't display correctly:

• If you don't have a HDR monitor, you can't view them.
• If you have HDR disabled in Windows, enable it.
• If you are using Edge or Firefox or something else, use Chrome.
• If you are using Chrome but the images are too dark, change the HDR brightness balance setting in Windows, or change the dynamic tone mapping setting on your display's menu.
• If you are not using Windows, I can't help you.

Lumen & Hardware Ray Tracing

Remember how we implemented support for hardware ray tracing bricks a long time ago? That code had gotten a little scuffed up over the years and was no longer functioning in the demo, but I just fixed it up. Hardware ray tracing is now back for Early Access, it's also quite a bit faster since back then (but still slow...).

In the mean time, Epic had made lots of progress on Lumen. Since we are now on Unreal Engine 5.5, I thought I'd give it another try. We still don't have distance fields to be able to use software ray tracing, but what if we could make the hardware ray tracing path work?

Naturally the first attempt did not work at all. We weren't getting any information from HWRT to Lumen whatsoever:

Since I had never really worked with Lumen before, I opened up an Unreal Engine example project to see how this view should look, and theirs is... quite different, wouldn't you say?

Turns out most of that was just because I had purposefully broken the lumen scene some time ago while making Proto Lumen. Let's revert that change so it only applies when we are actually running in Proto Lumen mode...

The bigger problem is that our bricks are still broken.

It turns out Lumen requires something called a Surface Cache to work properly. Basically, we have to cover our meshes with planes onto which it will render indirect lighting. Of course the code Epic made to do this for normal meshes only works in the editor and is extremely slow as it is intended for offline processing.

How do we do this? We could just write a more optimized version of their code that works at runtime. They are doing ray tracing against the meshes on the CPU side and it can take like half a second to process a single mesh this way. When we build clusters for a large build, we have thousands of meshes.

To do it at runtime, we'll do all of the following:

• We will use the embree4 library to trace the rays, making full use of its capability to trace 8 rays in parallel with AVX instructions.
• We will use our low detail mesh as input for each brick cluster.
• We will use very few rays, accepting a mediocre real-time result.

The full algorithm ends up as the following: it will take the low detail mesh we build for the brick cluster, convert this to an embree4 scene to be able to ray trace it on CPU, overlay a 32x32x32 voxel grid, then for each face of the grid (6) it will trace rays through the grid to hit the mesh, generating layers of surfels at the hit surfaces, trace additional rays to determine if some hits might be "inside" the mesh only and useless, then cluster those surfels to finally end up with the set of most significant surfaces to output as cards.

Our implementation of this is now so fast that it barely increases the time it takes to generate brick clusters.

In real builds, it looks significantly more cluttered, but it works surprisingly well. We don't always cover every surface since the brick clusters may randomly include multiple hollow structures, but we get most of them which is enough for the whole system to work.

Almost every build I've tried had ended up with a usable surface cache.

Let's get rid of those annoying debug views so we can appreciate the glory.

Yes, it does ray traced reflections too.

Almost feels like a real-time photo mode, rivaling the old path tracer we used to have. I've never seen a building game capable of looking this good before...

The memory usage and performance of this mode can be quite heavy. Epic has several performance optimizations in Unreal Engine 5.6, but we won't be able to get that in before release. If it doesn't currently run well on your computer yet, maybe it will once we upgrade to that.

Well, that's all for this preview. There are going to be many more before we reach Early Access. Stay tuned!

Hey everyone!

You’ve been asking us everywhere, and we can finally say it: Brickadia is launching in Early Access on July 11, 2025, on Steam - We can’t tell you how excited we are to finally write those words!. And we’re making this announcement in style, with a new montage trailer made entirely from in-game footage. Check it out below 👇

Here’s what we can share right now: the Early Access version will feel like the full game experience from day one, with the extra-benefit that it’ll come at a lower price than the final release. It’ll be your chance to jump into Brickadia early and be part of something big as it evolves. So for now, don’t forget to wishlist the game on our Steam page.

As always, thank you for being part of the journey as we build Brickadia together. We can’t wait to see the game in your libraries, we're almost there!

For more regular updates, join our Discord!

And to make sure you don’t miss anything, let us remind you about our official Brickadia newsletter - in it, you’ll get everything from the latest game updates to behind-the-scenes news, and even a chance to be selected for an exclusive closed beta ahead of Early Access!

Sounds interesting? 👇 

Hey everyone! With Steam Next Fest wrapped up, we're now full steam ahead, working toward our Early Access release. From the bottom of our hearts, we want to thank everyone, especially our amazing community, for participating in the Demo!

We loved playing with your different worlds and meeting new players and veterans alike. The creativity on display is genuinely beyond our imaginations! Seriously, thank you. We love this community❤️!

Survey Results
Feedback
 Horrible hit detection
 Vehicles are hard to control, slip, and clip often
 No prefab support for physics grids
 Griefing physics contraptions is too easy
 The Tutorial is clunky, unclear and confusing
 Limited gameplay gate options
Plans for EA
 Improved tools and prefabs support
 Improved combat and hit detection
 The Gallery
 Improved physics and vehicle handling
 Wires V2
 New Game Mode system
 Tutorial World
Key Giveaway
Community Showcase

Survey Results

Near the start of the demo, we put out a survey to help us gauge where we are doing things right, where we fell short, and where we should aim our development goals toward. Nearly 2,000 people submitted their surveys, and there are some interesting findings! That is roughly 5.5% of demo players submitting the survey. Thank you to everyone who submitted one.

First, some fun statistics (unfortunately, non-interactive on here).

Roughly half of players who filled the survey indicate they played the Open Alpha. This is interesting, as only about 10% of total players linked an Open Alpha account:

We have an overwhelming majority of male users:

Our main audience appears to be young adults currently:

The majority of players prefer playing in small friend groups:

During the demo, most people focused on dressing up their avatars and exploring existing worlds, which is about what we expected:

Surprisingly, the most liked built-in world was Officecorp Inc! We didn't know we had so many single player puzzle enjoyers among us:

Most of you were happy with the visuals and performance of the game, but we can still improve on making the interface easier to use:

The avatar editor was well liked in general, though some people are still wishing for even more options, despite us already having hundreds of parts!

It's very interesting how the mouse controls and keyboard controls were rated nearly the same. I think there is still room for improvement here:

Using the hammer to delete bricks is the easiest tool to use. Who could have thought?

Most of you prefer the streamlined mouse building control scheme:

We experimented with a lot of ways to integrate removing bricks into the builder, but it seems the hammer is still the most popular:

We are frankly surprised by how high you have rated the stability of the physics in the demo. Are our standards too high?

Most of you said you were able to figure out some basic contraptions:

Everyone figured out how to drive a vehicle but it was much harder to make a new one that drives well:

Your most desired future features seem to already align with our goals for Early Access and beyond:

It's clear that those of you who filled the survey were already very invested in the game:

Feedback

There was a ton of amazing feedback posted on the survey, on Discord, and on Steam, and we've been reading all that we could. Here's a list of things that you all made very clear needs improving (in no particular order):

Horrible hit detection

Hit detection has degraded noticeably from Alpha 5 (which already had subpar hit detection).

The Alpha 5 version of hit registration is based on an unfinished rollback model, where the server validates hits by rewinding time to see where you hit the enemy on your screen. Unfortunately, the solution implemented isn't perfect due to many factors, and it has seemingly gotten worse due to latency issues from EOS P2P and bugs from engine upgrades.

Another issue with weapons is that bullets come from the muzzle of your gun. Seems realistic and reasonable, but in practice, it is very easy to hit obstacles blocking your shot instead of your target in first person. It makes gun fights in corridors and nearby obstacles very annoying.

Vehicles are hard to control, slip, and clip often

One of the more common problems faced in the demo was vehicles flipping over and having little traction. Plus, since we're using actual physical wheels that actually spin, there's quite a bit of unstable behavior that occurs (especially at lower frame rates!). Additionally, climbing up plate bricks is a bumpy ride.

There were also many cases of "clipping" that occurs when two brick grids interact on a seam. You may have ran into this going up ramps or roads on vehicles where the chassis is low to the ground. This is an inherent limitation of how contacts are generated with physics. This has been mitigated with wheels, but not with brick grids. You can see the core of the issue here:

No prefab support for physics grids

The demo still employs the same old saving system from Alpha 5, which never supported multiple physics grids or entities.

Additionally, the Selector tool is still functionally similar to the one in Alpha 5, with the addition of working with brick grids and some usability updates (like splitting grids apart). However, it's not possible to copy/paste an entire contraption at once!

Griefing physics contraptions is too easy

The demo was intended for playing with trusted users only, and therefore barely had any restrictions on physics objects or their interactions. A few brave souls who dared to host a public server soon found out that there is a reason why we did not include the server browser at first as their creation became permanently covered in thousands of wheels and their vehicles lost to outer space.

Another very common request was to be able to define home positions for contraptions and vehicles so you can reset them with the minigame (or even through wires).

The Tutorial is clunky, unclear, and confusing

The demo became super invaluable for us in improving this area. Tons of new users struggled with not only the content of the tutorial, but also in the way the tutorial is presented. It is very clunky to press "M" on your keyboard to free the mouse, just to be able to interact with the tutorial. We've seen many screenshots where the tutorial widget is still stuck on in the player's HUD, no good!

We quickly added some UX improvements during the demo, such as the third-person interaction prompts to tackle some of the low-points, but there is still plenty to improve here.

Limited gameplay gate options

Wires and the new logic/gameplay gates have opened tons of possibilities for players (and you all have done some insanely creative things with just the ones available!)

There is definitely some room to improve here, especially when interacting with Gamemode features. For example, it's not possible to join a team using wires, detect when a round of deathmatch ended, add score, compare score... etc.

In the Demo, it wasn't really possible to make anything too groundbreaking when making gamemodes. (Though, there were some creative usages of physics and wires to make games like payload and survive-the-falling-cars!)

Plans for EA

We want the launch of Early Access to have the right foundations and the best possible user experience we can muster, but we also don't want to launch the game next year. So, the changes below from what you saw in the demo are our MVP for Early Access, and we are currently targeting a release in July 2025.

Improved tools and prefab support

Tackling the issue of saving vehicles and other physics contraptions, we will be upgrading the prefab system to support the new features that BRS did not.

The Selector will also be getting a big upgrade, such as being able to select or deselect individual bricks, and select by brick grids, which should make the Selector much more powerful than just only being able to select a box-volume.

Improved combat and hit detection

Improving the hit detection has been fairly tricky, and originally we wanted the combat system to be very precise. On the technical side, it implements a rollback system (similar to Counter-Strike 2) to ensure hits happened where they happened on your screen. At least, in theory, that is supposed to be what happens.

Due to various factors like Unreal Engine missing fixed-tick character movement, network replication and compensation, the implementation isn't very effective. We will likely move towards favoring client hits, with less aggressive server-side "sanity" checks and/or simplifying the implementation.

And another small but impactful change: the physical muzzle of your gun being blocked will no longer stop bullets the way it used to. Makes it much simpler to build maps that work correctly in first person.

The Gallery

The Gallery is a new feature coming to EA, where you can share your creations with others. It comes with full in-game integration, enabling you to easily find and upload content for all things Brickadia.

We will likely have a blog post detailing all the features and goodies that the Gallery adds, stay tuned!

Improved physics and vehicle handling

As mentioned earlier with clipping, this issue is unfortunately a limitation of physics engines. But, there are things we can do to (hopefully!) fix this, such as implementing sweep-based vehicles/wheels. Definitely stay tuned for a future blog post on this!

We plan on adding various weight bricks / the ability to change your vehicle's center of mass, which should help improve vehicles from tipping over. Increasing the tire friction is an obvious next step after improving these, and improving the handling of vehicles, especially at high speeds.

Wires V2

One of the limitations of gates in the version of wires that shipped in the demo was the reliance on brick components to implement their functionality. This puts many limitations on what gates can do, like having a variable number of ports, or supporting different wire types.

Wires v2 introduces "generic" gates, allowing us to implement gates for many different wire types. This is particularly useful for math gates that support integer and float/double math. Additionally, logic gates will benefit by having any number of inputs/outputs, and will let us design new types of gates such as selectors that need the flexibility.

Anyone who tried creating a complex contraption will likely have noticed timing issues where signals take different time to propagate down paths of different lengths, or even managed to get your gates stuck flickering in a loop for seemingly no reason. While this might be neat in a hardware simulator, it is extremely annoying if you are trying to make things just work. For the new version of wires, the system will correctly order the gates by their dependencies and propagate everything in a single tick.

A new gate, the Microchip, will also allow you to compact entire logic gate circuits into a single gate. A great utility of it is being able to modularize your wire circuits and share them on the Gallery! Plus, there are some really exciting things Microchips enable, as you'll read below.

New Game Mode system

We will be replacing the ancient minigames system with gamemodes! Functionally, they will work very similar, and our plan is to keep as much familiarity between both as possible, while improving the UX and confusion around setting up minigames.

Game modes will be able to be packaged up into a bundle that you can activate independently from the worlds, so you can easily combine different maps with playing different modes on them.

Problems with the old minigame system included figuring out which bricks/entities should be part of the minigame and unclear configuration, which leads many users (even experienced ones) to wonder why things just don't work the way they expect when creating minigames.

Once we're happy with the new UX, we're expanding the power of gamemodes in a dramatic way.

As mentioned before, we're adding the Microchip, a useful tool in the wiring arsenal for compacting circuit designs. In the context of gamemodes, they get a whole lot more powerful and interesting:

Microchips can also be attached to players, or directly integrated in your gamemodes to add new logic. Originally, we wanted to wait on Behaviors (our scripting language) to bring this ability, but it seems obvious that wires are a great fit here too, so we're adding it for EA!

We will be adding onto the collection of gates available, allowing you to do even more powerful things, like listen to game mode and player events, and do things with those events when used in conjunction with the Microchip.

Tutorial World

The tutorial widget we had in the demo, while it helped a little, definitely left many users confused. For EA, we plan to include a detailed Tutorial world that guides you through many of Brickadia's building features, one by one, in an approachable manner.

If your favorite future feature isn't listed yet, don't worry! This journey continues on far beyond Early Access.

Key Giveaway

For those who opted-in to the key giveaway in the survey, we've gone ahead and emailed the randomly selected 5 winners a Steam key. Congratulations to the winners, you will be able to play the game as soon as it releases!

Thank you!

And to everyone that had a chance to play the demo, thank you! For those who haven't seen any of the amazingly creative builds users have built, here is just a handful of ones we picked from our Discord and socials:

And finally, some crazy devices that employ sound. Take a listen!

We’re really excited about what’s coming next, and we can’t wait to share more with you soon. As always, thanks for all your feedback and support—it means the world to us! If you have additional feedback, you can always drop by our Discord (we're active there!), or send us a message through any of our social medias.

And lastly, Happy Frog Day! Wait, what do you mean it's not Frog Day anymore, and it was last week? Oh well, have this frog anyway.

Hey everyone, a short post for once! We're extremely happy to announce that the Brickadia Next Fest Demo is now available for download through Steam for a limited time! If you're here to play the game, you can click here for the Steam page to download the demo. For everyone else still here (you should go play the demo instead!), read on.

Our Next Fest Demo includes almost every feature we've been cooking up over the last few years, including physics contraptions, drive-able vehicles, wires, and our world system, and of course our brick-building system that supports millions of bricks at the core of it. If you haven't seen the brand new trailer for this demo, it was filmed entirely in-game in this demo!

What does this demo not include? Behaviors, the new gamemodes system, and the Gallery. Our planned Behaviors scripting system is on the back burner at the moment as we have been focusing on wires and logic gates first! This demo currently has the same old "mini-games" system as our old Alpha had - this system is planned to be replaced with a simpler, more flexible gamemode system in Early Access, but currently this hasn't been implemented yet for this demo. Our Gallery is also not ready yet - but we do really want it to be part of the proper Early Access release as it will let everyone properly share their creations and instantly load into other peoples awesome worlds.

A very exciting day for Brickadia indeed! This isn't our full Early Access release yet, but releasing a brand new demo showcasing the current state of our game is still a giant leap forward for us. We really look forward to seeing what you all create in this demo - please post your creations in our Discord, on social media, and in the subreddit. We love to see them!

We will have a survey available towards the end of the Demo. Please give us your honest thoughts and suggestions as that will shape the direction we take the first Early Access release.

As always, thank you for reading. And go play the Demo! Stay tuned.

Today we're going to be dipping our toes into two big Early Access features that haven't been discussed much on the blog: Wires and Vehicles. We'll also go over all the other cool stuff that the team did in 2024!

But before all that, we have an announcement: In February, we'll be joining the Steam Next Fest with a time-limited demo! During the fest, you'll be able to get your hands on an early preview of all the new creative features we've been cooking for the past few years!

The Next Fest build will be our Creator Demo, a build of the game that will focus on building and creators. The demo will be available from February 24 at 10 AM Pacific to March 3. We'll share more on this demo as we get closer to the Fest!

To be notified, add Brickadia to your wishlist on Steam.

Building Tool Improvements
 Offsetting From the Plane Lock Plane
 Follow Mode and Precision Mode
  New "arcball" rotation controls
  Reorient rotation still exists
  In follow mode, player now faces the brick
 Negative Spacing
 Upgraded Pie Menu
 Default "Loadout" of Bricks
 Correct Grid Snapping (To Edge/Over Edge)
 Align Half-Plate Thick Bricks To Surface
 Inventory is Single-Quickbar Again
 Entities
 Improved Catalog Organization
Wires
 The Solution
 The Connector
 Buttons, Targets and Switches
 Logic Gates
 Wire Types
 Various Examples
Vehicles and Contraptions
 Joints
 Joints Being Used Ingame
 Seats
 Driveable Cars
 Various Examples
Other Stuff!
 Procedural Brick Generation
 Weapon Resources
 Homing Missile
 Pole Resizable in All Directions
 Other New Bricks
 Skirts and Dresses
OK That's Everything

Building Tool Improvements

I really should write a full blog on how these work but here's an outline of what I have at the moment.

Offsetting From the Plane Lock Plane

Plane lock was added back into the new mouse building controls with a new feature: You are now able to offset from the plane lock plane in plane lock by scrolling the mouse.

This creates this cool line between the actual lock grid and the raised one. It has a bunch of uses.

Follow Mode and Precision Mode

In a huge surprise to absolutely nobody, I remade Orbit Mode and Detached Mode. They are now renamed to Follow Mode and Precision Mode. These modes share essentially the same codebase with different keybinds. However, several things work much better:

New "arcball" rotation controls

The rotation in follow and precision mode now offers an "arcball" rotation scheme when you hold ctrl, inspired by that offered by games such as Space Engineers. What does "arcball" mean? It means rotation is now relative to the surface you're looking at. Left/Right/Up/Down will all rotate the surface 90 degrees to point in that direction without affecting other axis, while the additional rotate buttons will turn it counter-clockwise and clockwise. Take a look:

Reorient rotation still exists

Holding R still gives you reorient controls. Tapping in a direction will rotate your brick to face in that direction, exactly as is offered by the mouse controls:

In follow mode, player now faces the brick

Finally, as a last little polish feature, your player will now "look" at what you are doing while you're in follow mode. Other clients see this too.

Negative Spacing

A very oft-requested feature since we added the ability to row-drag templates, and especially since we gave testers the ability to grid and volume-drag them has been negative spacing. Negative spacing allows you to overlap instances of the template you're dragging, making it possible to place a template that interlocks with itself.

The simplest example of course is a brick wall like here.

But there are more advanced cases, especially when you're placing wires (which we'll talk about in a bit) which auto-attach when overlapped with the same brick type attached within the template:

Upgraded Pie Menu

The tool pie menu now has descriptions.

When you select the Placer from the pie menu, you'll select the last brick you had selected, or else the first brick found in your inventory, or else a 1x1f will be thrown in the TEMP slot and you'll select that.

Default "Loadout" of Bricks

The quickbar now has things in it without you having to open the catalog and add them, which greatly confused people who came by our booth when we showed the game at a convention in November.

The default loadout is very transparently the minimal kit for building a car (don't worry, we'll get to cars):

Correct Grid Snapping (To Edge/Over Edge)

In alpha 5, when you are in one of the keyboard building modes (follow/precision as they're now called) your brick has never actually moved or aligned to the grid properly. Thankfully, the only way to notice this was to try and use a micro-brick, or some other brick that wasn't large enough to align to the grid.

In mouse mode, Alpha 5 can align your brick the way we intended - to the nearest edge of the aimed-at grid cell. It's only follow and precision mode that are broken (actually, quite a lot of the Alpha 5 building is broken).

What follow and precision mode actually should have been able to do was move bricks that are smaller than the grid cell on the move axis "to, then over" the grid cell's border, which oftentimes is an uneven movement per button press and so can't be done by simply offsetting the brick each key press. This corrected "to, then over" movement is how it works in Early Access.

Align Half-Plate Thick Bricks To Surface

When you have the plate grid alignment mode selected (you literally must give it a try!) try aiming at the surface of a micro-brick or some other surface that does not align to that grid in Alpha 5. Your brick will float.

What's worse is that this can be hard to notice from a distance, so you get done building something and then find it floating an uncorrectable (1-2 unit) distance off the ground.

In Early Access, your brick aligns to the depth of the surface you're looking at, even in Plate mode, as long as it isn't inside the bounds of a brick. So your micro-brick will actually place against off grid surfaces in Early Access:

Also notable here, but easy to miss - resize dragging moves the size up to the first grid edge for the first resize increment, then expands to fill further grid cells.

Inventory is Single-Quickbar Again

Many of you commented on the section of the last blog post saying that the multiple quickbars and increased inventory size may be difficult to deal with for new players. This is exactly what we found during testing, so they've been removed.

Entities

Since adding entities, we have added exactly two (2) entity types so far.

The first is a ball that can be painted and resized. As always, I forgot to add a size limit.

But then we have the current main use case of entities: Wheels. Wheels make perfect sense not to be bricks - they get to have proper analytical collision and they do not waste the server's processing power managing another brick grid. There are countless wheels in the game so far and here are a few of them:

Improved Catalog Organization

Confidentbottle has improved a bunch of stuff relating to the organization of the default catalog. First and foremost, the Entities tab is gone as there were not enough entities in the game to justify it. Instead, the Bricks tab is now an Objects tab:

Categories have been reordered to make more sense, with bricks you'll want to use first prioritized rather than the alphabetically ordered sets of Alpha 5.

Also, Micro-Bricks now have their own tab and are actually ordered sensibly, meaning you don't have to scroll right to the bottom to get at the regular cubes.

All the magical gameplay bricks and entities are spread across 3 categories, rather than ending up hidden in Special;

• Physics stores bricks and entities meant for making physics contraptions.
• Mechanics stores bricks and entities meant for making interactive machines or experiences.
• Logic Gates stores the logic gates provided to users of the wire system.

Wires

Back when we were thinking about the design of our still TBA scripting language, Behaviors, we very quickly realized that most of our players wouldn't want to have to use it to do simple things. No matter how approachable you make your scripting system, the more it can do, the more complex it has to be - and the more daunting it becomes to beginners.

But why should they have to learn what a function is, what bindings are, what symbols and variables and booleans and parameters are, just to make a switch open a door?

Or even to make the correct combination of switch values open a door?

These are use cases so simple that they shouldn't even have to go through scripting at all.

The Solution

If you've read previous blog posts, you already know this bit, but for new people I'm going to go over it again;

Conveniently, everything in Brickadia is data-driven - i.e. has a state that can be controlled very directly by reading and changing variables. Let's simply designate some variables outputs, and some variables inputs, and let players designate "links" between a given output and multiple inputs somewhere else. When the output variable changes, linked input variables are set to the same value.

This "link" is all a wire is.

The Connector

To attach wires, we have this tool, the connector. The connector lets you connect wires between physical ports in 2 clicks. For bricks without those, you can select your source or target port from a list instead:

As always, we've added a bunch of QoL features to the Connector to make it super easy to work with. You can hit R to restart connecting from the last port and hold Ctrl to multi-connect. The GUI has a quick fuzzy find search where you can press enter to choose the first port in the current results.

You're probably wondering if there's a way to organize these wires better. There is! Rerouter bricks. With the Rerouter brick, you can always organize your wires super nicely.

Buttons, Targets and Switches

We have 3 inputs to the wire system right now, none of which support animations yet:

Switches can be clicked to toggle their output signal between off and on. There are a lot of use cases.

Buttons emit an on signal while your mouse is held and an off signal otherwise. Originally, they had an on-off time, but the "holding" functionality is far more versatile. For advanced use cases, you can even get a count for how many players are holding down one button.

Targets emit an on signal for a certain amount of time when shot with a projectile or hit with a melee weapon. If hit while on, their current "on" signal will be reset to that amount of time instead.

Logic Gates

There are a ton of gate bricks with physical ports (most of which you see in the catalog above) that you can route your wires through. The system is turing complete, and you can use it to do most things.

As an example, we can use an AND gate to make a door that opens only when two switches are flipped.

Or an OR gate to make an item collectable when one of two buttons are held.

Wire Types

You've probably noticed all the wires are red. Can they be other colors? Yes, they can!

A wire's color is determined by the type of data it carries. Red wires carry booleans, i.e. an on/off signal. But since wires can carry any property type, you can also send decimal numbers and do operations on those.

Since wires automatically convert between all the basic types, you can send boolean values into ports that take numbers (as 0 or 1) and vice versa (!= 0 is 1).

In addition to this, and as you saw above, everything always converts into a string - which is how we can display the value on interact at the end.

With integer numbers, you can do bitwise operations. So here's something more advanced that most of you won't ever need to do: With a bit of work, we can send 8 different booleans as a single integer value.

Various Examples

You can make lots of things in Brickadia with just wires and no scripting. Eventually, though, wiring contraptions together becomes more of an art itself. There are some things you really should be doing with scripting later. But of course, you don't have to, so maybe, just for fun, you don't.

The UX of wires is basically finished with just some polish and additional features down the line.

Vehicles & Contraptions

You are all long overdue for an explanation of our plans for this, but there is a lot to go over so I will try to be concise here.

Joints

The first part of vehicles we implemented were the basic bearing joints, which currently remain the only joints in the game. Right now, they come in 3 flavors; Bearing, Motor, Servo. To attach a brick to a joint, you simply place it on top of the joint.

The Bearing (left) simply rotates freely with customizable damping (damping is the force with which the joint tries to slow to a stop while spinning). It's good for making hinges for doors, windows and other things, but it can't do anything advanced.

The Motor (center) is your workhorse powered joint. When enabled, it will spin with constant power you set. You can make something that spins constantly such as a platform or part for a total wipeout course, and you can even combine it with wires to make things like deathrun traps, fairground rides, and mechanisms.

Finally, the Servo (right) is what you use when you want something to move to a specific position and to try with user-specified force to stay there. It can be used to make suspensions but is most useful when paired with wires, which you can use to make automatic doors, spinning counters, all sorts of things.

We have micro joints too!

Joints Being Used Ingame

There are lots of use cases. Here are some images and videos from recent dev media.

Seats

The obvious next thing to make was some way to sit down and be attached to whatever ride/pseudo-car/other miscellaneous deathtrap you made. That comes in the form of the Seat, which you can click on to sit in.

There is not much else to say here. If you put one on a physics contraption it works as expected.

Driveable Cars

Again we are left with the problem of how to make versatile behavior possible without forcing the user to do a lot of work. And just so we're on the same page, programming good vehicle control is hard, easy to do wrong, and not even the first problem we need to solve.

The first problem we need to solve is how to allow a player set up their car, which they have built out of a lot of small little bricks, to drive in a way that resembles sensible.

To demonstrate the solution I came up with, here's what we want to drive:

It would certainly be quite a stretch to call this a "vehicle", but I'm going to anyway.

We need to mount the wheels, but there's immediately a problem. If we put our wheels on the car with a Motor, they wouldn't be able to steer. Motors only turn.

Enter the Wheel Joint, which can steer and turn. It even has a built in suspension.

Already this is starting to look more like a car. We still can't drive it, though. Nothing is controlling the wheel joints.

There are many different schools of thought in sandbox games for how you tell the game how the player's controls control the car, but me? I'm partial to the approach taken by Robocraft and Spore (a creature is technically a vehicle, right?). That approach being: The game should figure out as much about how to drive and steer your creation as possible on its own, without you needing to be involved in every little decision.

But this is Brickadia, so we also want modularity. We want to be able to entirely exclude functionality we don't want, like gear switching and air control. And we want to be able to tweak things that make sense to tweak, like acceleration, braking force and top speed.

This means that first of all, we should add the least additional functionality to the Seat as possible. We should simply have the Seat emit a Control signal that we can use (or decompose into wire outputs) somewhere else.

What do we attach it to? Introducing the Wheel Engine.

The Wheel Engine's placement designates the forward direction for our vehicle, and also where the engine noise comes from. This means that even if the seat were placed like this:

The vehicle would still drive correctly. In fact, to make sure, let's leave that there. We'll put another one on the other side. For balance. And we'll also wire up the driver's seat.

The driver sits on the left side, so they're not in danger of being hit by traffic. I'm so glad we found a way to solve that design problem.

By the way, you don't have to use this big bulky engine if you don't want to. There is a small alternative that has all the same features.

The engine gets very happy when we sit down in the seat and makes a noise. But we can't drive yet because we gave it no control over the wheels.

How do we do that? It's easy. The engine takes the seat's input signal and translates it to a wheel control signal that we can wire into the wheel joints.

Let's do that now.

And now it drives!

And no, extremely keen eyed readers, you eyes are not deceiving you - the engine is calculating a steering box containing all the wheel joints and doing Ackermann Steering, which reduces wheel slipping and is what you find on most vehicles in the real world:

All this, too can be combined with wires. The engine is fully wire controllable!

Various Examples

The testing team have built vehicles that are, somehow, even better than mine. Here are some videos of their adventures:

Other Stuff!

Procedural Brick Generation

I have just finished the brick composer, a dev tool we can use to create new procedural brick types.

Without going too deep into detail, the brick composer is able to take a few carefully made mesh parts parts in blender, like these:

And by arranging them and retexturing them, create a fully realized resizable brick.

This generator is super powerful. It can already be used to make all but 3 of the 28 procedural brick types currently in the game. Of that 25, 16 (including all of the micro-bricks) can be made simply by opening Blender, cutting up the default cube a little bit and throwing some Dyn texture markings on its faces:

We plan to use it for many more bricks including the resizable slider joints.

Weapon Resources

Weapons now have a "resources" system.

There are several types of weapon ammo in Early Access:

• Arrows, used for Bows and Crossbows.
• Black Powder, used for old timey weapons like the Flintlock Pistol.
• Explosive Ammo, used for the Rocket Launcher & Grenade Launcher.
• Light Ammo, used for Pistols, SMGs and others.
• Medium Ammo, used for Assault Rifles, Machine Guns and others.
• Heavy Ammo, used for precision rifles.
• Magnum Ammo, used for Magnums, Revolvers, and the LAR.
• Plasma Ammo, used for heavy energy Sci-Fi weapons.
• Pulse Ammo, used for low energy Sci-Fi weapons.
• Shotgun Shells, used for shotguns.

But the resource system is made in such a way that weapon resources aren't just limited to ammo. Weapons can have individual resource values that they track to influence behavior - heat, charge, and more. There are no examples yet - for now, as a task, ammo is large enough.

Homing Missile

I saw a cool implementation of speed-conserving proportional navigation, a homing algorithm for projectiles, on the UE5 marketplace. It made me want to program my own from scratch, so here is Brickadia's very own homing missile in action:

Speakers

These come with an audio component pre-attached. Get some tunes on!

Pole Resizable in All Directions

I decided to unlock the pole's resizing and see what would happen. I expected the brick to break but with a few tweaks to the vertex count generation it's actually fine. So I've left it unlocked:

Other New Bricks

We have (a few) new decorative bricks that don't do anything at all!

Skirts and Dresses

OK, That's Everything

For more regular updates, join our Discord!

My favorite thing to do in Brickadia is watch other people build.

I'm always interested to see the cool things people are making, but I'm most interested in the techniques they use. How they make use of the tools we made - and how they don't. What I found out was in some cases surprising, and has fed into a lot of the new design decisions I've made.

Before we go further, make sure you're not browsing on mobile data! Here's a table of contents for this post:

What Needs Improvement?
Resize-Dragging rather than Row-Dragging
Unusable Brick Reorientation
No Visual Metrics
Bad New Player UX
Complicated Dual Inventory System
Too Little Inventory Space
Unable to Start Floating Builds
More Extensibility Desired
Rewrite the whole building system??
Upgrading the Inventory
Extensible Inventory Slots
More Inventory Space
Keeping your Character Inventory
Selecting Inventory Slots
Upgrading Building
The Core
Aligning Bricks with the Mouse
Placing Floating Bricks
Gizmos and the Preview Grid
Dragging Brick Rows (Old)
Dragging Brick Rows (New)
Resize-Dragging
Rotation and Reorientation
Tool Widgets
Tool Bind Hints
Selection Highlighting
More to Come!

What Needs Improvement?

First, let's talk about what we can learn from how players built in Alpha 5, and how we can use that information to improve the tools for Early Access.

Resize-Dragging rather than Row-Dragging

Years ago, we built Brickadia's original mouse building around point and click placement of bricks, and - as an afterthought intended for people making regular patterned things such as brick walls - made it so that if you click and move the mouse without releasing it, you drag out a row of bricks.

You can do the same thing with a brick template.

This is super efficient for placing rows of the same brick.

Brickadia also supports resizing bricks. It's a separate tool, here.

You can resize any brick to any valid size. If you like a certain size, you can pick it into the quickbar with Ctrl-MMB. You can have up to 10 bricks in your quickbar, which seems like enough for most tasks we can think of. And the resizer has quick binds for resizing to the minimum and maximum size:

And so, our thinking went, now all our builders have everything they need to make cool structures quickly. We released these features in the Open Alpha.

Here's how people actually used them:

First, you place a very small brick. Usually a 2x2x2 micro brick, sometimes larger. It's the only thing that's useful to have in your quickbar with this style of building, ever. The size it needs to be is your lowest common denominator - the smallest gap you'd ever need to fit it into, meaning smaller is better. Then, you switch to the resizer. You resize your very small brick to the size it actually needs to be. Then you start over.

At first this is clumsy. It feels bad. It feels like the game is broken. Slowly, though, you grow used to it. You bind the resizer to its own key. You go through this process tens of times, then hundreds of times, then thousands of times. It becomes muscle memory. You learn to do it without thinking. One building away, I'm standing on a roof, watching you. Horrified.

The problem here is that our iterative improvements to the game created a contradictory user experience:

• The placer is designed for a building experience where players build things by arranging non-resizable shapes of different sizes.
• Most of the bricks in Brickadia became dynamically resizable when the resizer was added in Alpha 4.

These players aren't doing this constant switching between the Placer and the Resizer to be annoying contrarians. To actually be able to leverage the resizability of almost every brick in the game, they're forced to do it. The placer tool doesn't let them do so on its own. To add insult to injury, the resizer doesn't snap brick sizes to the current alignment grid, so if you want plate sized micro-bricks you're forced to strain your wrists doing it carefully.

Resizing bricks directly as you place them would make a lot more sense. In reality, there are many more cases where you'd find it handy to resize a brick as you place, than cases where it's helpful to place a row of the same brick.

Therefore, clicking and dragging shouldn't default to row placing. It should place one brick, which resizes according to your drag. In addition, you should be able to resize the brick on all of the axes in one go, so you can make any size you want without ever needing the Resizer unless you want to modify an existing structure.

Obviously, the resizing should snap to the lines of the current placement grid too.

Unusable Brick Reorientation

This one is not that hard and we should have gotten it right the first time.

For most of Brickadia's lifespan it has been a pain to orient bricks to rotations where they are not upright. In Alpha 5, you do this using a horrible keybind called Cycle Brick Orientation (default keybind: Numpad /) that cycles through every possible brick orientation in an apparently random order;

You might notice I miss the orientation I wanted to stop at the first time and have to go through them all again. This is a result of years of training - most people miss the orientation they want at least twice.

This was actually an iterative improvement, because we only gave it a dedicated keybind in Alpha 5 - before then, you had to use advanced trickery with side studded bricks if you wanted to reorient a brick.

Let's get some insight into what's happening here. Brickadia stores which way your brick points in an enum (called EBrickDirection), with 6 possible values:

/** An axis aligned direction. */
enum class EBrickDirection : uint8
{
	X_Positive,
	X_Negative,
	Y_Positive,
	Y_Negative,
	Z_Positive,
	Z_Negative,
};

Cycle Brick Orientation might seem disordered, but it actually is ordered; it's going through the values of the EBrickDirection enum. This seemed like the way to go at the time, but the order it goes through orientations is actually so confusing that the Brickadia programmers are still the only people it makes sense to.

The fundamental problem is that it is meaningless to tell your players something is X+, Y-, etc, to try to come up with any "natural" order to cycle through the different directions, or to ask them to "set a direction" given a list like the one specified in EBrickDirection. You must let them point in a direction, and then resolve the axis and sign they wanted from that - you must translate how the user understands space to how the computer does.

No Visual Metrics

In the same vein, it's quite strange that not just Brickadia, but so many advanced creation tools find it sufficient to simply display measurements for things only on the HUD, when you're doing something in the world.

I recently watched a GDC talk called Keeping Level Designers in the Zone Through Level Editor Design, which for some reason is now unlisted. A lot of the talk is about texturing and pivots and other things not really relevant to Brickadia.

I found one specific point very interesting though: In Hammer, moveable brushes are positioned as boxes, where we instantly see the measurements of each edge displayed as text on that edge. Not as some "X by Y by Z" formatted size that we have no idea how to translate to the world.

By comparison, the information Brickadia shows you when resizing a brick is completely worthless:

Clearly we can do better here, as well.

Bad New Player UX

The HUD meant to teach users how to use the Placer is, to put it bluntly, programmer UI:

It uses only text, and it doesn't include certain key functions, like picking, at all. It's hard coded to display the default keybind rather than displaying the currently bound key name. In a particularly egregious case - the detached mode controls - it simply tells you to move the brick by using "Numpad".

In addition, prompts for keys aren't unified in any way. Down here is a little set of mystery icons meant to show new players how to open the inventory, use tools, use bricks etc, which do change to reflect your current bindings:

Painting has its own style of control prompts again. These, again, don't change to reflect your key bindings, but do change contextually as you navigate the menu.

And like the Placer, these are missing things like fill paint, which people have requested me to add to the game at least 15 times not knowing it's already there (alt-click with the paint tool) because there's no hint.

In Early Access we should show control prompts in a way that is more prominent, digestible, consistent, complete and reactive.

Complicated Dual Inventory System

This one was a little contentious. Basically, in Alpha 5, there are two character inventories. We have the brick inventory:

And the item inventory:

This pretty much always confuses new players who don't realize that they have two inventories and need to use Ctrl+Q to switch between them. They should be merged into one inventory which can contain both bricks and items, like Minecraft, Space Engineers, Stardew Valley, or basically any other game do.

Too Little Inventory Space

The inventory needs more space than just the 10 slots if we want people creating RPGs, salvage gamemodes and other experiences! This is doubly necessary after the last change as items now share space with bricks. Something that has been requested a lot is more than one quickbar, which advanced users could find very helpful.

We can design things so that only the currently selected quickbar is considered for adding new items, eliminating cases where new users might otherwise "lose" an item in a different quickbar.

Unable to Start Floating Builds

People often want to place things in mid air. Brickadia is supposed to be a game that is okay with you placing things in mid air. However, regardless of mode, the controls make this unreasonably hard. I always feel slightly embarrassed watching what people have to do to hoodwink the game into letting them do so.

To explain, let's say I want to start building an airship here:

My best options are:

• Aiming at some wall on the ground, plane locking and aiming up (the fastest way, but don't tell the mouse mode haters).
• Going into orbit mode on the ground and holding the "move up" button for an obnoxiously long time.
• Going into detached mode on the ground and holding the "move up" button for an obnoxiously long time.

You should just be able to position bricks in mid air at a set distance from your face. It should work like this: if you hold a 'float' key while in mouse mode, your ghost brick starts hovering at its current distance. If you're aiming at something too far away (like the sky), it will hover at a preset default distance instead.

More Extensibility Desired

This final new requirement is that the building system should be implemented in a modular way. That means the core Placer code should do very little, almost all functionality should be inside modes which are added on to it.

We currently have three types of modes:

Control Modes will implement the UX for handling user input and displaying output on the HUD. They will register a set of control hints to display on screen and can show or hide them from the HUD at any time.

We will continue to have three: Mouse, Orbit, and Detached mode. Implementing them as entire separate modes allows us to implement each mode more robustly as a state machine.

Alignment Modes will decide the behavior of the placement grid in all cases. At present, we have Plate, Half, Fifth, Tenth, and Brick.

Later we might add new alignment modes, or better yet, let the player define their own alignment grids for certain building styles like cube terrain.

And finally, Placement Modes will decide placement behavior. At present, we have Resize-Drag and the old Row-Drag.

Future placement modes could include a Circle-Drag or Frame-Drag. The way the system is designed will make it easy to extend, and all placement modes will work in all control modes.

We have our work cut out for us. Time to rewrite the whole building system!

Rewrite the whole building system??

There are many reasons we chose to rewrite the building mechanics in this case, even though we want to release the game some time this year still:

• The code for both the old inventory and building systems is almost entirely written in Blueprint prototypes (Unreal Engine's artist targeted visual scripting language), because we didn't really know what we were doing back then. Over the years this turned into literal spaghetti code, Blueprints are incredibly slow to refactor, cannot merge or version properly because of binary files, and there are no good tools to edit them other than Unreal's very clunky editor.
• There are now special bricks and other objects such as physics joints that you can place. Many of them need custom placement behavior. With the old Blueprint code, this was impossible to do in a reasonable way because the code is highly specialized to ordinary bricks.
• Important parts of the inventory system's "state", such as the brick inventory in its entirety and the current selected slot, were stored entirely client-side. This meant the server could never do things like know what bricks you have or what you have selected. This prevented us from implementing many long-desired features such as letting you put prefabs from the Gallery (more on that in later posts) in your quickbar.
• There was no modularity or real separation of the control modes (mouse, orbit, detached) and shared behaviors (alignment grid). Everything was either implemented multiple times for each case, or done by a shared function that had to be branch-heavy to the point of unreadability because of all the special cases. Nobody knows what parts you'd have to change to do X! And even if someone did...
• The blueprints were impossible to navigate and maintain, because there were so many functions and variables, and you can only view one at a time:

Why didn't we just buckle down and try extending this rather than a rewrite? Well, we sort of did, but it quickly became obvious it wasn't the way to go.

If you've been following the project for a while, you may have seen the recent Ferris wheel video in our #dev-media Discord channel, and the not-so-recent Physics Trailer. Those were made with prototype tools that were created by modifying (bodging) the building manger. And those prototype tools were not very good.

Here's me trying to build the Ferris wheel with them again, as a demonstration of how terrible it was the first time:

All the problems worked together to make the prototype UX this bad. It was slow for Zeblote to work with, and he had to really fight the fact that the building manager is written only for bricks, and has spaghetti-like code that is essentially working for every one of the neatly separated "modes" we designed above at once. Even if it were fully written in C++, this would have been very tiresome and resulted in wiping out most of the original code either way.

At the end of the day, addressing this kind of technical debt is something that just can't wait.

So let's get it done!

Upgrading the Inventory

Firstly, you will often see me use the expression "the inventory". But in Brickadia, at least in the Open Alpha, you really had three inventories: the Item Inventory, the Brick Inventory (client side only), and the Tool Inventory.

The Item Inventory lives on your character. It defines what appears in the quickbar, and in Alpha 5 it can only contain items. Because the character inventory lives on your character, it's fully lost when you die.

The Brick Inventory holds all the bricks you want to build with.

This inventory has a special extra slot in it called the TEMP slot. Something can be held in it temporarily, until you switch to another slot, at which point the TEMP slot is destroyed. This was mainly used for picking bricks from the world.

The Tool Inventory lives on your player controller, which can be seen as the "soul" that inhabits characters you control in Brickadia. Unlike the character, it's not recreated when you respawn - it's created once when you join a game, and deleted only when you leave. In addition, the tool inventory being here means you don't lose your tools when your character dies - they're kept.

We display the tool inventory via the tool pie menu:

The tool inventory can technically be edited by game modes, which will change what's in the pie menu! There's no particular reason it can't contain guns or, in the case of our new inventory changes, bricks. We just haven't added a way to do so.

Extensible Inventory Slots

In Alpha 5, inventory entries always store references to item actors. The game spawns item actors in the world when they are added to someone's inventory and hides them under the map until they're held, at which point it welds them to that player's hand(s) and plays any relevant animations.

We can visualise that inventory design like this:

You will notice it seems like this can't support bricks, even though we had a Brick Inventory in Alpha 5. That's exactly right! Alpha 5 only works because the Brick Inventory in Alpha 5 isn't real. It's a bunch of Blueprint hell where we create 11 widgets and store a brick reference on each one, and the UI widget calls a function on the building manager to change the current brick being placed. Which means the server has no idea, or authority over, what bricks you have!

The first thing we are going to do to fix this is throw out this separate, "fake" Brick Inventory and merge it into the Character Inventory. To do that we'll need to adapt our inventory to store bricks in it, which means we need a layer of indirection between the inventory and the different things you can store in it. Like this:

Entries point to an item that should be put in the player's hand when that entry is selected. As selecting a brick still needs to put the placer in your hand, we'll do something broadly the same as what A5 did - we'll create a placer instance with every player that joins the server, and put it in their hand when they have any brick selected in the quickbar.

More Inventory Space

Currently, our quickbar widget can only ever view the first 10 slots of the inventory - adding more doesn't work. But we can upgrade it to view specific ranges instead.

Here's what we do: When the widget is initialized, it takes the total inventory size and divides it by 10 to compute the quickbar count (i.e. 10). Now, you can switch between quickbars in order by CTRL-scrolling:

Or, you can press CTRL-[0-9] to go directly to a specific quickbar:

Keeping your Character Inventory

Doing all this has foregrounded an issue that already existed and was quite annoying in Brickadia's creative mode - when you die, either by physics damage or self destructing for a joke, your character inventory is cleared. The new problem? This now clears all the bricks in your inventory, too.

To fix this, I've added one more new feature: Keep Inventory. If you are in a minigame where this is on, or if you are not in a minigame at all, this feature will cause your inventory to be copied to your new character when you die. This means you don't lose your bricks, or any guns you spawned in for fun.

Selecting Inventory Slots

This mostly only exists for historical reasons at this point, but it seemed like an interesting tidbit nonetheless. When we were setting up the inventory system years ago, we wanted client side prediction for switching and firing weapons.

That meant the slot selection had to be routed through the character movement component in Unreal Engine. This wasn't easily extensible, but we had one free byte that could be used.

How do we select something out of two inventories and a TEMP slot using a single byte? Simple, we encode the current inventory selection in an int8 - a signed integer with 256 possible values, ranging from -128 to 127 - which we call an inventory index. We map inventory slots to the index like this:

• 0 is a special case. It means the player sending this index is not holding anything from any inventory.
• -1 is a special case. It means the player sending this index is holding whatever is in the TEMP slot.
• 1 to 100 select inventory items from the character inventory - you can get the index of the item in the character inventory by subtracting 1.
• -2 to -101 to select inventory items from the tool inventory - you can get the index of the item in the character inventory by removing the sign, then subtracting 2.

This fits 126 entries in each inventory, of which we'll only use 100.

Upgrading Building

Building has now been mostly rewritten in C++. It's nicely modularized and much easier to extend and debug. Here are the cliff notes of how it works!

The Core

With a lot of checking back to the building manager, I started by making the Placer's core - its state machine for the control mode, as well as selection for the alignment and placement modes.

Things that work exactly the same way in every mode can be implemented on the Placer itself, so we'll implement the controls to switch between placement and alignment modes here. C switches alignment mode, J switches placement mode. Holding C selects the special "super" alignment mode.

Of course, even though you can select bricks from the Quickbar, you can't actually place a brick yet at all. Or see anything happening when you swap the modes. We're about to get to that. Starting with...

Aligning Bricks with the Mouse

The second most complicated part of building is the code that uses the position of your mouse to determine where the brick you're aiming should go. It seems trivial but it's not. The tool trace hit position must be resolved into a brick placement location, where:

1. The resulting placement must be positioned on the grid that was intersected, or if none the global brick grid (and the placement preview should parent itself to that brick grid, so there's no jittering if that grid is a moving vehicle);
2. The resulting placement must not be positioned in a way that causes it to intersect the surface it was aimed at;
3. The resulting placement must treat hidden or noncollided bricks like regular bricks;
4. The resulting placement must respect the placement alignment grid, meaning that the placement's edges must be aligned to a minimum of 3 faces of one of the alignment grid cells it lies inside (which is why bricks smaller than the alignment grid align themselves to corners);
5. That alignment grid's origin and oriented cell size must first be resolved from considering the orientation of any hit anchors (such as studs or stud inlets) or else the orientation of the surface on the brick that was hit by our raycast - i.e. if you aim at the side of a reoriented brick, or a stud grid, you get a rotated alignment grid;
6. The resulting placement should also orient itself to any anchors (such as studs or stud inlets) unless a specific direction is requested - i.e if you aim at side studs and you haven't manually set your direction, your brick should turn sideways to place on it, and;
7. The specified user rotation, and, if set, direction, should otherwise always be respected.

In other words, firing the correct raycast given the position of the cursor is the easy part.

How do we tackle this?

Let's start by grabbing a bit of information from our hit result. We'll grab:

• The brick grid we hit, or global if we hit the map.
• The EBrickDirection of any anchor (stud or inlet) we hit, or the global up direction (Z+) if we didn't hit any.
• The type of anchor we hit, or none if we didn't hit one.

We can already compute our alignment grid's origin and cell size from this information combined with our current alignment mode. The origin is the position of any anchor we hit (or the brick grid's position if we didn't hit one), and the cell size is our alignment mode's cell size rotated to our up direction.

We can now snap our brick to some kind of grid and rotate it to anchors' orientation.

But of course, as soon as we try to place something other than a 2x2 micro brick, it's obvious that something is still very wrong - even when we align the placement point to the grid, the brick ends up wrongly positioned.

Positioning the brick properly requires understanding that what we are placing is not a point, but a box with a size. Placing it like that means we can use the box extents to de-penetrate it from the surface we hit and the nearest 3 grid cell faces, which gives us way better results:

And because of what we did before, it'll even rotate to face away from studs or towards inlets.

Unfortunately, it's still a bit difficult to work with. To explain why, let me demonstrate with this extremely long, tall ramp.

This isn't very usable for building with unless I'm placing it on the floor of the map. For most other use cases, like placing them corner to corner, I need the origin to be where the stud inlet is. I need a pivot.

So let's upgrade our size to a full pivot - a box with a relative offset and a size that is calculated within the bounds of the brick being placed. We can use the existing code from the old building system, which per-calculates several of these, and we can choose a pivot to use based on what our ray cast hit. We'll add:

• A "Bottom Studs" pivot, which records the location and size of the first found bottom stud grid. We'll choose this one for aligning to top studs.
• A "Top Studs" pivot, which does the same for the first found top stud grid. We'll choose this one for aligning to bottom studs.
• An "Expanded Studs" pivot, which takes the top studs pivot and expands it to the other end of the brick. We'll choose this one if we're aligning to the side of a brick with our rotation or aligning against the map, since it helps us cull parts of the brick from the placement calculation that are irrelevant.
• A "Bounds" pivot, which when used produces behavior identical to what we were doing before we used pivots - an unmoved bounding box that encapsulates the entire brick. We'll only choose this one if we're aligning to the side of a brick with a different rotation to our previewed one, and we can't reorient to match it. We can also use it for other placement calculations, such as the origin of the brick in the next section.

All sorted!

Knowing where the stud grids are also lets us do stuff like this.

And even if we locked the orientation, we can still line things up relative to the brick being placed on.

Placing Floating Bricks

We wanted a floating placement mode that lets you place your brick in front of your face while holding ALT.

We can do that fairly easily - take the origin and direction of the cursor ray and the distance from it of the current preview brick (or a sensible default distance if there is none) and compute a location. Now, continuously move the brick's origin to the grid cell nearest to that location:

We can improve it further by binding the mouse wheel to changing the distance, so you can move the brick closer or further away.

Gizmos and the Preview Grid

You've been seeing a grid in the last few videos. That grid is not the same one from Alpha 5 - it's been re-implemented as something called a gizmo.

A gizmo is a rendered element that provides interactivity and/or feedback when working with 3D scenes. You may have seen these before:

These are common gizmos you'll find in engines like Unity and Unreal, as well as modelling tools like Blender. And soon you'll find them in Brickadia. But more on that in another post.

Unreal's Interactive Tools Framework provides an entire system for displaying arbitrary gizmos at runtime, and previously, Zeblote has done work that allows me to draw things in the engine's Editor compositing layer at runtime too. It only makes sense to make some use of it!

I started by creating a gizmo manager which we'll provide with some materials to draw gizmos with. You can register gizmos with it, and gizmos are allowed both to control actors, and do manual drawing with ITF's gizmo elements. Let's do some quick testing to make sure it can be configured to draw things on top of everything else:

Dragging Brick Rows (Old)

Do you remember when I said that previewing brick placements was the second most complicated part of building? This is the most complicated part. We need to determine, with only a world start location and a camera angle as our inputs, which direction the player wants to drag their brick row - up, down, north, east, south, or west - and how long they want it to be. To recap:

In Alpha 5, we already had an algorithm to do so that worked roughly like the following steps:

1. We convert everything to local space relative to the position the row starts at. From there, imagine lines extending in the direction of the 3 axes. The crosshair can be converted to a ray from the camera origin into the world.

2. Now, we construct 3 axis aligned planes between each pair of axes, then intersect our ray with each of them. This gives us up to 3 intersection points.

3. For each plane, we determine how close the intersection point is to the axes.

4. From these, we select the intersection point that is closest to an axis overall. The nearest axis will then be used to drag along.

5. From there, we simply have to snap the distance along the selected axis to the grid cell size and return the result.

This algorithm produced mostly sensible results in most cases, and worked well enough for the Alpha. However, there are many annoying edge cases that we could never figure out how to solve with this approach, such as:

Dragging Brick Rows (New)

The problem is this existing algorithm is not very good at the transitions between planes. It constantly annoyed us by randomly jumping around as it selected a different plane to be closer and produced unintuitive results. So after I pushed the first building changelist, Zeblote rewrote this function to select the closest axis to your cursor in screen space instead.

1. We start with the same axes and crosshair:

2. We project those world-space lines to screen-space lines. This sounds trivial at first, since Unreal Engine already provides a ProjectWorldToScreen function. All we need to do is pick two points on the line (such as the origin and one unit away) and we'll have screen space points defining our line in 2D.

However, there's a problem with that approach. In some cases, you might want to start dragging a row and then move or turn your camera far away, until the start point of the line is no longer on screen at all. This then breaks the projection.

So we need a more robust way to construct screen space lines. There is a simple solution in theory, we need to find two points on the axis that are actually on screen, but how can we do that reliably?

One way is to clip the line inside the view frustum, so we end up with a line segment that is entirely on screen. In the above image, this would effectively select the point at the bottom left corner and the point at the horizon.

We can then extend the line segment again to make sure it reaches the edges.

3. We select the line that is closest to the cursor in screen space. This effectively divides the screen into up to 6 zones that will select one of the axes, but they're not necessarily the same size.

4. There's an additional filter to reject axes that are very steep when multiple axes are near the crosshair at the same time. This fixes the issue of extending the row into your face when you are looking at the brick from a steep angle.

5. Once we have our chosen point on the screen space line, we need to convert it back to a world space point so we can calculate how far along on the axis it actually is. We could attempt to do some linear algebra here, to figure out what distance along the screen space line equals what distance along the world space axis, but that seems annoying given the perspective view.

So we just use the existing DeprojectScreenToWorld function in the engine to construct a ray from the camera origin going into the scene. By finding the closest point on the world space axis to this ray, we've finally got the point we wanted. What an ordeal!

Also, there's one more edge case to take care of, if we're looking away from the axis (even though it is on screen), that trick won't work, because the ray will diverge from the axis. So we detect that special case and just drag a row to the maximum length along the chosen axis.

Once we picked an axis and world space point, we figure out the row length the same way as before, and we finally have row dragging working again. It's much more robust now, and the edge cases we had above no longer happen.

It's trivial to add in spacing too.

But we're not done yet - Let's take advantage of our gizmo system to display a line on top of everything showing the drag start point and both ends of the row. Near the active end, we'll display a row length in-world.

Resize-Dragging

Resize dragging is a simple extension to row dragging, it mainly involved changes to the very last part of the row dragging math. Instead of resizing the brick in increments of the brick size, as if we were row dragging, we resize in increments of the alignment grid size, skipping increments that don't line up with valid dimensions for the brick type. That means we resize on our grid, like this:

We can still resize in increments of the brick size, if we change the grid size:

One note; we need a special case if the brick's starting size does not entirely fill the grid cells it's in. In this case, for the first increment we want to size it up slightly less, so we only resize up to the grid line:

But what use is being able to resize only in one direction? Let's quickly add the support for switching axis with RMB. The row dragging math only needs a few more branches to filter out axes that we've already locked in.

We can easily allow this in row dragging mode too to create "grids" and "volumes" - 3d grids of the same brick with arbitrary spacing.

Rotation and Reorientation

It's easy to make tapping R rotate our brick clockwise, as before. But remember how we wanted to reorient bricks to the closest direction to the cursor? Well, that's exactly half of how row-dragging and resize-dragging already work.

We'll activate this new behavior if the player holds R for more than 200ms and moves the mouse, then finalize the orientation once they release it. While reorienting, we simply make the brick's up direction point towards where the mouse is.

And of course, we made a gizmo for this too.

Tool Widgets

Our HUD is looking quite bare with the new placer.

The old one modified some text that was manually added to the A5 HUD - but that text has been removed from the EA one, depriving us of some important information the old placer, resizer and other tools were able to report by modifying it.

Actually, doesn't this case happen a lot? There are two other tools I can think of that put information on the screen - the Painter and the Resizer - and yet we manually modify the HUD to add their widgets every time, then just make the tool unhide them. Shouldn't we have a better system? We should, right?

Here's that better system: All tools can now add an arbitrary "large" tool widget to the bottom right corner of the screen, and a "status" tool widget to the area above the quickbar. For the placer, we'll use this to display more measurements onscreen.

Tool Bind Hints

The new system is working nicely, but it needs learnability! We're in need of a means to display our new controls to the user in a way we can dynamically update in real time, because we want to display all the controls the user can use right now - and hide ones that aren't relevant until they are.

First, we needed a nice way to show any input. This CC0 pack by Kenney fit great into our new UI style, and they even fixed a bug we reported quickly. Can definitely recommend these for your project!

We then (manually, ugh) wrote a big table that would translate Unreal Engine FKeys to an icon texture reference from the Kenney pack, and a widget that given an Input Action or Input Axis name, displays the icon for the key bound to that action. Or sometimes multiple icons for chords like Ctrl+C.

Now that we had a way to display keys, we created a system called Tool Bind Hints. All tools are allowed to register them, and they look like this:

How it works is that all tools define a list of bind hints they display in any order they choose. For example, the placer defines this list:

Bind hints have tags, and the game chooses what bind hints to display by determining if they have any tags that are currently shown. For example, here's how the placer uses its tags:

• Previewing is set while the placer is previewing a brick position.
• Placing is set while the placer is dragging a brick row.
• SwitchAxis[123] are used to show the various switch axis prompts (this might be upgraded to a better solution later, bear with me)
• BuildingSpacing is set if you're placing in a placement mode that allows the usage of spacing (so we hide the spacing hint in resize-drag mode)
• FloatBuilding is set if you're using floating building (to show the scroll prompt).
• Reorienting is set if you are reorienting the brick.

And finally, here's a demo of its hint UI updating in real time as you place stuff!

Selection Highlighting

One more thing, we added a system to highlight specific bricks and objects with selection outlines in various colors. For example, the Hammer now shows you which brick is going to be deleted with a red highlight:

Placing new bricks also uses a selection outline around the preview, except it's white. Did you notice it in the videos above?

More to Come!

That's all I have for you today, but there's more coming soon. We'll show the new modes for building physics contraptions. We'll look at the new locking modes, which will bring back the plane locking functionality you can get by holding ctrl, and then some. We'll also be getting into the new orbit mode for building on a controller or Steam Deck, and some new detached mode features.

I look forward to seeing you then. Stay tuned!

Welcome back to another devlog! What do you mean it's been half a year since the last one? Time really flies. Anyway, today I want to show you all the graphics improvements and new features that I added over the past year. Of course these don't all come for free, but they can be quite nice on capable GPUs.

Mobile data warning: This page will load hundreds of MB of media as you scroll!

Overview

Having an index was quite useful on the last post, so let's do it again.
Introduction
Unreal Engine 5.3 and PhysX 5.3
Upgraded Dynamic Environments
Volumetric Clouds
New Environment Settings
Flat Earth Theory Disproven
Improved Screen Space Reflections
Bending Water Reflection Rays
Inexact Proto-Lumen Reflections
Final Result
Order Independent Glass
How Does That Work?
It's Never That Simple
Performance Testing
High Dynamic Range Output
New Upscaling Plugins
DLSS 3 Frame Generation
FSR 2 Upscaling
What about FSR 3?
Improved Level of Detail Transitions
Dithered Level of Detail Transitions
Improved Low Detail Brick Shapes
Combining Both Improvements
What's Next?

Introduction

Since our previous post was already about physics, it only makes sense for this one to focus on graphics again, right? There's a lot to discover in this one, from simple pretty pictures to technical details and views under the hood, debugging graphical problems, and more. I'm not a very experienced graphics programmer, so some of it is also just my personal curiosity to get some of these things to work. I think it will have something interesting for you regardless of whether you're waiting to play the game or working on your own projects :)

PS: This blog is not co-authored by ChatGPT! I actually tried to do that once, and it spewed unusable corporate-sounding garbage.

Unreal Engine 5.3 and PhysX 5.3

Since the last upgrade post, I've migrated the project from Unreal Engine 5.1 to 5.2 and then to 5.3, so now we are fully up to date again. Due to the amount of changes we have to the engine, each of these migrations is a massive task. I have to rebase tens of thousands of changes in hundreds of files to the new branch, fixing several hundred merge conflicts along the way. Somehow Epic likes to change the same files as us.

Those changes include our PhysX integration, now targeting PhysX 5.3 (isn't that number a funny coincidence?), which was originally based on a version of Epic's code in Unreal Engine 4 but somehow strays further from the beaten path with every upgrade. There are also many rendering and shader modifications, bug fixes, networking and performance improvements, ... and that's before we can start fixing all the new bugs we just added.

For example, Proto-Lumen had broken in multiple ways during this upgrade. It was no longer getting any velocity information, which I finally managed to track down to be caused by Epic having allowed async compute on NVIDIA GPUs for the first time in 5.3, causing Lumen to go down a different code path that was previously never used.

In this path, Lumen was not compatible with not having a depth pre-pass, because that'd result in velocity information only being generated after Lumen work had been dispatched. Brickadia does not have a depth pre-pass, because that actually slows down the rendering with lots of meshes and only simple shaders being used. Having to process thousands of draw calls and millions of vertices twice, perhaps unsurprisingly, doesn't make the game faster.

I tried to enable the early velocity pass so this data would be ready in time, but it turns out this does not work without the early depth pass. It produced clearly nonsensical velocity information, such as seeing the movement of the left hand through the body of the character, when it should be obscured.

In hindsight, this should have been the expected result with front to back draw order and no depth buffer, but it still took me quite a while to figure out the cause.

The final fix ended up being to move Lumen dispatch after the normal base pass and velocity were done. There were still more problems with Proto-Lumen, though, it was also flickering so terribly in the dark that I'd consider it unplayable.

Lots of tweaks later, this version of it seems much more stable.

We continue to have silly issues with our PhysX implementation too, seems something has changed with the joint axes in either PhysX or Unreal Engine.

On that note, I've received many requests from other indie developers if they could use our PhysX integration for other, non-competing projects. That sounds reasonable to me, but the changes have been slowly getting mixed up with other commits and fixes. Before we can share it, it would need to be separated out and cleaned up and tested more, and I don't currently know when there will be time.

At the moment, it doesn't even compile outside of the Brickadia project with its very specific set of enabled/disabled plugins and related changes.

Upgraded Dynamic Environments

If you've been following our project or Unreal Engine in general for a while, you might have recognized that the customizable environment on Plate is powered by something called Ultra Dynamic Sky, which builds on the existing lighting and atmosphere simulation features in Unreal Engine. It also provides the weather effects we're using in the game currently. From there, we mostly optimize its performance, improve the look and colors, integrate it with our inspector system to allow you to customize it in multiplayer and create presets, control it with behavior scripts, etc. It's layers of abstraction all the way down!

However, for most of this time, we were using a very old version of it - several years behind by now. So, what if we modernized our maps a bit, and re-created the environments using the new version for Unreal Engine 5?

Volumetric Clouds

The most striking difference you'll notice are the clouds. Now that we're at Unreal Engine 5.3, Epic has slowly improved the performance of their new volumetric cloud system so much that we can actually consider using it in game. Just look at how pretty the clouds are!

Woops, wrong image. Let's try that again:

But wait, there's more. Volumetric clouds are actually located at a fixed height in the world, so you can fly towards them, and then above...

Yes, you can fly vehicles above the clouds, and build things there too.

Now, when I said earlier that they perform well, that doesn't mean the fancy clouds are free. Enabling them, as nice as it looks, will slow down your game a bit. So I've hooked up a graphics setting to turn them back off and essentially revert back to the 2D clouds you've seen in Alpha 5, ensuring we don't degrade performance on low end hardware as we get closer to the release.

New Environment Settings

Much of the environment menu has been revamped to expose new features. For example, you can now control the day/night cycle more sensibly.

You have much more control over the night sky now with extra moon settings.

Weather effects can now be individually controlled, and there's a new one, too.

Here are some pictures of environments our testers created!

Flat Earth Theory Disproven

We've finally managed to send a satellite with a camera into outer space, and discovered the ground is in fact not flat.

This change had to be made because the sky relies on atmosphere simulation, and atmospheres only exist for round planets. So we curved the entire map. Don't worry, it's imperceptible at ground level, because the playable area is contained in the little white cube. You can see the difference clearly above the clouds:

Improved Screen Space Reflections

We can currently only use screen space reflections in the game, as our bricks are not yet represented in the off-screen scene data used for Lumen reflections. In most cases, like if you don't look straight at a mirror, this looks good enough to be acceptable. There are a few really bad outliers though, especially with large bodies of reflective water.

For example, the reflection of the environment on this lake really doesn't look great. It's cut off at the edges of the screen, which looks extremely distracting as you're moving the camera around, because it's always reflecting the sky at full brightness in those corners. Note that I replaced the lake with a perfectly smooth metal surface to make the reflection more easily visible.

And if we enable the Proto-Lumen reflections, we get sharper reflections with even more sky incorrectly visible in them. This is especially visible under the trees. It's because Lumen would normally trace the off-screen scene data there, but we don't have that, and won't at release.

So I decided to fix, or at least, bodge this until we can eventually use "proper" Lumen. Let's attack the white edges on the left and right side first. What is actually the problem there?

Bending Water Reflection Rays

To understand the problem at the screen edges, we have to be aware of how screen space reflections work at least on a high level. It's actually a fairly simple concept. The engine first renders the game world without reflections, then for each pixel where a reflective surface (like a lake) is visible, it calculates where the reflection would be located, and tries to retrieve the color at that location from the rendered image.

So according to that simple drawing we should be able to see buildings on screen reflected in the water. But then, what's the issue at the screen edges?

Part of it is actually an intentional fade towards the edges in the shader, to hide artifacts. Let's start by turning that off so we can see what's really going on.

Now we can see the issue more clearly. There's a straight cut where the reflection reaches the edge of what is visible on screen above. The further we look down, the worse it gets, due to the way perspective works.

Meanwhile, if we look straight ahead or up, it actually looks fine at the edges, as the reflected area is now smaller than the area we have rendered on screen.

My initial try to fix this was to take the reflections we have, and extrude the outer edges to the edge of the screen. So it'd just continue whatever color there is to the actual edge.

I implemented this by clipping the screen space search at the edges of the screen, rather than shortening the ray to remain within the screen. It even looked somewhat reasonable in a still image!

There's a problem though. It looks absolutely terrible in motion! Due to the extrusion effect, large swathes of pixels are changing their color together as we turn the camera, so this isn't any less distracting than the sky-colored borders.

So this idea was a complete failure. Let's try that again, but this time armed with more understanding of what's happening behind the scenes. To really visualize the issue with the reflection rays going outside the screen, we need to take our sketch from above and upgrade it to be 3-dimensional.

I don't really have a good software to visualize this kind of stuff, so I used a bunch of translucent shapes in Unreal Engine. As long as it gets the idea across, the method doesn't matter, right? Ignore that there's a sky in the background, it's not relevant to our visualization.

The grey plane at the bottom represents the lake. The light grey shape that gets larger in the distance represents your camera. This is actually a fairly reasonable approximation of a view frustum for a camera with 16:9 aspect ratio and a 55° vertical field of view. The rod inside represents a ray from the eye towards the lake, which is then getting reflected off it. We are trying to determine the reflection for a pixel in the bottom right of the screen.

You can see how as long as the camera is aiming straight horizontal, the ray will remain within the view frustum, i.e. it will intersect with the large back wall (shown by its shadow, or the image below, where I flew inside the thing).

That all looks reasonable so far. But what if we rotate the camera down a little?

Uh oh! With the camera pointing down, our reflection ray is leaving the view frustum to the side. This is exactly what is happening with the diagonal edge in the screenshots above.

This happens because with the camera pointing down, the right side of our view frustum actually ends up at an angle, when compared to the Z axis going straight up. So even though we are still reflecting straight up off the flat water, it is leaving our view to the side.

Hopefully this 3d visualization helped in some way. But now that we understand where our reflection ray is going, what do we do with this information?

Essentially, what we want to accomplish is to make sure the reflected rays stay within the view frustum. To do this, we have to switch to a different coordinate space.

Imagine a cube. It has an extent of one unit on each axis, and is centered at the origin. If you draw a top view of this cube, with the coordinate system overlaid, it looks somewhat like the below image. You could consider this something like cube-space, and a set of coordinates between -1 and 1 on each axis would let you position something anywhere relative to the cube.

We can do the same thing for the view frustum of our camera above, except we stretch it, like the below image. You can now use coordinates between -1 and 1 to position something anywhere within the view frustum.

In graphics programming, this is normally called "clip space", because objects outside of the unit cube will be clipped by the edges of the screen. The part we care about though, is that parallel lines starting inside the view and going "forward" in this coordinate space will remain within the view. We can visualize our reflection ray going off screen (red) in this coordinate space.

All we have to do to ensure we get a valid reflection point, is align it to face straight forward in clip space. This is as easy as ensuring the x component of its direction is equal to 0.

Let's try to implement this in the shader and see how it looks!

Let's try that one more time, shall we?

Well, we have indeed fixed the edges. But... this is not the way either, is it? Now everything is horribly distorted as we move the camera around! Argh...

One last try before we give up, what if we kept this effect but only applied it towards the edges, fading it out towards the center where most of the attention goes?

It seems like this works pretty well! It isn't perfect by any means (it cannot be, without off-screen scene information), and the distortion is still visible, but I think it's much better than the glowing white border we started with. Especially if used for something like an underground cave filled with water.

Inexact Proto-Lumen Reflections

With the screen edges solved, we still have the problem that once we turn on Proto-Lumen, most of the reflections disappear. This is because Lumen only uses screen space reflections for cases where it is certain the reflection is correct, i.e. the screen space ray does not get occluded by anything. In all other cases it tries to fall back to tracing the distance field scene instead (which we don't have!).

Luckily the fix for this is rather simple. Just... don't do that. It's going to produce a bunch of nonsense in some cases, but that's fine, the old screen space reflection effect did that too.

Final Result

Here is what this lake looks like now, if we swap the metal plate back for the glass surface that was there previously, and look at it with Proto-Lumen enabled. This improvement has no additional performance cost.

Order Independent Glass

Another very jarring visual oddity in the game is the bad translucency sorting we get from the way we batch render bricks, which prevents any sorting of the inner surfaces relative to each other. So if you look at, for example, a large translucent preview of a prefab you're going to place, it will often look like nonsense.

Some examples:

What if there was a simple way to fix it? Compare to the following images!

How Does That Work?

Unreal Engine implements a technique called Multi Layer Alpha Blending (MLAB). There is a nice blog post here that goes into more detail on how such a thing could be implemented when you're not dealing with the massive engine shaders. The implementation in Unreal Engine is more efficient though, we'll get to that later on.

At a high level view, what the engine does is use a large buffer to store up to N translucent surface layers for each pixel, sorted by their depth. Every time a new layer is rendered to that pixel, we insert it into this buffer at the correct index, potentially merging the last layers if the buffer is full. Then after all objects were rendered, we flatten the layers to a single color.

To compare, let's first look how Unreal Engine traditionally rendered translucent objects in the world. We will take a look at the following scene.

Before rendering any translucency, the opaque scene is drawn and lit.

Then we start drawing the translucent objects on top of the scene with forward shading. The engine tries to sort objects by their distance from the camera here, so nearest objects are drawn last. This doesn't work as intended for our bricks, because we can't draw tens of thousands of translucent bricks as individual objects. Instead they'll be rendered in large clusters, which means most of them remain unsorted.

With the translucent faces drawing arbitrarily over each other inside each cluster, performance is very good, but the result is very bad looking with wrongly sorted surfaces.

In many other cases sorting objects by distance will not work either, for example, consider the classic case below. There is no known real time solution to this problem, other than to use an OIT technique.

Let's take a look how Unreal Engine solves this. As mentioned they are using MLAB, but the implementation is quite unusual. There is a raster order view of the same size as the normal screen buffers, which contains a single sample count value for each pixel. Then, separate buffers are used to store the color, depth and transmittance of the individual layers, with N values for each pixel. Usually, N is 4 for a good balance between quality and performance.

You might be wondering what a raster order view does. Usually the GPU handles many thousands of fragments concurrently, only merging them at the end. However, with OIT, our shader needs to write samples to the correct position for the current layer count, and potentially merge others! So we really don't want it to run multiple instances affecting the same pixel concurrently, because that corrupts our buffers and looks like this:

The raster order view solves this, by serializing operations for each pixel. So different pixels can still run in parallel, but we're no longer messing up the values in our buffers by running multiple fragments affecting the same pixel at once.

Let's follow rendering the scene from above again, but this time with OIT!

Up to the opaque scene being rendered, everything works the same as before. However, translucent objects now render to the OIT buffers rather than directly onto the scene color. Since the OIT buffers are so large, I changed the main resolution of the window to 960x560, but here is what these look like once we're done rendering translucent objects:

At this point I found out that these buffers are encoded in r11g11b10 format, which is rather annoying, because the engine only binds them as r32 buffers, so they don't display correctly in any visualization tool. Long story short, we can use a custom visualization shader in RenderDoc that decodes the texture, and since I found no useful minimal examples of this being done anywhere on the internet, here is the code that displays the texture in the correct format:

// This is the standard r11g11b10 unpacking function
float3 UnpackR11G11B10F(uint rgb)
{
	float r = f16tof32((rgb >> 17) & 0x7FF0);
	float g = f16tof32((rgb >> 6) & 0x7FF0);
	float b = f16tof32((rgb << 5) & 0x7FE0);
	return float3(r, g, b);
}

// This is how you access the selected texture in RenderDoc
// For some inexplicable reason it is always an array
uint4 RD_TexDim();
Texture2DArray<uint> texArray : register(RD_UINT_2D_ARRAY_BINDING);

float4 main(float4 pos : SV_Position, float4 UV : TEXCOORD0) : SV_Target0
{
	uint4 res = RD_TexDim();
	uint packed = texArray.Load(int4(UV.xy * res.xy, 0, 0)).r;

	return float4(UnpackR11G11B10F(packed), 1.f);
}

Now we can continue looking at our buffers.

The interleaved layers are easier to see, if we zoom in to the image. Here each group of 2x2 values represents data for one pixel of the final image.

Once we have collected all this data, a combine pass will flatten these layers onto the scene color, and we can resume the same rendering path as without OIT.

This scene was a bit messy, so here is another example with a much simpler one. We're rendering three tinted glass panes in a row.

Due to the separate buffers, this implementation is highly efficient for cases where not much translucency is actually on screen, so basically most real scenes. On most pixels we'll just read that the sample count is 0 during the combine pass, and skip them entirely. It requires little memory bandwidth to run too, as only the minimal amount of data actually needed is being written to the buffers. But this doesn't mean it's free. We'll evaluate the performance later.

It's Never That Simple

The excitement of seeing translucent previews finally rendering in a sensible way did not last long at first. This is because when I turned my camera and breathed incorrectly, my whole computer would crash. Giving this build to a few testers to try on their machine, they could reproduce it, and crash their computers too.

Eventually we discovered that what happened is the GPU froze and timed out, also called a TDR, and the computer actually recovers after about a minute if you continue staring at a black screen for what feels like forever. Why it takes a minute to recover, when the timeout triggers after two seconds, remains a complete mystery. This was the first time I ever had Unreal Engine fail in this way, so I didn't really know how to go about debugging it. Also, the freeze only occurs in a shipping build, isn't that amazing?

Let's check if the game wrote something to its log file first.

[2023.11.04-21.36.38:515][110]LogD3D12RHI: Warning: GPU timeout: A payload (0x0000015E5AC55F00) on the [0x00000151B6270B00, 3D] queue has not completed after 5.000000 seconds.
[2023.11.04-21.37.34:005][110]LogD3D12RHI: Error: CurrentQueue.Fence.D3DFence->GetCompletedValue() failed 
 at .\Runtime/D3D12RHI/Private/D3D12Submission.cpp:980 
 with error DXGI_ERROR_DEVICE_REMOVED with Reason: DXGI_ERROR_DEVICE_HUNG

[2023.11.04-21.37.34:005][110]LogD3D12RHI: Error: [GPUBreadCrumb] Last tracked GPU operations:
[2023.11.04-21.37.34:005][110]LogD3D12RHI: Error: [GPUBreadCrumb]	3D Queue 0

[2023.11.04-21.37.34:010][110]LogD3D12RHI: Error: [GPUBreadCrumb]	Copy Queue 0

[2023.11.04-21.37.34:021][110]LogD3D12RHI: Error: [GPUBreadCrumb]	Compute Queue 0

[2023.11.04-21.37.34:032][110]LogD3D12RHI: Error: DRED: Last tracked GPU operations:
[2023.11.04-21.37.34:032][110]LogD3D12RHI: Error: DRED: No command list found with active outstanding operations (all finished or not started yet).
[2023.11.04-21.37.34:032][110]LogD3D12RHI: Error: DRED: No PageFault data.
[2023.11.04-21.37.34:032][110]LogD3D12RHI: Error: Memory Info from frame ID -1:
[2023.11.04-21.37.34:032][110]LogD3D12RHI: Error: 	Budget:	   0.00 MB
[2023.11.04-21.37.34:032][110]LogD3D12RHI: Error: 	Used:	   0.00 MB
[2023.11.04-21.37.34:044][110]LogD3D12RHI: Error: GPU Crashed or D3D Device Removed.

Use -d3ddebug to enable the D3D debug device.
Use -gpucrashdebugging to track current GPU state.

It did, but the output is not useful, it's basically just telling us "yes it crashed". We can try to add those two command line arguments it suggests, but neither of them are useful: -d3ddebug does nothing, and -gpucrashdebugging makes the game run slower without triggering the freeze at all.

After looking around more, I discovered Unreal Engine also integrates something called NVIDIA Aftermath which should give us more information. However, the documentation just tells us the same flag again, which hides the freeze!

Digging through the code, I found that you can enable Aftermath by itself with the following arguments: "-nvaftermath -aftermathall". This way it's not enabling the other systems that hide the freeze at the same time.

We get a little more information this time!

[2023.11.04-22.51.53:639][270]LogD3D12RHI: Warning: GPU timeout: A payload (0x00000220144D6200) on the [0x00000213EE430B00, 3D] queue has not completed after 5.000000 seconds.
[2023.11.04-22.52.48:744][270]LogD3D12RHI: Error: CurrentQueue.Fence.D3DFence->GetCompletedValue() failed 
 at .\Runtime/D3D12RHI/Private/D3D12Submission.cpp:980 
 with error DXGI_ERROR_DEVICE_REMOVED with Reason: DXGI_ERROR_DEVICE_HUNG

[2023.11.04-22.52.48:744][270]LogRHI: Error: [Aftermath] Status: Timeout
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Scanning 22 command lists for dumps
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 0, command list 00000213ED87E4F0, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 1, command list 00000213F88B0A00, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 2, command list 0000021388881020, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 3, command list 00000213A921ADE0, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 4, command list 00000213A920F0B0, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 5, command list 00000213AFD34050, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 6, command list 00000213A920C690, status Executing, 3 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] 0: Scene
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] 1: Translucency
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] 2: Translucency(%s Parallel) %dx%d
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 7, command list 00000213A9209C70, status Finished, 1 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] 0: EnqueueCopy(%s)
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 8, command list 00000213B393E490, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 9, command list 00000213A92105C0, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 10, command list 00000213A920B180, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 11, command list 00000213AB9A7B40, status Finished, 2 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] 0: Scene
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] 1: FGPUSortManager::OnPostRenderOpaque
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 12, command list 00000213AB9A9050, status Finished, 2 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] 0: Scene
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] 1: ClearRenderTarget(%s, slice %d, mip %d) %dx%d ClearAction
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 13, command list 0000000000000000, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 14, command list 0000000000000000, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 15, command list 0000000000000000, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 16, command list 0000000000000000, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 17, command list 0000000000000000, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 18, command list 0000000000000000, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 19, command list 00000213AF9F79F0, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 20, command list 00000213AF9F3AC0, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] Context 21, command list 0000000000000000, status Finished, 0 markers. Begin GPU Stack Dump
[2023.11.04-22.52.48:746][270]LogRHI: Error: [Aftermath] End GPU Stack Dump

This is again not actually helpful though. The most we can tell from this output is that the issue occurs during "Translucency", which is about what we'd expect to happen given the freeze only occurs when OIT is enabled, but it tells us nothing about the underlying cause. So we'll need another approach.

Searching the internet for how to debug a TDR, one thing I found was this page explaining that you can analyze a TDR with PIX. Except that to analyze it, it has to take a single-frame capture on exactly the frame that causes the freeze. With it seemingly freezing randomly during camera movement, how are we meant to know in advance which frame will freeze to capture it? This feature seems a bit useless to me, though maybe there are some situations where you can accurately reproduce the issue like that. It's certainly not going to help us.

Then I discovered that NVIDIA Aftermath is not just the library the engine uses, there are also standalone tools for interacting with it. After setting up the crash monitor on my computer, it did indeed capture the TDR in Nsight.

But we don't have any shader symbols, so it's useless in its current state.

We can follow the instructions on their documentation and hook up the separate shader debugging information that Unreal Engine optionally generates during packaging to get this working.

Now we can tell that the GPU is freezing inside the AddOITSample method in the translucent base pass shader! I didn't have access to Nsight Graphics Pro while I was investigating this last month, and this is as far as the no-NDA edition will get us. But we can still manually review this function and the surrounding code and see if any issues pop out.

There's definitely a questionable control flow here:

void AddOITSample_MLAB(uint2 InPixelCoord, float3 InColor, float3 InTrans, float InDepth)
{
    // ROV read to for pixel synchronization
    uint SampleCount = min(TranslucentBasePass.OIT.OutOITSampleCount[InPixelCoord], TranslucentBasePass.OIT.MaxSamplePerPixel);

    [...]

    if (SampleCount > 0)
    {
        const uint2 LastSampleCoord = GetStoringCoord(SampleBaseCoord, SampleCount-1);
        const FOITSample LastSample = OITLoadSample(LastSampleCoord);
        if (Current.Depth > LastSample.Depth) // Scene depth (not inv-Z)
        {
            if (all(LastSample.Trans < TranslucentBasePass.OIT.TransmittanceThreshold))
            {
                discard;
            }
        }
    }

    [...]

    // Write to ROV to unlock pixel
    SampleCount = min(SampleCount + 1, TranslucentBasePass.OIT.MaxSamplePerPixel);
    TranslucentBasePass.OIT.OutOITSampleCount[InPixelCoord] = SampleCount;
}

The shader starts by acquiring a lock on the raster order view, doing a bunch of logic, potentially discarding the current pixel if it is deemed irrelevant, at the end releasing the lock by writing back to the raster order view.

What exactly happens to our unlock write to the raster order view, if we have discarded the pixel above, which prevents the writes from actually happening? I honestly don't know the answer, but I made a little experiment here: let's just add return after discard, to force the compiler to generate explicit unlock instructions and exit the function right there.

    if (SampleCount > 0)
    {
        const uint2 LastSampleCoord = GetStoringCoord(SampleBaseCoord, SampleCount-1);
        const FOITSample LastSample = OITLoadSample(LastSampleCoord);
        if (Current.Depth > LastSample.Depth) // Scene depth (not inv-Z)
        {
            if (all(LastSample.Trans < TranslucentBasePass.OIT.TransmittanceThreshold))
            {
                discard;
                return;
            }
        }
    }

Surprisingly, this really did fix the issue. My GPU is no longer randomly freezing during translucency rendering, and neither are any of the others.

Another fix to be made here is that Epic had declared TransmittanceThreshold as the wrong type, it needs to be a float, not an integer. This had likely made the issue worse as the comparison was now invalid, causing more pixels to hit the discard case than intended.

But if this was the issue, why did the freeze only occur in the shipping build with GPU crash debugging disabled? Are we dealing with an optimization bug in the shader compiler or driver?

We could potentially figure this out with Nsight Graphics Pro now, but here is where I gave up on investigating further. It is somewhat unsatisfying to not have a complete low level explanation of what the GPU was hanging on or why it has been fixed by this change, but we can't lose ourselves in this one issue.

So are we done? I thought we were, until another tester reported the game not launching at all on his computer with an RX 580 GPU.

Running with -d3ddebug should tell us what caused the shader compilation error. Except that when he ran it on his computer, it would just show this message:

Fatal error: [File:.\Runtime/D3D12RHI/Private/D3D12Adapter.cpp] [Line: 418] The debug interface requires the D3D12 SDK Layers. Please install the Graphics Tools for Windows. See: https://docs.microsoft.com/en-us/windows/uwp/gaming/use-the-directx-runtime-and-visual-studio-graphics-diagnostic-features

Too bad that was already installed... now what? The log reveals another problem:

D3D Error 887e0003: (12600@88679078) at 00007FF9AEFFC9F0 - D3D12 SDKLayers dll not found at D3D12SDKPath. 	

So it seems the dll needed to run -d3ddebug was excluded from shipping builds by default, breaking the feature completely. Easy fix, just always include it.

            RuntimeDependencies.Add(
                "$(TargetOutputDir)/D3D12/D3D12Core.dll",
                DirectX.GetDllDir(Target) + "D3D12Core.dll");

            //if (Target.Configuration != UnrealTargetConfiguration.Shipping &&
            //    Target.Configuration != UnrealTargetConfiguration.Test)
            {
                RuntimeDependencies.Add(
                    "$(TargetOutputDir)/D3D12/d3d12SDKLayers.dll",
                    DirectX.GetDllDir(Target) + "d3d12SDKLayers.dll");
            }

Finally we get a message telling us the actual issue. Who would have thought there could be a DirectX12 capable GPU without support for raster order views?

D12 ERROR: ID3D12Device::CreatePixelShader: Shader uses Rasterizer Ordered Views, but the device does not support this. To check for support, check device caps via the CheckFeatureSupport() API [ STATE_CREATION ERROR #93: CREATEPIXELSHADER_INVALIDSHADERBYTECODE]

Epic didn't, apparently.

AdditionalDefines.SetDefine(TEXT("PLATFORM_SUPPORTS_ROV"), 1); // Assume min. spec HW supports with DX12/SM5

The problem this time was that having OIT enabled in the project would always bind a raster order view in the translucency shaders, even if not actually used. This then causes the game to crash, as those shaders fail to compile on GPUs that don't support raster order views, even if they are never used. Fixing this took more effort, but the gist is basically:

• Add a GRHISupportsRasterOrderViews flag next to all the other runtime feature flags that is populated from D3D12_FEATURE_DATA_D3D12_OPTIONS::ROVsSupported.
• Add a new r.OIT.SortedPixels.Enabled cvar that can be used to fully enable/disable OIT at runtime, to be controlled by graphics settings.
• Add a permutation domain to TBasePassPS with a PERMUTATION_SUPPORTS_OIT flag that is combined into OIT_ENABLED in BasePassPixelShader.usf. The extra permutation is only compiled for translucent materials and only if OIT is enabled for the project.
• Extend FBasePassMeshProcessor slightly to use the correct shader permutation depending on if we are drawing a translucent base pass that requests OIT.

Finally we can have optional OIT in our project, that can be toggled on and off from graphics settings. What an adventure!

PS: I sent my changes to Epic on UDN and they have integrated them into 5.4, so you should no longer hit these issues if you want to use OIT in your own projects.

• Random TDRs with OIT enabled fix commit
• Optional ROVs/runtime OIT toggle/sorting order fix commit

Performance Testing

I'm using a PC with a GTX 1650 in this test, the smallest non-integrated GPU I have available currently from almost 5 years ago, running the game in 1080p with no upscaling. All the screenshots below have frame rate counters enabled.

We'll look at scenes with different amounts of translucent geometry visible on screen, from very little to filling the entire screen, and compare the performance with OIT on/off for each. I also chose not to enable the volumetric clouds here.

So this effect is still usable even on low end hardware, staying in playable framerates, as long as you don't go crazy filling the whole screen with it.

Is it worth it to enable? Maybe. Depends how much the wrong translucency sorting is annoying you while building, what hardware you currently use, and how much you can tolerate reducing your frame rate to fix it. I like to think that we are creating things for the future, not the past - the number of people who can run the effect will only increase over time.

On higher end systems, it's usually a non-issue, and I always keep it enabled myself. For example, here is a similar scene running on a RTX 4090:

High Dynamic Range Output

This is a pretty simple one, considering it's already integrated in Unreal Engine and you just have to turn it on. Except you can't use the existing function in the engine, of course, that would be too easy. For example, you might be looking at EnableHDRDisplayOutput and think it will do the trick, until you actually look at the code and notice that it changes the fullscreen setting for no reason.

Attempting to enable HDR also exposed a lot of issues with our environment setup. When I first tried it, the image was way too dark, and basically unusable on anything other than a TV with Dynamic Tone Mapping enabled to bring it back into a sensible range. Turns out our scenes did not have nearly enough light, which had been compensated for by the SDR tonemapper in previous versions.

After fixing all those issues though, it looks absolutely fantastic. Seeing the game on the big LG OLED G3, with HDR enabled and all the settings maxed, is almost unbelievable - the sky during the day and emissive bricks at night especially.

I never want to play without it again! We've got a problem here though - I can't actually show it to you, unless you also have a good HDR display, enabled HDR for your desktop, and are using the latest version of Chrome. I have the game set to 1500 nits peak brightness, but that does not mean every scene will use it.

These images were captured in 4k HDR using Xbox Game Bar on Windows 11, which writes a JPEG-XR file, and then converted to AVIF using this tool I found, so they can display in the browser. On my computer, the version in the browser looks exactly the same as the game, but I have no idea if that works for you too.

Some troubleshooting if the images don't display correctly:

• If you don't have a HDR monitor, you can't view them.
• If you have HDR disabled in Windows, enable it.
• If you are using Edge or Firefox or something else, use Chrome.
• If you are using Chrome but the images are too dark, change the HDR brightness balance setting in Windows, or change the dynamic tone mapping setting on your display's menu.
• If you are not using Windows, I can't help you.

New Upscaling Plugins

I try to keep up to date on all the commonly used upscaling plugins, especially those that I use myself and know work very well. Here are some that were released over the past year, that will be available in Early Access:

DLSS 3 Frame Generation

Since NVIDIA released a plugin for DLSS 3 Frame Generation earlier this year, I have obviously already added this to the game.

This is some truly magic tech - by generating new frames inbetween the ones the game actually renders, your frame rate can be almost doubled in many cases. It works very well for taking a game running at 60 fps to around 100-120 fps.

Unlike most graphics quality settings, this applies regardless if the bottleneck is your GPU or your CPU. So for example, you can use it to run some crazy physics contraptions! Do note though, that this requires at least a 40 series GPU. I have the RTX 4090 here, so let's try loading something completely absurd.

We'll start with this classic map built from about 2.3 million bricks as a backdrop.

Then we'll load in a space ship built from roughly 2500 bricks, with multiple materials like glass in use and even some components attached.

Wait, obviously I meant 2000 space ships. Otherwise what is even the point?!

Our frame rate seems to have taken a bit of a hit. Let's enable DLSS 3 to fix it.

And there you have it! Some of the optimizations I have already planned for after launch will likely speed this up significantly without having to use DLSS 3, but for now this works very very well (if you can run it).

FSR 2 Upscaling

There are some goodies for people on AMD GPUs too! FSR 2 is AMD's counter to the DLSS 2 that we had during the Open Alpha, and has been released as a plugin some time ago. This replaces the temporal upscaling pass in Unreal Engine with a new, better one that works on more GPUs, and also works on the native Linux build. I don't consider the visual quality as good as DLSS, but it can definitely be a viable alternative to TSR with comparable performance.

Comparing these on a high end system doesn't really lead to meaningful differences in performance, they're all pretty good.

However, things change drastically when comparing them on the low end PC, combined with the usual graphics settings to keep our frame rate up.

With DLSS 2 and TSR-Ultra not usable on the GTX 1650, the fight is between the FSR 2 and TSR-Low, and FSR 2 definitely feels less blurry to me.

Unfortunately I can't show it to you in motion, as that would need lossless video for a fair comparison. This is very subjective, so your impressions might be different from mine. If in doubt, just try all the upscalers yourself.

What about FSR 3?

Now you might be thinking: Hang on, if I'm adding DLSS 3 Frame Generation, and FSR 2 upscaling, why not FSR 3 Frame Generation? It was just released also!

However, as far as I can tell in my experiments, this is just... not working?

To give it a fair test, I've used possibly some of the best gaming displays available: an LG UltraGear 38GN950-B and an LG OLED G3, set to 144Hz and 120Hz respectively, both G-Sync Compatible.

I've tried every possible combination of sync settings: G-Sync enabled on the display, or not, V-Sync enabled, or not, and combined these with the source frame rate ranging between 50 and 90. Can you imagine there wasn't a single case where it provided a good experience? In every single test, enabling it would introduce pacing issues that appear as slight to very visible stuttering.

V-Sync appears to be entirely unusable, despite the documentation saying that it works better using V-Sync. It was stuttering so much, I even tried to capture the screen at 144Hz to see what is going on. Stepping through that capture frame by frame revealed many frames that were just duplicates of the previous one, despite the game being capable of running much faster than that. Meanwhile, capturing the game running at 144Hz without FSR 3 enabled is perfectly smooth.

G-Sync is able to hide the terrible pacing somewhat due to its highly variable refresh rate, but it still doesn't feel smooth. For example, the game running at 65 fps with G-Sync actually felt better to play than the result of FSR 3 doubling that to 130 fps. The improved motion smoothness I can clearly notice from DLSS 3 is nowhere to be found.

So what's the problem? I have no idea. Maybe the plugin is broken. Maybe it's just incompatible with some other configuration. Maybe I just did it wrong somehow. But there's nothing I could compare it to and find out. If AMD wants to post a sample project that has it actually working nice and smoothly, like there is for DLSS, we can revisit this.

Improved Level of Detail Transitions

One graphical oddity I've seen a lot of people complain about (and complained about a lot myself) is how the low detail meshes we use for bricks absolutely destroy special bricks like trees at a distance. They'll have this really ugly and distracting popping effect if you fly over a large build.

But why does that happen? There are three main reasons:

• We group bricks into clusters for rendering, which means many bricks switch the level of detail together as a group, making it more noticeable on screen as a larger area is affected in a single frame.
• The low detail version of special bricks is auto generated and absurdly bad. It's just a bounding box around the brick, often too large.
• There isn't any kind of transition, it just snaps from showing one version in one frame to another version in the next frame.

Now, we're not going to make any more major changes to the brick rendering system before release at this point. So we can't do anything about the first point. Bricks will continue to be rendered as clusters in the near future, at least until we get to a full Nanite integration some time during Early Access (maybe?).

But we can do something about the latter two.

Dithered Level of Detail Transitions

Unreal Engine supports transitioning between distinct levels of detail with a fade effect that lasts several frames. This works by temporarily rendering both versions, blending between them with a dither pattern.

It's quite badly documented, but here's how to use it for custom meshes:

• Enable the Dithered LOD Transition setting in all of the materials.
• Enable the bDitheredLODTransition flag on all your mesh batches.
• Make sure you have MaxScreenSize and MinScreenSize configured.
• Create separate static mesh batches for each level of detail.

Now if you went and done all of that, the result will be this unusable thing that is always flashing for one frame before the transition starts, because of course the feature is actually broken in 5.3. Watch closely and then you can't unsee it.

(These videos were taken from a newer version of the game, so the lighting is quite different. That's not relevant to this comparison, try to ignore it.)

After some investigation, it turns out someone had refactored a bunch of the code and accidentally taken it out of order - it was binding the dithered LoD state uniform buffer before regenerating it for the current frame, so it ended up combining the set of LoD models for the current frame with the fade progression of the previous frame (where the previous transition had already completed), resulting in a flash of nonsense for exactly one frame.

When I say "some" investigation, I actually mean it took all day to track this down, mostly because I was not familiar with how any of the code involved works.

Now we have smoother transitions, but it still doesn't really look good.

Improved Low Detail Brick Shapes

Take a look at some special bricks up close, and what they look like when rendered as low detail. You'll hopefully agree that this is quite suboptimal.

In a previous post I wrote a bit about generating convex hulls around collections of bricks. In hindsight, doesn't it seem quite obvious to use the same approach for generating more "snug" low detail versions of these bricks? Let's try that.

Much better! The new low detail shapes are less comically oversized, and also have face normals in directions more similar to the high detail version so the difference in lighting will be smaller. As a result, the transition will be less visible. We still want to use as few faces as possible, so for bricks below a certain volume like that jar on the right, those will remain a simple box.

Combining Both Improvements

Here is what the fly over looks like now, with both improvements combined. I think it's quite satisfying, virtually all of the popping has disappeared.

Let's do that again from a different angle.

What's Next?

I haven't been around much in the community this year, but our social media managers tell me these are your three most important questions:

• What happened to the networked physics?
• Why don't we write blog posts more often?
• When will you be able to you buy the game?

To be completely honest with you, progress has been slow. We still have little time to work on the game after our jobs. But we're still going, so there's no need to worry. I'm continuing my networked physics implementation right after I finish writing this post, and there will be another post on that as soon as it is ready to demo. Perhaps a Physics Trailer 2 too? There's been lots of hidden progress on Behaviors scripting, and Six is now working on revamping the building controls to work better for vehicles. You definitely won't have to wait another 6 months for updates this time, but some of these things have to cook for a while longer still.

Partly due to the things we have posted on here before, I have been hesitant to post something on this blog, unless I feel like we have collected enough stuff to make each individual post impress people somehow. It also takes quite a while to create these large posts, I just spent several days writing this one and getting media for it, which is all time not spent on actually adding more features to the game. But that means we sometimes go half a year without posting updates at all, so I can understand how that probably isn't what you'd like us to do...

Originally this blog was intended to just be posted regularly, every few weeks or so, with whatever curious things we did during that time and little polish. We'll try to get back to that for future posts.

As for the release date, I still can't tell you. We'd previously said "when it's done", and that is still the case. My best guess for when it might be done is now mid 2024. There are interesting events during that time, so it would align really well.

We will let you know once we are aiming for a specific date again, stay tuned.