About this calculator
This calculator estimates how many OSB sheets, framing members, and fasteners a ceiling needs, given the room's length and width, the sheet size, orientation and edge profile you're buying, and whether the sheets are fixed to joists/battens or to an existing solid substrate. It shares its core layout logic with this platform's OSB wall sheathing calculator (framed vs solid mode, the same suggested-spacing, joint-offset, framing-member, and fastener reasoning), with two changes a ceiling specifically needs: sheets run across the primary member rather than along it by default, and consecutive rows are staggered so a continuous joint line doesn't run across the ceiling.
Formula
The room is tiled in rows stacked across its width (one row per sheet length), each
row tiled across the room's length in sheet-width pieces — the same tileRun and
row/pooling logic as the wall calculator (see its own Formula section for the full
framed-vs-solid reasoning), with one addition:
rowCount = ceil(roomWidth / sheetLength)
row 0, 2, 4, ... starts at offset 0
row 1, 3, 5, ... starts at offset effectiveSheetWidth / 2 (staggered)
Staggering alternate rows means a joint in one row does not sit directly above the joint in the row beside it — the defect this avoids is a continuous seam running across the ceiling. Whether staggering changes the sheet count is computed for your actual inputs, not assumed: the calculator builds both the staggered layout (what it actually reports) and an unstaggered comparison, and states plainly whether they differ for this room, and by how many sheets, whenever they do.
Sheet orientation (widthwise, the default, or lengthwise) picks which
physical sheet dimension tiles across the room's length vs stacks across its width —
widthwise keeps this calculator's original behaviour (long dimension stacking
across the width); lengthwise swaps the two. This changes the sheet count itself,
computed for both orientations every run so the cheaper one is visible without
re-running.
Framing direction (framed mode only) picks which axis the primary member runs
along: widthwise joists (spaced along the room's length, this calculator's original
behaviour) or lengthwise battens (spaced along the room's width, perpendicular
counter-battening — common when levelling an uneven ceiling or adding services).
Suggested spacing and the joint-alignment offset check both follow whichever sheet
dimension actually crosses that member's own spacing axis — exactly the wall
calculator's own reasoning. Because rows are staggered here, a widthwise check
runs per row (each row's own piece boundaries differ from its neighbour's) while a
lengthwise check runs once against the row-height sequence (stagger never changes
row heights, only where each row's own pieces start).
A sheet's long axis should run across its supports, spanning several rather than
resting on two — the same rule and the same warning-not-block behaviour as the
wall calculator, firing whenever sheetOrientation and framingDirection name the
same axis.
Framing members (framed mode only) follow the wall calculator's own model:
primary members (joists or battens) at floor(run / primarySpacing) + 1, noggins at
every horizontal joint (widthwise framing only, one per joist bay), and — per
opening — two trimmers plus two headers (a ceiling opening has no floor reference,
so both ends get a header rather than a wall's distinct head/sill). Solid mode omits
the framing section and parts list entirely, not zeros.
Fasteners (both modes) follow the same perimeter/intermediate line model as the wall calculator, adapted for stagger: since staggered rows have different piece boundaries, the tile-direction lines are computed per row (each only as long as that row's own height), while the row-boundary lines are computed once for the whole room's length.
Openings (light fittings, a loft hatch) are not deducted from the sheet count, for the same reason as the wall calculator: a fitting mid-sheet is waste, not a saved sheet.
Worked example
4200 x 3600 mm ceiling, one 300 x 300 mm light fitting, 2500 x 1250 mm square-edge sheets, framed mode, 625 mm joist spacing (the suggested spacing for a 1250 mm-wide sheet), 5% waste.
rowCount = ceil(3600 / 2500) = 2 -- row0: 2500mm, row1: 1100mm (staggered)
tileRun(4200, 1250, 0) = [1250, 1250, 1250, 450] -- row0, 4 pieces
tileRun(4200, 1250, 625) = [625, 1250, 1250, 1075] -- row1, 4 pieces
row0 (2500mm tall = the full stock height): no spare sheet height for a second
shelf, so all 4 pieces need their own sheet -> 4 sheets
row1 (1100mm tall): floor(2500/1100)=2 shelves fit per sheet. The two 1250mm
pieces exactly fill one sheet as two shelves; the 1075mm piece opens a second
sheet (leaving a 175mm sliver, narrower than the 200mm minUsableOffcut, so
scrapped rather than offered to the last piece); the 625mm piece opens a
second shelf in that same sheet (1400mm was still free) -> 2 sheets
framed = 4 + 2 = 6 sheets. Unstaggered comparison also gives 6 (verified via
script) -- staggering does not change the count for this room.
6 sheets net, plus 5% waste (round_up(6 x 5 / 100) = 1) for 7 sheets required.
Solid mode for this same room also needs 6 — pooling both rows into one packing
pass finds nothing left to rescue once each row's own pieces already pack this
efficiently on their own.
A 1650 x 5000 mm ceiling shows framed and solid genuinely diverging instead:
tileRun(1650, 1250, 0) = [1250, 400] for the even row, and (staggered by half
of 1250 = 625mm) tileRun(1650, 1250, 625) = [625, 1025] for the odd row — both
rows the full 2500mm stock height. Framed packs each row on its own: row0's
1250+400 need 2 sheets (no spare height for a second shelf, and 400 does not fit
the 1250-wide sheet's own already-used shelf), row1's 1025+625 likewise need 2
(the 225mm leftover from the 1025 piece is too narrow for the 625 piece) —
4 sheets. Solid mode pools all four pieces: the 1250 and 1025 pieces each
open their own sheet (leaving unusable 0mm and 225mm remainders), the 625 piece
opens a third sheet leaving a 625mm-wide offcut, and the remaining 400-wide piece
fits into that same offcut instead of opening a fourth — 3 sheets.
Staggering itself can still change the sheet count under this packing, just less often than the old cell-per-sheet model suggested: a 1606 x 6270 mm ceiling in solid mode needs 5 sheets staggered versus 4 unstaggered (verified via script) — which pieces a given row's own tiling produces changes whether they can share a sheet with another row's own offcut, and staggering changes those widths. The calculator always uses the staggered (correct) layout for the number it reports; the comparison exists only to tell you honestly whether stagger changed anything for your room, in whichever direction it actually goes.
Laid lengthwise instead, this same 4200 x 3600 mm room also needs 6 sheets — tied with widthwise, unlike the pre-packing model where lengthwise was cheaper.
At the default 625 mm joist spacing, framing for this room (7 joists the full 3600 mm width, 6 noggins 580 mm long at the single horizontal joint, plus the fitting's own 2 trimmers at 300 mm and 2 headers at 390 mm) totals 30,060 mm of 45x95 mm timber — 0.129 m³. Fasteners (perimeter lines along every sheet edge at 150 mm, intermediate lines along the 3 joists that fall inside each row rather than on its own edges, at 300 mm) total 251, one box of 500.
FAQ
Why does the ceiling calculator stagger rows but the wall calculator doesn't? Because the wall calculator's own rows sit one above another with a real horizontal joint that needs noggin/blocking support regardless of where it falls — there's no "continuous line" defect to avoid there in the same sense. A ceiling's row-to-row joints are less constrained (they don't need to land on a joist), which is exactly why they're staggered instead: to break up what would otherwise be a straight seam across the whole ceiling.
Does staggering always cost an extra sheet? No, and it does not even reliably cost one at all under correct packing: see the worked example above, where it costs nothing for a 4200x3600 mm room, and the 1606x6270 mm case where it does cost one. Which is true depends on how the row widths it produces interact with the packing, not a fixed rule — this calculator computes both layouts and reports the true answer for your own inputs rather than assuming either direction.
How narrow does an offcut have to be before the calculator writes it off as
scrap?
Whatever minUsableOffcut is set to (200 mm by default) — see the wall
calculator's own FAQ entry for the same reasoning; identical here.
Why is T&G the default edge profile here but square edge for walls? Because T&G is the typical edge profile for floors and ceilings, less so for walls — see this platform's OSB wall sheathing calculator for the same coverage-loss reasoning and its own disclosed, editable default.
Why do ceiling openings get two headers instead of a wall's head-and-sill?
Because a ceiling opening has no floor reference — there is no sillHeight field,
so nothing distinguishes one end from the other the way a wall opening's sill height
does. Both ends get the same kind of member (a "header"), each spanning across the
two trimmers the same way a wall's own head does.
What standard does this calculator cite? None — see the wall calculator's own FAQ entry; the same reasoning applies (OSB the material is standardised, its installation layout is not).
Assumptions and limits
The stagger offset is exactly half the effective tiling dimension, applied to
every other row regardless of sheetOrientation. This is the conventional
running-bond pattern; the calculator does not attempt a different fractional offset.
The sheet-packing is a heuristic (first-fit decreasing height, guillotine cuts
only), not a globally optimal cutting-stock solver — see the wall calculator's
own Assumptions section for the same limitation, including why pieces are never
rotated (a calculator-wide sheetOrientation already fixes which physical sheet
dimension plays which role for the whole ceiling).
Openings never reduce the sheet count, only the informational net-area figure.
The room is treated as a plain rectangle (length x width) — there is no polygonal room-shape input here, unlike this platform's drywall-ceiling calculator.
This calculator does not attempt structural sizing. framingSection and
primarySpacing are the user's own input, not a span table, load calculation, or
code-compliance check — see the wall calculator's own Assumptions section; the same
reasoning applies here.
Opening trimmers and headers are additional members, not a replacement for whichever regular joists/battens an opening's own rough width would otherwise interrupt — see the wall calculator's own Assumptions section for the same limitation.
Noggin length uses the regular bay spacing uniformly for every bay, and fastener counts are a line-length-and-spacing estimate, not a simulated nail pattern — both exactly as documented in the wall calculator's own Assumptions section, including its disclosed gap for a vertical-joint-equivalent blocking member under lengthwise battens alone (this calculator does not add one either).
perimeterSpacing/intermediateSpacing/fastenerBoxSize are widespread trade practice, not a citable standard — see the wall calculator's own Assumptions section for the same disclosure.