@medieval-kit/registry 0.1.0 → 0.1.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +21 -20
  2. package/package.json +1 -1
package/README.md CHANGED
@@ -1,8 +1,8 @@
1
1
  # Medieval Kit
2
2
 
3
3
  A lowpoly medieval model library for [Vibe3D](https://github.com/vibe-stack/vibe3d)
4
- and Three.js. Install a prop and you own its source: readable TypeScript in your
5
- own tree, not an opaque package boundary.
4
+ and Three.js. Installing a prop puts its source in your own tree, as readable
5
+ TypeScript you can edit.
6
6
 
7
7
  ![The whole kit in one scene](https://medieval.crt.fyi/kit.png)
8
8
 
@@ -35,8 +35,8 @@ so without it the source you just installed does not typecheck.
35
35
  }
36
36
  ```
37
37
 
38
- That map is how the namespace resolves `vibe3d add` stops with
39
- `Registry @medieval-kit is not configured in models.json` without it.
38
+ That map is how the namespace resolves. Without it `vibe3d add` stops with
39
+ `Registry @medieval-kit is not configured in models.json`.
40
40
 
41
41
  Then take one model, or the lot:
42
42
 
@@ -49,21 +49,23 @@ bunx vibe3d add @medieval-kit
49
49
 
50
50
  The installed source imports through the `@/` alias that `models.json` declares,
51
51
  and it imports `.ts` files by their extension. Both have to be true on your side
52
- as well in `tsconfig.json`:
52
+ as well. In `tsconfig.json`:
53
53
 
54
54
  ```json
55
55
  {
56
56
  "compilerOptions": {
57
57
  "moduleResolution": "bundler",
58
58
  "allowImportingTsExtensions": true,
59
- "baseUrl": ".",
60
59
  "paths": { "@/*": ["./src/*"] }
61
60
  }
62
61
  }
63
62
  ```
64
63
 
65
- and in your bundler, because TypeScript's `paths` only teaches the type checker.
66
- For Vite:
64
+ No `baseUrl`. It was removed in TypeScript 7, and `paths` resolves relative to
65
+ this file on its own. Verified against a clean project on 7.0.2.
66
+
67
+ The alias has to be set in your bundler too, because TypeScript's `paths` only
68
+ teaches the type checker. For Vite:
67
69
 
68
70
  ```ts
69
71
  resolve: { alias: [{ find: '@', replacement: fileURLToPath(new URL('./src', import.meta.url)) }] }
@@ -72,7 +74,7 @@ resolve: { alias: [{ find: '@', replacement: fileURLToPath(new URL('./src', impo
72
74
  ## Models
73
75
 
74
76
  37 models and one shared lib. Addresses are `@medieval-kit/<id>`. This table is
75
- generated from the models themselves with `bun scripts/catalog-table.ts` — a
77
+ generated from the models themselves with `bun scripts/catalog-table.ts`. A
76
78
  hand-written list goes stale on the first model you add, and this one already
77
79
  did once.
78
80
 
@@ -154,7 +156,7 @@ Each model follows the Vibe3D protocol:
154
156
 
155
157
  - **`root`** keeps its object identity for the model's whole lifetime.
156
158
  - **`parts`** expose stable semantic anchors. Attach your own lights, labels, or
157
- gameplay objects to `part.anchor` they survive `configure()`, because only
159
+ gameplay objects to `part.anchor`. They survive `configure()`, because only
158
160
  `part.content` is rebuilt.
159
161
  - **`materials`** resolve per slot and can be overridden. Materials you supply
160
162
  are borrowed: the model never disposes them.
@@ -187,24 +189,23 @@ difference.
187
189
 
188
190
  | Slot | What it covers | Why it is separate |
189
191
  | --- | --- | --- |
190
- | `oak` | timber | |
192
+ | `oak` | timber | the baseline everything else is measured against |
191
193
  | `iron` | forged iron, oxidised and matte | separate from `steel`: the difference is not in colour but in ROUGHNESS, and vertex colour cannot carry roughness |
192
194
  | `steel` | steel polished by use | the anvil face, the shovel blade, the pitchfork tines |
193
195
  | `brass` | bronze and copper | the bell, the coins |
194
196
  | `straw` | straw, wicker, broom bristle | a bale declaring itself "oak" would be a lie told to the consumer |
195
- | `cloth` | linen, sackcloth, rope | |
196
- | `leather` | worked leather | |
197
+ | `cloth` | linen, sackcloth, rope | woven, so it takes light softly and never glints |
198
+ | `leather` | worked leather | darker and glossier than cloth at the same colour |
197
199
  | `glass` | blown glass | transparent, `depthWrite` OFF, `DoubleSide` |
198
200
  | `produce` | fruit and vegetable skin | given straw's roughness, an apple would look like dry grass |
199
- | `ember` | flame | `MeshBasicMaterial` it does not receive light, it emits |
200
- | `char` | charcoal and pitch | |
201
+ | `ember` | flame | `MeshBasicMaterial`: it does not receive light, it emits |
202
+ | `char` | charcoal and pitch | the darkest thing in the kit, and it has to stay readable against shadow |
201
203
  | `water` | standing water | a thin transparent film over whatever holds it: in the reference trough the basin reads hue 39.5, which is the hue of the STONE underneath, so it works through opacity rather than colour |
202
204
  | `stone` | dressed and rubble masonry | its colour is close to weathered oak; what separates them at a glance is that stone scatters light completely flat, and roughness is not something vertex colour can carry |
203
205
 
204
206
  `ember` also acts as a rule in two places: bodies in that slot are skipped
205
- entirely while ambient occlusion and mottle are baked. The reason is simple
206
- in an unlit material the vertex colour *is* the final colour, so darkening it
207
- puts the flame out. The rule is attached to the slot itself rather than to a
207
+ entirely while ambient occlusion and mottle are baked. The reason is simple: in an unlit material the vertex colour *is* the final
208
+ colour, so darkening it puts the flame out. The rule is attached to the slot itself rather than to a
208
209
  per-model flag, so it cannot be forgotten.
209
210
 
210
211
  Colour variation lives in the geometry, not in the materials: each of the
@@ -220,12 +221,12 @@ bunx vibe3d registry validate dist/registry.json
220
221
 
221
222
  The build walks `models/`. A folder containing `model.ts` becomes a
222
223
  `vibe3d:model`; any other folder becomes a `vibe3d:lib`. Registry dependencies
223
- are derived from the source an import from `../core/` makes
224
+ are derived from the source. An import from `../core/` makes
224
225
  `@medieval-kit/core` a dependency automatically, so there is no hand-maintained
225
226
  list to go stale.
226
227
 
227
228
  `drafts/` is deliberately outside that walk: the code is kept in the tree but
228
- never reaches the published package including its own `drafts/README.md`,
229
+ never reaches the published package, including its own `drafts/README.md`,
229
230
  which is why this sentence does not link to it. A relative link on an npm
230
231
  package page resolves against the repository, and there is nothing at the
231
232
  other end of it for a reader of this page.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@medieval-kit/registry",
3
- "version": "0.1.0",
3
+ "version": "0.1.2",
4
4
  "description": "A lowpoly medieval procedural model library for Vibe3D and Three.js.",
5
5
  "type": "module",
6
6
  "license": "MIT",