@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.
- package/README.md +21 -20
- 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.
|
|
5
|
-
|
|
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
|

|
|
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
|
|
39
|
-
`Registry @medieval-kit is not configured in models.json
|
|
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
|
|
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
|
-
|
|
66
|
-
|
|
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
|
|
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
|
|
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
|
|
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
|
-
|
|
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
|
|
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
|
|
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.
|