volume_pages

Decides which bricks of a volume are worth storing, and where each one lives.

One invocation per brick. It scans the brick's voxels in the source volume, and a brick holding anything over threshold claims a slot from an atomic counter. The slot number lands in the page table (slot + 1, so 0 keeps meaning "empty"), and the brick's grid coordinates land in the slot list so volume_pack knows what to copy into that slot.

Nothing is read back to the CPU and no brick waits on another, so the pass can run every frame — which is what makes the page table usable as the acceleration structure for a volume whose contents change while it renders.

Bindings

#	name	what
0	source	the dense volume being paged (sampled 3D texture)
1	pages	page table, one texel per brick (rgba16f storage)
2	page_alloc	[0] slots handed out, [1] bricks that found the pool full
3	page_slots	four words per slot: the brick's x, y, z, and 1
4	P	PageParams — volume dimensions, brick edge, threshold, channel, capacity

page_alloc must be zeroed before each run; the counter is what allocates, so a stale count hands out slots past the pool.

The page value

A resident brick's page value is slot + 1, split into two digits base 1024 across the texel's red and green channels. The page table is rgba16f because that is the format that is both storage-writable and filterable — the raymarcher binds it where a sampled 3D texture is expected — and a half float only carries integers exactly up to 2048, which one digit stays under. A brick holding nothing writes zero in both channels, so "is anything here" is the sum against zero, the same test the older single-channel occupancy grid answers.

Overflow

A brick that arrives after the pool is full is counted in page_alloc[1] and written as empty. The volume renders without it rather than sharing a slot. page_alloc[0] keeps counting past the capacity, so a caller that reads it back learns the capacity the volume actually needs.