Understanding Blocks & _blockSize

What Are Blocks?

When Q3Map2 runs the VIS stage, it overlays the map with an invisible grid. Each cell of that grid is a block. By default, the grid spacing is 1024 × 1024 units on the X and Y axes, extending through the full Z height of the map. This means your level is automatically sliced into a series of vertical prisms, each one a block.

When Q3Map2 runs the VIS stage, it has to determine which parts of the map can potentially see one another. Performing those calculations across an entire level all at once would be extremely expensive, especially in maps with a lot of detail. To make the task manageable, the compiler overlays an invisible grid across the map and divides it into blocks.

This block grid allows the compiler to work locally rather than globally. Visibility calculations can be processed within a block and then extended outward to neighboring blocks, rather than having to consider the entire level in one sweep. In effect, blocks reduce the scope of the problem into chunks, which makes the VIS process much faster and less memory-intensive.

Blocks are not the same thing as map geometry, nor do they replace walls, doors, or hint brushes. They are purely a compilation aid to the VIS algorithm. Once the map is fully compiled, the block structure disappears and the game engine never thinks about it again.

Why Adjust Block size?

This is a largely untouched value, as most level designers had no issues with the default blocksize value and would often only increase it when running into issues. But there are a few cases where I think it's necessary to tune your own value. While some people advise to increase blocksize in your compile switches, I have found if you use _blockSize in the worldspawn setting, you're able to tune the X Y axis independently(Z axis will always extend to the void without splitting).

• A very large map with expansive outdoor areas, increasing block size can reduce the total number of blocks and therefore speed up VIS.
• A dense map with lots of detail, sometimes decreasing block size helps the compiler manage visibility more effectively and can reduce overdraw.
• In most cases 512 512 will suffice for a VIS pass, with wise structural brush placement. Often only needing minimal hint brushes to help problematic areas.
• A linear layout could have the X and Y axis split at different intervals, eg. 512 1024
• A confident level designer can also reduce it to 0 0 and build their own X Y and Z splits along specific structural geometry.
• While it is not mentioned in any documentation, _blockSize accepts a 3rd value for the Z axis. So you can split more vertical maps with this value, though if no value is set it will default to 0. I would not recommend changing this for Urban Terror.