Welcome to this week's special edition blurb!

Who would've thought this would all be built so quickly?:

Credit: Brickadia Community

Well-built Roman-inspired building:

Credit: Stormer

"Honey look, I think I can see A6 from here!":

Credit: Flookh

Hope you got your ticket to see this build:

Credit: Bluester16

Castle gates with some towers, not even done but it already looks so good:

Credit: UngaBunga

shrek shack #1:

Credit: Moose

Overgrowth, mossy, and ruined: awesome aspects for any build:

Credit: Syringe

shrek shack #2:

Credit: BlueBip

Very epic shack:

Credit: dhagrow

You're telling me a robot lives in this house?:

Credit: TombstoneTechnician

Someone build an apartment where people can build their own rooms in!:

Credit: Domless

Sick river facility:

Credit: KevinTR

Obama? You build in this server too!?:

Credit: Obama

He really do be building here:

Credit: Obama

Recently, a user of the community sent me their first ever builds on Brickadia, pretty awesome stuff!:

Credit: TrapAZayd

Back of yo leg, fool:

Credit: Cryptic Runner

While we have seen clips and images of physics objects and vehicles in the past, the general issue with collision in those videos was that physics objects were dealt dirty with a regular collision box rather than a sort of in-depth collision. As a result, you get this:

Credit: Zeblote

In other words, a Garry's Mod moment. Also, for some reason, ragdolls didn't collide with those physics objects? Just a tid-bit, but let's keep moving. Over the course of the development blog, the developers go over a series of possible solutions for having concave collision detection, which is basically the kind of collision for physics objects we all want aka you being able to sit in a seat even though the car is angled 0.01 degrees east. Let's go over those in a sort of quick bullet-point sequence:

• Compounds and Aggregates in PhysX: Solution would generally be have a parent object and have all other shapes be connected to that parent object. The negative is that each shape has physics calculated for them still. This, your giant 1 million part Titanic boat makes the game unplayable because all the bricks in the Captain's bedroom are being calculated alongside every brick in every other room on the ship.

• Voxel-Based Concave Collisions: All collision is created by uniform voxel blocks. The problem is, to put it bluntly, that Brickadia's bricks aren't uniform to a single size, but to a variety of grid increments. Also memory issue possibilities. No gaming here.

• Custom Compound Shapes in PhysX:This is what they chose, let's go home (just kidding). PhsyX, a feature in Unreal Engine, basically does the work for you. Put simply, an object that collides with another object is positioned relative to the object collided with, find the overlapping parts, create the contact points, and then physics-up the contact points.

Are you following along just fine? Let's keep going:

The developers then talk about choosing a Dynamic Spacial Index, which is basically in reference to a brick collision detection system that can have the objects be updated. They then go over some of the things they need for this spatial index system, like the ability to remove objects at random, the ability to handle wildly-different sizes for collisions, and so on and so forth.

Now the devs go over some common spatial data structures that fit the bill for what they are looking for in regard to their collision system. Let's not go over those cause it's 1 AM on a Thursday as I'm typing this. What you need to know is that the developers went with Loose Octrees after regular Octrees asked the developers for voxels, but we know NEVER to talk to a stranger that wants to offer you voxels.

In short, Loose Octrees still didn't fit the bill, and the developers decided to improve what they had with Loose Octrees and call it OctoBVH, BVH standing for Bounding Volume Heirarchies. Why do we need to know this? In short, OctoBVH helps with collision by simplifying boundary boxes by subdividing the overall boundary box into smaller boundary boxes that hold bricks. The bounding box is then used for collision.

If anyone who actually has technical expertise in this is reading this and are just shaking their head, I'm sorry. Please forgive me. Let's keep going!

A lot of stuff from this point mainly deals with information regarding memory, queries, and all that stuff. And frankly, I prefer my stuff to be visually appetizing. Ignoring all of that cause man, we find that with the collision system figured out for the most part in reference to primitives, now brick-on-brick collision needs to be figured out. In other words, how do I cram 10 white whales inside an Office Depot build? The collision box is convex appromated, meaning based on the cubes that we got from OctoBVH for giving birth to it (we love you, kid), those cube subtrees are used to create the convex shape, at least from what I gather. From there, you get this:

Credit: Zeblote

What is interesting is when you pay close attention to this picture, some of the ships don't completely collide/touch each other, and this can mainly be seen with the ship on the most-left and with the ship to the upper right of it. Though, at best, they just may be frozen midair.

And I'll leave it from there, considering the rest of the development blog mainly deals with optimizations for loading builds and lots of code.

Adding to that real quick though, given that the game has been optimized for release with the addition of less memory usage, this will make it easier to be able to play on servers whose brick count reaches the millions!

And now I'm done. This is also the last time I cover technical stuff in this manner, cause even I had a hard time following along. lol.