public struct IrradianceBrickCursorWhere a round-robin refill has got to, walked over the indirection grid.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
Doc 19 § L2's "N bricks per frame round robin", as a value both fillers share. The walk is four lines of arithmetic and two subtleties, and the subtleties are the reason this is a type rather than a loop written twice: a coarse brick names itself in every cell it covers, so the walk stops only at the cell that is its origin — otherwise a brick of size eight is filled five hundred and twelve times a lap — and the position has to be dropped when the grid changes shape, because an index into a grid that no longer exists is a different cell every time the resolution changes.
And because the two fillers have to agree. One traces on the CPU and one dispatches; comparing them is how the shader is checked at all, and two implementations of the same ordering is exactly the pair that drifts apart into a comparison of different bricks.
A struct, so a filler holds one by value and there is nothing to allocate or dispose. It is mutable — it is a cursor — so it belongs in a field rather than in a readonly one.
Fields and properties (1)
public int PositionWhich indirection cell the next take starts at.
Methods (1)
public int Take(IrradianceField field, Span<IrradianceBrick> bricks)Takes the next bricks to refill, carrying on from where the last call stopped.
Used by (3)
- CapturedIrradianceFillerVixen.Rendering
- IrradianceFieldFillVixen.Rendering
- TracedIrradianceFillerVixen.Rendering.IrradianceFields