Commit graph

3 commits

Author SHA1 Message Date
CRT
0b2623755f Add the stone trough, and water to put in it
The kit could water nobody. It had a well, a bucket and a cauldron, and all
three are things you carry water IN; a trough is the thing a village keeps
water in, standing in the street outside the smithy.

Two additions to the core, both earned by measurement rather than by wanting
them:

  - `limestone`, a palette key. `stone` was measured off dressed and rubble
    masonry and is grey, because a wall is quarried and laid face out. One
    block left in the open for a century reads hue 36 and saturation 0.16
    against the wall's 44 and 0.05 — warmer, three times more saturated,
    lighter. Both are right and neither replaces the other. The rendered block
    now matches its reference to within a fifth of a degree of hue and 0.004
    of lightness.
  - `water`, a slot, and it is far less green than instinct says. Sampled
    inside the reference's basin the film reads hue 39.5 — which is the hue of
    the stone UNDERNEATH it, not a colour of its own. It darkens and slightly
    saturates whatever it lies on and does that through the material's
    opacity. Painted the pond green I was about to reach for, the composite
    would have missed the reference by a hundred degrees.

Making it read as CARVED rather than sawn took three goes, and the two failures
are opposite errors worth keeping:

  1. Each wall in two tiers, to give `roughenGeometry` more corners to move.
     The tiers' corners sit at different positions, the hash moved them by
     different amounts, and the render showed a lid on a base with a hard seam
     right round it.
  2. One box per wall, roughened harder to compensate. A box has eight corners
     and every face is two triangles, so moving those corners folded each wall
     along its own diagonal. Not stone: creased cardboard.

Both were trying to get subdivision out of the wrong thing. The walls are
`dishedSheetGeometry`, whose own docstring says the trough wants it: one
continuous body with levels along its length, so the rim undulates because
each level carries its own height, the wall thickens and thins because each
carries its own thickness, and there is no join for a seam to open in.

The z-fight checker earned its keep twice on the same plane, `0,-1,0 | 0`.
Four walls standing on the ground all have a face down there, and where the
corners overlap — which is where they are MEANT to overlap — two of those
faces share it. Lifting the basin floor only moved the pairing from
floor-against-wall to wall-against-wall. The answer was to stop there being
four things down there at all: a trough is solid below the water line, so it
is one block from the ground to the basin with the walls sunk into it, by
different amounts, because two buried faces in one plane are still two faces
in one plane.

Last, two defaults that the render corrected rather than the reference. The
walls at 0.27 of the width shut the basin so far that a three-quarter view
showed only its inner face, against the reference's opening of about three
fifths — now 0.21. And the water at 0.55 of the basin's depth sits below the
near rim and the trough reads as dry from every angle anyone will look at it
from; the reference stands a couple of centimetres under the rim, which is
0.85.

36 models, 31 748 triangles, fourteen material slots, all checks pass, 0
floating cases, GLB round-trip clean, Conformant, documentation in step.
2026-08-27 02:46:05 +07:00
CRT
30c7c4863a Take the shoulder off the bench's feet
Reported twice. The first time I planed the through-tenons from 42 mm proud to
3 and called it done, which answered the tenons rather than the question — the
tenons were never it. Measured again now: nothing stands more than 3.9 mm above
the seat at any slider setting, and the thing that was catching was on the
LEGS.

The leg board widens on the way down; that is the splay. The two feet, cut out
of its bottom edge by the arch, were built at `footWidth` — the board's width
at the FLOOR. But a foot starts at the top of the arch, a third of the way up,
where the board has not widened that far yet. So every foot stood proud of the
board it hangs from, on both sides, as a hard shoulder at shin height: 14 mm by
default, 20 mm on a wide bench, 32 mm at full splay. Setting the splay to zero
made it vanish, which is what finally named the cause.

The leg's outer edge is a straight line from `footWidth / 2` at the floor to
`legWidth / 2` under the seat, and a foot's outer face has to lie ON that line
rather than run vertically up from its own base. A tapered box narrows about
its centre, so taking twice the taper off the top width moves the outer face in
by exactly the taper — and moves the inner face out by the same, narrowing the
arch as it rises, which is also what a splayed leg does. 14.2 mm becomes 0.2,
32.3 becomes 0.4, and 0.2 mm is the sampling resolution rather than a step.

`scripts/probe-bench.ts` is how it was found and it took two wrong versions to
get there, both failing the same way — by measuring something and reporting a
number that was not the answer:

  - The first sampled vertices into height bands. A tapered box has corners
    only at its top and bottom, so the bands between them came out empty, were
    skipped, and it reported a confident 0.0 mm step for a leg with a 17 mm
    shoulder on it. It now slices the actual triangles, which gives a width at
    any height whether a corner is there or not.
  - The second scanned the full height of the leg part and found its biggest
    drop at 86% — exactly where the board ends and only the tenon carries on
    into the seat. That is what a tenon IS. A real fault of 14 mm was sitting
    underneath a 66 mm reading that was not a fault at all, so the scan now
    stops at the seat's underside.

Both media images regenerated, since the bench is in each of them.
2026-08-27 02:02:35 +07:00
CRT
a48431ca9c Lay the whole-kit scene out square, and let it be the picture
The image both READMEs open with was a contact sheet whose FIRST cell — top
left, the one everybody's eye lands on — was the `kit` entry: all thirty-five
models arranged in one scene, squeezed into a 300 px cell, an illegible smear.
It is not a model and it does not belong in a grid of models. Rendered on its
own it is by far the better picture anyway, so it is now the picture, and the
contact sheet is a second image beneath it.

Rendering it on its own is also what showed the arrangement had quietly gone
wrong. The row width was a fixed 5.6 m, which was right for a kit of tankards
and barrels and became wrong the moment anything bigger than a row went in: the
oak is 8.6 m across and the mill 6.6, so each took a row to itself while the
small props packed four and five deep. The kit had stretched into a long thin
diagonal, and since a camera fits a bounding SPHERE, the sphere around a
diagonal line is enormous next to the things inside it — the kit occupied about
a quarter of its own picture and the rest was empty floor.

So the row width is measured from the models now rather than fixed: the square
root of the total footprint, which packs rows about as deep as they are wide
whatever the kit happens to contain, floored at the widest single model since
no row can be narrower than the thing standing in it. Swept for the factor:
1.15 gave 15.1 x 21.7 m, 1.45 gave 19.2 x 13.3 — the square is between them,
and 1.24 lands at 16.4 x 14.8, aspect 1.11, filling the framed disc better than
any of them.

It reads as a village yard now: mill and oak at the back, forge and cart in the
middle, the small props at the front. Which is what the entry is FOR — every
model on one ground plane at one scale is the only place a difference in scale
or tone has nowhere to hide.
2026-08-27 01:50:26 +07:00