volume_pack

Fills the brick pool from the volume volume_pages has just paged.

One invocation per pool voxel. The pool is a grid of blocks, one block per slot; a block holds a brick plus a one-voxel apron taken from the neighbouring bricks, so a trilinear sample inside a brick reads what the dense volume would have given it rather than whatever brick the pool stores next door.

Bindings

#	name	what
0	source	the dense volume being paged (sampled 3D texture)
1	atlas	the brick pool (rgba16f storage)
2	page_slots	four words per slot, written by volume_pages
3	K	PackParams — volume dimensions and brick edge

Why the pool is always rgba16f

A pool is written as a storage texture and sampled with filtering. rgba16f is the format that is both: the one-channel formats cannot be written as storage textures, and r32f cannot be filtered without a device feature the engine does not require. So a scalar volume's density rides in the pool's red channel — which is where the raymarcher reads density from in density mode — and pays rgba16f per resident voxel. Volume:sparseStats() reports the dense and resident sizes side by side rather than assuming paging is the smaller of the two.

The pass writes every voxel of the pool, including blocks whose slot was never handed out: those hold whatever brick their stale slot entry names, and the page table never points at them.