A village well: a drystone kerb, a timber frame over it, a windlass with
its collars and crank, and a rope and bucket that lower down the shaft.
`setDepth` and `setWinding` drive the bucket; its part origin is the
roller's axis, so winding is a translation and costs nothing per frame.
The kit had no masonry at all, which for a medieval catalogue is a hole
rather than an omission -- a well, a trough, a millstone, a boundary wall
and a hearth are all stone before they are anything else. `stone` is the
twelfth slot. Its colour sits close to weathered oak on purpose: what
separates the two at a glance is not hue but that stone scatters light
completely flat, and roughness is not something vertex colour can carry,
which is exactly the argument the slot table makes for keeping iron and
steel apart.
Four faults on the way in, and three of them are ones this session has seen
before in other models.
The blocks were written footprint-first as [wall, arc]. `rotateY` carries a
footprint's +Z out along the radius and its +X round the circumference, so
every block sat across the ring rather than along it -- each one sticking a
block's length out of a wall a block's width thick. The kerb came out as
rubble thrown at a circle.
The rope started at the roller's axis, which put its whole surface inside
the barrel's hollow interior touching nothing. Then it started in the eye
of the wound coil, which is also a hole. It has to begin within the coil's
material, between 1.0 and 1.34 of the roller radius, so that it crosses the
coil's outer face on the way down.
The actions set `anchor.position.y = 0`, which destroys what `origin` had
just done and dropped the whole rope and bucket by the height of the
roller. Everything the actions touch is now an offset from where the origin
put the anchor.
And the masonry was over the triangle budget at 2 784, almost 1 900 of
which were chamfers on forty-four blocks -- edges the roughen pass softens
anyway, and stone is the one material here where a sharp arris is not
wrong. Plain tapered boxes bring the model to 1 376.
Two things about the wall itself, both from looking at it. Varying each
block by a tenth in arc and thickness put every stone at its own radius and
its own width; a dry wall is irregular the way a hand-cut stone is
irregular, which is a few percent. And blocks cut to exactly their share of
the arc cannot close: a flat face on a curve leaves a wedge of daylight at
every joint, so they are cut long and bite into each other -- safe here
because each is rotated to its own angle and no two adjoining faces are
parallel.
29 models, 22 043 triangles, all checks pass, 0 floating cases, GLB
round-trip clean, Conformant, build clean.
The tinter returned a single Color and mutated it on every call. The
reasoning was sound -- the geometry helpers read the colour immediately, so
an allocation per call is waste -- and it holds right up until two tints
appear as arguments of the SAME call:
latheGeometry(profile, 7, origin, tint('char', 0.06),
{ colourTop: tint('charHot', -0.12) })
Both arguments are the same object and both carry whatever the second call
computed. That is why the torch's pitch head rendered hot orange instead of
black: the char never reached the geometry. The same mistake turned up
twice more in one session -- the anvil's stump came out painted in end
grain on every face, and the shovel nearly went the same way. Three
occurrences means the hazard belongs to the helper, not to the callers, and
a few hundred allocations at build time is not a price worth one class of
silent, invisible bug. `steelTint` and `ironTint` already allocate; the two
disagreeing was itself part of the trap.
With the colour actually arriving, the torch head is also fatter -- at 2.5
shaft radii it was a spindle, where a torch head is a fist of tow and rags
bound on, and it is the whole reason the object is not a stick -- and its
flame is shorter than the head that feeds it rather than twice its height.
The cart wheel's tyre was 23 mm of iron on a 0.52 m radius, set wider than
the wheel itself, and read as a pneumatic. A real tyre is 8 to 12 mm of bar
shrunk onto the felloe. It could not simply be narrowed: the felloe's axial
thickness jitters by ±7%, so anything from 0.93 to 1.07 of the width will
sooner or later share a plane with some piece, and the earlier fix for that
flicker was to go wider than the whole range at 1.1 -- which is what made it
look pneumatic. Going UNDER the range solves it the same way and is the
truer shape: the hoop is set into the tread, and on a worn wheel a sliver
of felloe shows at each edge where the iron has bedded in.
27 models, 19007 triangles, all checks pass, 0 floating cases, GLB
round-trip clean, Conformant, build clean.
Every vertex is mapped by its own Y, so the curve only exists where there
are Y levels to sample it at. Handed a `boxGeometry` -- two levels, top and
bottom -- there is no midpoint to displace: the top face swings to one
angle, the bottom to another, and what comes out is a sheared wedge. It
looks like a curve in the source and is not one in the geometry, and
nothing anywhere reports it.
This session found that same mistake in three separate models: the
tankard's handle, and both the brace and the curl of the tavern sign. In
each one the author had written a curve, the geometry had never curved, and
every render ever produced had shipped the wedge. The sign's was the
expensive one -- the sheared curl pushed the bracket's top above the post it
is bolted to, and it was also hiding a second fault underneath it. Three of
the same bug is a pattern, so the helper now refuses rather than waiting
for a fourth.
The error names the fix, because the tempting response is to adjust the
curvature and the curvature was never the problem: give the piece levels,
or use `arcBarGeometry`, which sweeps a real arc and asks for the two
things that actually matter -- where the ends land.
Mutation-tested both ways: a box is rejected, a five-level lathe still
bends, and all four remaining callers (the broom's shaft, the hoe's neck
and blade, the pitchfork's tines) build unchanged, so they were legitimate
bends all along.
27 models, 18481 triangles, all checks pass, build clean.
Three faults, one of them mine and one that had been there from the start.
The braces were the change this session declined and that reached the repo
anyway, in 715d6af: moved outboard of the uprights, where they connect to
nothing and read as broken sticks. Reverting them was not enough, because
the version they replaced was also wrong -- a single diagonal tilted about
Z, in the same plane as the bell, which had to be shoved in front of it and
drew a line straight across the one silhouette in this model that has to
read cleanly. Neither is what a bell frame does. A real frame is two
A-frames, one at each end of the beam, braced fore-and-aft in their own
planes, with the bell swinging in the gap. Tilting about X instead of Z
puts them there and the bell is never in the way.
The uprights stood at beamLength * 0.34, which at the default yoke is 0.165
against a bell radius of 0.18. With their half-width they spanned 0.147 to
0.183 and ran through the mouth of the bell. Nothing objected: the support
test sees one connected mass, which is precisely what a post driven through
a bell looks like. They now stand at the larger of the yoke's reach and the
bell's radius plus a margin, so a short yoke cannot close the frame onto
the bell -- and the beam's span is derived from that rather than from the
yoke alone, because decoupling the two first left the rail too short to
reach the uprights at the bottom of the slider and the two A-frames came
apart into separate objects.
The foot sat height * 0.16 below the mouth, leaving 24 mm between sill and
lip. A bell hangs clear of its sill; at that gap it read as resting on one.
Colour last. The bell was painted from the `brass` entry and rendered at
hue 39 / saturation 0.56 / value 0.56, against a reference at 33 / 0.34 /
0.33. That is not a subtle disagreement and, unlike the hay bale, the
measurement can be trusted here: a bale photographs desaturated because it
is thousands of straws shadowing each other, while a cast bell is a smooth
surface, so the number is the material rather than the texture. A separate
`bronze` palette entry, derived by inverting the renderer's own gain,
brings it to 30 / 0.31 / 0.43. It is a palette entry and not a slot -- the
mesh still resolves through `brass` -- so the coin pouch and the book's
corner fittings, where fresh yellow bronze is right, are untouched.
27 models, 18457 triangles, all checks pass, 0 floating cases, build clean.
With a reference photograph for every model it became possible to ask a
question the kit could not previously answer: is the colour right? Not
"does it look nice", but how far is it, in degrees and in saturation,
from the real material.
Our oak hue turned out to be correct already -- 26 degrees against 27 in
the photographs -- but saturation ran a median 0.08 high across ten wooden
models, worst on the ones that are almost entirely bare timber: the ladder
and the fence were each 0.16 over. That is the gap between weathered oak
and new pine. After the adjustment the median difference is 0.003 and the
mean absolute error drops from 0.097 to 0.055.
The same measurement said straw and linen were too yellow and too washed
out, and acting on it made them visibly worse, so that change is reverted
and the reason is written into the palette. A bale photographs as
desaturated because it is thousands of straws each shadowing its
neighbour; pushing a flat lowpoly surface to that number does not
reproduce the texture, it just makes the surface garish. The statistic was
real and the inference from it was wrong.
Two further measurements closed off the remaining colour theories. Our
saturation spread is 93% of the references', so the surfaces do not lack
variation, and the hue was never off. Whatever still separates these
models from their references is geometry, not colour -- which is where the
next pass goes.
Also adds the remaining reference shots: all 27 models now have one.
27 models, 17393 triangles, all checks pass, 0 floating cases.
The kit is going public, so everything a reader sees is now English:
27 model sources, the core vocabulary, meta.ts (titles, descriptions and
every slider label), the viewer UI, all script output, REFERENCE.md and
the READMEs.
Rules applied: only comments, doc comments and human-facing strings were
touched. Identifiers, numbers, logic, registry item ids, part names and
material slot names are unchanged — those are a published contract and
were already English.
Verified rather than assumed: for all 53 changed .ts files the code
skeleton (source with comments stripped and string contents replaced by a
placeholder) is byte-identical before and after. Full gate is green —
typecheck, registry conformance, ~510 model checks, GLB round trip and a
production build.
Also fixed here:
- index.html and viewer.html were missed by the translation pass because
the file list only covered .ts/.md/.css. Both had lang="tr" and Turkish
titles.
- The viewer formatted triangle counts with toLocaleString('tr-TR'), which
prints 15.425 rather than 15,425.
- REFERENCE.md's model table header did not match what
scripts/catalog-table.ts emits, so the next regeneration would have
silently changed it. Aligned to the generator.
- Removed scripts/probe.ts and scripts/zdiag.ts; they were throwaway
diagnostics that got committed by accident.
Üçü de render'a bakılarak elden geçirildi. Ortak sebep: her birinde
modelin KONUSU eksikti.
çit — birleşim yoktu. Dört kare çubuk ve önlerine konmuş iki lata;
derinlik/boy oranı 54:1, yani karton. Artık gerçek zıvana var: direk iki
yanak + köprü bloklarından kuruluyor, delik geometrik olarak var oluyor,
kiriş içinden geçip uçlarda karşı yüzden taşıyor. Ayrıca kiriş dağılımı
formülü kaç kiriş olursa olsun hep 0.28–0.78 aralığını dolduruyordu —
üstü ve altı doldurmak yapısal olarak imkânsızdı. 440 → 860 üçgen,
derinlik 0.09 → 0.31 m.
çapa — kaz boynu yoktu. Ağzı sapın ekseninden öne taşıyan kıvrık boyun
olmadan model "kürsü / yol tabelası" diye okunuyordu. Boyun latheGeometry
ile kurulup bükülüyor, ağız boyun ucunun teğetine hizalanıyor; ikisi de
hesapla, gözle değil.
süpürge — demet içi boş bir koni kabuğuydu: bütün levhalar tek halkada.
Üç eşmerkezli halka (6/10/16) kütleyi kuruyor. Bağlar artık demetin dış
yarıçapına oturuyor; eskiden ayrı bir tahmin formülüyle levhaların İÇİNDE
kalıyor ve hiç görünmüyorlardı.
Ölçerek bulunan iki gerçek hata:
- bendGeometry'nin etkisi geometrinin y=0'a göre nerede durduğuna bağlı.
Orijinde ORTALANMIŞ bir gövde simetrik bükülüyor: iki uç aynı yöne
gidiyor, siluet değişmiyor. Çapanın ağzında Z aralığı 0.0337'den
0.0327'ye DÜŞÜYORDU — yani yorumda "sorunu çözüyor" dediğim kavis hiç
yoktu. Tabanı orijinde kurulunca kaçış 44 mm. Yardımcıya yazıldı.
- Süpürgede açılma işareti tersti: rotateX(+f) levhanın ucunu -Z'ye
atıyor, rotateY onu EKSENE doğru çeviriyor. Levhalar ekseni geçip karşı
tarafa savruluyordu; demetin kabuk olmasının asıl sebebi buydu. Gözle
değil ölçüyle yakalandı (genişlik 0.23 beklerken 0.13).
Sistemik: kapanma yarıçapı ve alaca hücresi modelin en büyük ölçüsünden
türetiliyordu. 4.89 m'lik çitte hücre 0.27 m çıkıyor, yani bütün direk tek
hücreye düşüyor ve doku sistemi hiçbir şey yapmıyordu; kapanma yarıçapı
0.69 m ile her şeyi battaniye gibi karartıyordu. İkisi de mutlak sınırlara
alındı — ahşabın damar lekesi nesnenin boyundan bağımsızdır.
Doğrulama: test yamalarının gerçek config alanlarına işaret ettiği artık
denetleniyor. Çapa yeniden yazılırken `bladeAngle` alanı kalkmıştı ama
test hâlâ onu yamalıyordu, yani o varyant sessizce varsayılan modeli
sınıyordu.
render.ts: --angles ile turntable. Tek bir 3/4 açı yanıltıcı — çit ancak
tam yandan bakınca cılız görünüyor.
Kullanıcının prop listesindeki son madde meyve/sebzeydi; sepetle birlikte
kapatıldı çünkü kitte zaten sepet eksikti.
Örgü, biçimi yapımdan türetiyor: yatay halkalar önce düz bant olarak
üretilip köşeleri açılarına bağlı olarak içeri-dışarı itiliyor
(yarıçap × (1 + genlik·cos(dikeySayısı·açı + faz))), ardışık sıralarda faz
π kaydırılıyor. Dikey çubuk başına iki segment yeterli — dalga tam olarak
her çubukta bir artı bir eksi örnekleniyor.
Halka başına iç yüz üretmek altı sırada ~800 üçgen tutuyor ve modeli
lowpoly bütçesinin dışına çıkarıyordu; yerine 44 üçgenlik tek parça iç
astar var.
Yeni `produce` materyal yuvası (mumsu kabuk, roughness 0.52). Meyve rengi
`hue` alanından geliyor: aynı modelden elma, şalgam ya da lahana sepeti.
Modeller (13 → 26): chest, bench, torch, lantern, bell, sign, hay bale,
sack, broom, tankard, book, phial, coin pouch. Kürek, çapa ve yaba
render'lara bakılarak yeniden yazıldı.
core:
- createKitModel artık tipli `actions` ve `update(dt)` taşıyor
- BuiltPart.extras: bir parça birden çok materyal yuvası kullanabiliyor
(sandığın kapağı = meşe tahta + demir kayış, birlikte dönmek zorunda)
- BuiltPart.origin: parça başına dönme merkezi (menteşe, sarkaç)
- bendGeometry / roughenGeometry / mottleGeometry
- 5 yeni materyal yuvası: steel, brass, straw, cloth, leather, glass
- bandGeometry({ inner }) — serbest halkalar kapalı katı olabilsin
my-registry/meta.ts: katalog metadata'sı artık build.ts ve viewer için
tek kaynak. Doğrulama modelle metadata'nın uyuştuğunu denetliyor ve bu
eklendiği gün dört modelde gerçek bir sapma yakaladı.
Doğrulama (~500 kontrol):
- metadata uyumu, eylem semantiği, kare hızı bağımsızlığı
- scripts/render.ts: tarayıcısız yazılım rasterleyici. Bütün doğrulama
geometrikti; "bu kürek küreğe benzemiyor" diyebilmek için modele
bakmak gerekiyordu
- scripts/verify-glb.ts: dışa aktar → geri oku → karşılaştır
GLB dışa aktarımı: viewer düğmesi ve toplu CLI aynı kodu kullanıyor.
Viewer:
- parça paneli (solo/izole) ve materyal yuvası paneli (canlı renk override)
- kit görünümü: 26 model tek sahnede, ölçek ve ton tutarlılığı için
- configure() sonrası gölge bayraklarının düşmesi düzeltildi
A lowpoly medieval procedural model library for Vibe3D, plus the model
inspector used to build it.
Registry (@medieval-kit, published as @medieval-kit/registry):
- core: deterministic mulberry32 RNG, slot-based vertex-coloured materials,
a geometry vocabulary (box, prism, stave, band, head, flip), and the
stable-anchor part slots the Vibe3D protocol requires
- wooden-barrel: 806 tris, 13 separate staves, iron hoops, recessed heads
- wooden-crate: 360 tris, plank rows on corner posts, forged straps
- iron-brazier: 423 tris, typed actions, per-frame flame flicker, own light
The kit declares no renderer capabilities, so it runs on WebGLRenderer as
well as WebGPURenderer. Colour variation lives in vertex attributes rather
than in materials, so each model keeps one draw call per material.
Verification (bun run verify) covers 64 checks without a browser: geometry
validity, winding by two measures (radial alignment for bodies of
revolution, signed volume for closed solids), coplanar-face detection for
z-fighting, stable root and anchor identity across configure(),
deterministic seeding, material ownership, and idempotent disposal.
