@genex-ai/cli-demo 0.93.0 → 0.94.0-dev.249
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/dist/index.js +26 -5
- package/package.json +1 -1
- package/templates/skills/genex-ai-model/SKILL.md +3 -2
- package/templates/skills/genex-ai-skybox/SKILL.md +4 -4
- package/templates/skills/genex-ai-texture/SKILL.md +1 -1
- package/templates/skills/genex-ai-video/SKILL.md +1 -1
- package/templates/skills/genex-game-director/SKILL.md +321 -411
- package/templates/skills/genex-game-director/references/design-contract.md +130 -179
- package/templates/skills/genex-game-director/references/routing-map.md +242 -362
- package/templates/skills/genex-getting-started/SKILL.md +2 -2
- package/templates/skills/genex-threejs-exposure-color-grading/SKILL.md +3 -7
- package/templates/skills/genex-threejs-multiplayer/SKILL.md +19 -2
- package/templates/skills/genex-threejs-procedural-assets/SKILL.md +112 -0
- package/templates/skills/genex-threejs-procedural-materials/SKILL.md +3 -7
- package/templates/skills/genex-threejs-procedural-vfx/SKILL.md +6 -11
- package/templates/skills/genex-threejs-shadow-systems/SKILL.md +2 -3
- package/templates/skills/genex-threejs-visual-validation/SKILL.md +0 -4
- package/templates/skills/genex-updates/SKILL.md +1 -1
- package/templates/skills/genex-threejs-atmosphere-aerial-perspective/SKILL.md +0 -46
- package/templates/skills/genex-threejs-atmosphere-aerial-perspective/references/atmosphere.md +0 -213
- package/templates/skills/genex-threejs-bloom/SKILL.md +0 -44
- package/templates/skills/genex-threejs-bloom/references/bloom.md +0 -187
- package/templates/skills/genex-threejs-exposure-color-grading/references/exposure-grading.md +0 -205
- package/templates/skills/genex-threejs-game-content/SKILL.md +0 -198
- package/templates/skills/genex-threejs-game-content/references/content-tables.md +0 -269
- package/templates/skills/genex-threejs-image-pipeline/SKILL.md +0 -56
- package/templates/skills/genex-threejs-image-pipeline/references/image-pipeline.md +0 -197
- package/templates/skills/genex-threejs-lighting-design/SKILL.md +0 -144
- package/templates/skills/genex-threejs-lighting-design/references/light-recipes.md +0 -137
- package/templates/skills/genex-threejs-open-world/SKILL.md +0 -149
- package/templates/skills/genex-threejs-open-world/references/terrain-streaming.md +0 -215
- package/templates/skills/genex-threejs-precipitation-surfaces/SKILL.md +0 -59
- package/templates/skills/genex-threejs-precipitation-surfaces/references/precipitation-surfaces.md +0 -181
- package/templates/skills/genex-threejs-procedural-architecture/SKILL.md +0 -50
- package/templates/skills/genex-threejs-procedural-architecture/references/architecture-systems.md +0 -509
- package/templates/skills/genex-threejs-procedural-fields/SKILL.md +0 -61
- package/templates/skills/genex-threejs-procedural-fields/references/field-systems.md +0 -232
- package/templates/skills/genex-threejs-procedural-geometry/SKILL.md +0 -39
- package/templates/skills/genex-threejs-procedural-geometry/references/mesh-systems.md +0 -202
- package/templates/skills/genex-threejs-procedural-materials/references/material-systems.md +0 -198
- package/templates/skills/genex-threejs-procedural-planets/SKILL.md +0 -48
- package/templates/skills/genex-threejs-procedural-planets/references/planet-systems.md +0 -498
- package/templates/skills/genex-threejs-procedural-vegetation/SKILL.md +0 -52
- package/templates/skills/genex-threejs-procedural-vegetation/references/vegetation-systems.md +0 -314
- package/templates/skills/genex-threejs-procedural-vfx/references/vfx-systems.md +0 -218
- package/templates/skills/genex-threejs-raymarched-space-effects/SKILL.md +0 -37
- package/templates/skills/genex-threejs-raymarched-space-effects/references/space-effects.md +0 -194
- package/templates/skills/genex-threejs-screen-space-ambient-occlusion/SKILL.md +0 -35
- package/templates/skills/genex-threejs-screen-space-ambient-occlusion/references/ambient-occlusion.md +0 -441
- package/templates/skills/genex-threejs-spectral-ocean/SKILL.md +0 -52
- package/templates/skills/genex-threejs-spectral-ocean/references/spectral-ocean.md +0 -473
- package/templates/skills/genex-threejs-temporal-surfaces/SKILL.md +0 -41
- package/templates/skills/genex-threejs-temporal-surfaces/references/temporal-surfaces.md +0 -207
- package/templates/skills/genex-threejs-visual-validation/references/visual-validation.md +0 -427
- package/templates/skills/genex-threejs-volumetric-clouds/SKILL.md +0 -49
- package/templates/skills/genex-threejs-volumetric-clouds/references/volumetric-clouds.md +0 -579
- package/templates/skills/genex-threejs-water-optics/SKILL.md +0 -57
- package/templates/skills/genex-threejs-water-optics/references/water-optics.md +0 -195
|
@@ -131,7 +131,7 @@ and re-link the clone to the same live game:
|
|
|
131
131
|
```bash
|
|
132
132
|
git clone <the game's repo url> my-game && cd my-game
|
|
133
133
|
npm install
|
|
134
|
-
npx @genex-ai/cli-demo@
|
|
134
|
+
npx @genex-ai/cli-demo@dev link <slug> # slug = the name in the play URL
|
|
135
135
|
```
|
|
136
136
|
|
|
137
137
|
Don't know the slug? **`npx genex list`** prints every game on your account —
|
|
@@ -158,7 +158,7 @@ Safe to run any time — genex-owned skills are refreshed to the latest version,
|
|
|
158
158
|
and your own files are never touched:
|
|
159
159
|
|
|
160
160
|
```bash
|
|
161
|
-
npx @genex-ai/cli-demo@
|
|
161
|
+
npx @genex-ai/cli-demo@dev init
|
|
162
162
|
```
|
|
163
163
|
|
|
164
164
|
Use `--force` only if you intentionally want your own existing files overwritten
|
|
@@ -18,10 +18,6 @@ HDR scene
|
|
|
18
18
|
→ final output conversion
|
|
19
19
|
```
|
|
20
20
|
|
|
21
|
-
Read [references/exposure-grading.md](references/exposure-grading.md)
|
|
22
|
-
for the exact 64x36 meter, encoded readback, adaptation constants, 32-cube LUT,
|
|
23
|
-
and signal-ownership ambiguities.
|
|
24
|
-
|
|
25
21
|
## Film grain — add it only if the look calls for it, and author it correctly
|
|
26
22
|
|
|
27
23
|
Film grain is a legitimate look. **Badly-authored grain is the single most common
|
|
@@ -89,6 +85,6 @@ c += g * uGrain * lw; // uGrain ~0.02–0.03, NOT 0.045
|
|
|
89
85
|
|
|
90
86
|
## Routing boundary
|
|
91
87
|
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
88
|
+
Keep HDR glow, AO, atmosphere, and shared render-target ordering in the game's
|
|
89
|
+
existing post stack. This skill owns exposure, tone mapping, grading, and output
|
|
90
|
+
conversion only.
|
|
@@ -46,10 +46,10 @@ npm i @genex-ai/multiplayer@^0.12.0
|
|
|
46
46
|
> landed in 0.10; confirmed object controls, snaps, host-tick teardown, and reconnect rebasing
|
|
47
47
|
> in 0.9. An older resolve does not have those.
|
|
48
48
|
|
|
49
|
-
This skill targets `@genex-ai/multiplayer` **≥ 0.
|
|
49
|
+
This skill targets `@genex-ai/multiplayer` **≥ 0.13.0** (`objects`/`host` since 0.4; verified per-player `avatarUrl` since 0.12;
|
|
50
50
|
`matchmake()` since 0.5; private lobbies since 0.7; auto-reconnect + `inputs`/`onHostTick`
|
|
51
51
|
since 0.8; soft ownership handoff since 0.8.4; confirmed controls, snap epochs, and host-tick
|
|
52
|
-
lifecycle guarantees since 0.9; regional relay selection via `getColyseusUrls()` since 0.10;
|
|
52
|
+
lifecycle guarantees since 0.9; regional relay selection via `getColyseusUrls()` since 0.10; host-only `setRoomOpen()` since 0.13;
|
|
53
53
|
exact-relay `url` overrides for cross-region invites since 0.11).
|
|
54
54
|
|
|
55
55
|
## Trust model (say it plainly in your game's copy)
|
|
@@ -598,6 +598,23 @@ fights (many writers). A ball on `objects` glides and has one owner. That's the
|
|
|
598
598
|
|
|
599
599
|
The same rule covers anything else you lazily load per player or per object (nameplates, weapon
|
|
600
600
|
models, audio): a check that straddles an `await` is not a guard.
|
|
601
|
+
- `room.setRoomOpen(open)` — **host only.** Stop (or resume) the matchmaker putting NEW players
|
|
602
|
+
into THIS room. A lobby game needs this: once your match starts, arrivals would otherwise be
|
|
603
|
+
dropped into a fight already in progress. Close the room at match start and the next arrival
|
|
604
|
+
forms the NEXT room instead; reopen when you return to the lobby. Everyone already inside keeps
|
|
605
|
+
playing, and a reconnecting player still gets back in (reconnection uses a reserved seat, not
|
|
606
|
+
matchmaking). A non-host call is ignored, so check `isHost` first — and because the host can
|
|
607
|
+
change, re-assert it on `on('host')` rather than only once at match start:
|
|
608
|
+
|
|
609
|
+
```ts
|
|
610
|
+
function startMatch() {
|
|
611
|
+
if (room.isHost) room.setRoomOpen(false); // late arrivals form the next lobby
|
|
612
|
+
}
|
|
613
|
+
function backToLobby() {
|
|
614
|
+
if (room.isHost) room.setRoomOpen(true);
|
|
615
|
+
}
|
|
616
|
+
room.on("room:open", ({ open }) => showLobbyClosedBadge(!open)); // every client is told
|
|
617
|
+
```
|
|
601
618
|
- `room.activePlayers` — the connected-only subset of `room.players`; use its size for live quorum.
|
|
602
619
|
- `room.objects` — shared objects nobody owns until claimed (a ball, an NPC):
|
|
603
620
|
- `claim(id)` — **legacy** optimistic request. It flips local ownership immediately and is corrected
|
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: genex-threejs-procedural-assets
|
|
3
|
+
description: Build editable, parameterized Three.js props from reference images or explicit procedural requests. Use when the user asks for a procedural, parametric, code-built, customizable, seeded, or variation-ready prop, hard-surface object, modular decoration, or simple structure. Do not trigger merely because an image exists.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Genex Three.js Procedural Assets
|
|
7
|
+
|
|
8
|
+
Build a recognizable asset as local, editable Three.js code when code is the
|
|
9
|
+
requested product—not as a fallback for every object.
|
|
10
|
+
|
|
11
|
+
## Choose the route
|
|
12
|
+
|
|
13
|
+
- Start directly when the user says procedural, parametric, code-built,
|
|
14
|
+
customizable, seeded, or asks for controlled variations.
|
|
15
|
+
- An attached or available image does not activate this skill by itself.
|
|
16
|
+
- If “make this image 3D” could honestly mean either route, ask exactly one
|
|
17
|
+
question: **“Do you want a generated textured GLB, or editable procedural
|
|
18
|
+
Three.js code?”**
|
|
19
|
+
- Use `$genex-ai-model` when the user chooses a generated textured GLB.
|
|
20
|
+
- Use this skill for props, hard-surface objects, modular decorations, and
|
|
21
|
+
simple structures or environment pieces.
|
|
22
|
+
- Do not use it for characters, creatures, rigging, skeletal animation, or
|
|
23
|
+
character likeness. Keep those in their existing specialist lanes.
|
|
24
|
+
|
|
25
|
+
## Keep the reference safe
|
|
26
|
+
|
|
27
|
+
A user attachment, local file, or private URL is build input only. Inspect it
|
|
28
|
+
in place. Do not upload it, place it in `public/`, publish it, or commit a copy
|
|
29
|
+
without the user's permission.
|
|
30
|
+
|
|
31
|
+
When no reference exists and one would materially improve the requested
|
|
32
|
+
asset, use the existing `npx genex image` route. Record that image as its own
|
|
33
|
+
normal paid generation row in `DESIGN.md`, including its generation ID and
|
|
34
|
+
landed URL. Do not create another image pipeline or automatically re-roll a
|
|
35
|
+
reference.
|
|
36
|
+
|
|
37
|
+
State which geometry is visible and which geometry is inferred. A single view
|
|
38
|
+
does not prove its hidden sides. Ask for another view only when the requested
|
|
39
|
+
fidelity or gameplay behavior genuinely depends on it; otherwise make a
|
|
40
|
+
reasonable inference and name it.
|
|
41
|
+
|
|
42
|
+
## Record the work in `DESIGN.md`
|
|
43
|
+
|
|
44
|
+
Give the procedural result a separate row in the existing Assets table:
|
|
45
|
+
|
|
46
|
+
```markdown
|
|
47
|
+
| <asset> | procedural-code | building (blockout) | — |
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
Use this status flow:
|
|
51
|
+
|
|
52
|
+
```text
|
|
53
|
+
proposed → planned → building (blockout | detail | material | runtime)
|
|
54
|
+
→ landed (<local TypeScript path>) → wired
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
A Genex-generated reference keeps its separate image row and normal paid
|
|
58
|
+
generation status. Note that the procedural-code row is derived from that
|
|
59
|
+
image. A private user reference is not a paid generation row.
|
|
60
|
+
|
|
61
|
+
Keep only useful state: intended use, fidelity target, reference provenance,
|
|
62
|
+
visible versus inferred regions, any required moving parts or collision
|
|
63
|
+
shape, current stage, output path, and comparison evidence. Do not add a
|
|
64
|
+
second review ledger.
|
|
65
|
+
|
|
66
|
+
## Build the asset
|
|
67
|
+
|
|
68
|
+
1. Identify the silhouette, proportions, part relationships, material zones,
|
|
69
|
+
and the few details that make the subject recognizable.
|
|
70
|
+
2. Define meaningful parameters before geometry: dimensions, part counts,
|
|
71
|
+
thicknesses, palette or material choices, and variation ranges. Add an
|
|
72
|
+
optional seed only when controlled variation is useful.
|
|
73
|
+
3. Build the smallest blockout that proves massing and scale. Use named child
|
|
74
|
+
objects for semantic parts rather than one anonymous group of primitives.
|
|
75
|
+
4. Add only the detail and material behavior required by the user's target.
|
|
76
|
+
Preserve real dimensions and keep randomness inside valid ranges.
|
|
77
|
+
5. Render one reference-matched view plus one off-axis or in-game-scale view.
|
|
78
|
+
Fix meaningful silhouette, proportion, attachment, and material mismatches.
|
|
79
|
+
6. Stop when the requested acceptance level is reached, then integrate the
|
|
80
|
+
factory and move its `DESIGN.md` row from `landed` to `wired`.
|
|
81
|
+
|
|
82
|
+
The output is a local TypeScript factory that returns a `THREE.Group`, for
|
|
83
|
+
example `createMarketStall(options): THREE.Group`. Give it stable defaults,
|
|
84
|
+
intentional parameters, and named parts that gameplay code can address.
|
|
85
|
+
|
|
86
|
+
Add pivots or sockets only for parts that must move or attach. Expose a
|
|
87
|
+
collider description only when gameplay needs collision, and let the game's
|
|
88
|
+
existing physics owner create the real collider. Add destruction groups only
|
|
89
|
+
for a destructible asset. A static decoration needs none of this ceremony.
|
|
90
|
+
|
|
91
|
+
## Respect existing owners
|
|
92
|
+
|
|
93
|
+
Consume the game's existing Three.js scene and runtime. Never replace or
|
|
94
|
+
silently configure its renderer, camera, lighting, shadows, post-processing,
|
|
95
|
+
physics, animation, adaptive-quality, or mobile systems. If the request grows
|
|
96
|
+
from one asset into a general mesh library, building grammar, or world
|
|
97
|
+
generator, pause and confirm that expanded deliverable instead of turning this
|
|
98
|
+
skill into a catch-all runtime.
|
|
99
|
+
|
|
100
|
+
Do not replace `$genex-ai-model`, the character or creature lanes, rigging,
|
|
101
|
+
animation, or any protected platform pipeline.
|
|
102
|
+
|
|
103
|
+
## Keep the loop proportional
|
|
104
|
+
|
|
105
|
+
The user's acceptance target controls the work. A rough background prop may
|
|
106
|
+
finish after blockout and material; a hero prop may earn more refinement.
|
|
107
|
+
Continue autonomously through unambiguous fixes and keep unrelated game work
|
|
108
|
+
moving.
|
|
109
|
+
|
|
110
|
+
Do not impose mandatory pass counts, numeric fidelity scores, review ledgers,
|
|
111
|
+
weapon-specific rules, automatic re-rolls, or user approval after every pass.
|
|
112
|
+
Ask only when a real product choice remains.
|
|
@@ -19,10 +19,6 @@ stable coordinates
|
|
|
19
19
|
→ lighting/shadow extensions
|
|
20
20
|
```
|
|
21
21
|
|
|
22
|
-
Read [references/material-systems.md](references/material-systems.md)
|
|
23
|
-
for atlas filtering, specular AA, planetary coordinates,
|
|
24
|
-
world-height wetness, per-instance dissolve, and authored PBR response bundles.
|
|
25
|
-
|
|
26
22
|
## Required controls
|
|
27
23
|
|
|
28
24
|
- real or perceptual texture scale;
|
|
@@ -47,6 +43,6 @@ world-height wetness, per-instance dissolve, and authored PBR response bundles.
|
|
|
47
43
|
|
|
48
44
|
## Routing boundary
|
|
49
45
|
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
46
|
+
Keep shared scalar/vector causes and complete world or planetary bodies in the
|
|
47
|
+
request's owning implementation. This skill owns the material response, not a
|
|
48
|
+
general field library or world generator.
|
|
@@ -141,10 +141,6 @@ Call `burst()` from the same place the game already plays the explosion sound
|
|
|
141
141
|
that call site IS the moment, and it is the proof the effect is event-driven
|
|
142
142
|
rather than ambient decoration.
|
|
143
143
|
|
|
144
|
-
Read [references/vfx-systems.md](references/vfx-systems.md)
|
|
145
|
-
for ship-conforming reentry shells, capsule wakes, dense instanced
|
|
146
|
-
spark/debris pools, HDR hierarchy, and implementation limits.
|
|
147
|
-
|
|
148
144
|
## Rules
|
|
149
145
|
|
|
150
146
|
- Every layer must have a role in silhouette, motion, illumination, or residue.
|
|
@@ -158,10 +154,9 @@ spark/debris pools, HDR hierarchy, and implementation limits.
|
|
|
158
154
|
|
|
159
155
|
## Routing boundary
|
|
160
156
|
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
and pooled debris in this skill.
|
|
157
|
+
Keep accumulated screen frost, persistent weather/surface state, and ground
|
|
158
|
+
material changes in the request's owning scene system. Impact **residue** on a
|
|
159
|
+
surface (scorch, bullet holes) is a decal — `$genex-ai-image` owns that; the
|
|
160
|
+
spark that throws the residue is this skill, and a hit usually wants both.
|
|
161
|
+
Keep ship-space plasma, generated wakes, sparks, and pooled debris in this
|
|
162
|
+
skill.
|
|
@@ -42,6 +42,5 @@ Read [references/shadow-systems.md](references/shadow-systems.md) before impleme
|
|
|
42
42
|
|
|
43
43
|
## Routing boundary
|
|
44
44
|
|
|
45
|
-
Use this skill for light-space directional shadow maps.
|
|
46
|
-
|
|
47
|
-
visibility; AO is not a replacement for cast shadows.
|
|
45
|
+
Use this skill for light-space directional shadow maps. View-dependent ambient
|
|
46
|
+
visibility is an AO concern; AO is not a replacement for cast shadows.
|
|
@@ -18,10 +18,6 @@ Evaluate the mechanism that creates the image. A beautiful hero screenshot can h
|
|
|
18
18
|
7. Record image, geometry, memory, and timing budgets.
|
|
19
19
|
8. Keep a small regression set tied to visual invariants.
|
|
20
20
|
|
|
21
|
-
Read [references/visual-validation.md](references/visual-validation.md)
|
|
22
|
-
for visual contracts, required inspection controls, mechanism-specific
|
|
23
|
-
evidence, temporal checks, budgets, and explicit rejection criteria.
|
|
24
|
-
|
|
25
21
|
## Meshy character approval evidence
|
|
26
22
|
|
|
27
23
|
Before generating a Meshy character, discuss two or three visual directions.
|
|
@@ -38,7 +38,7 @@ update, so update immediately.)
|
|
|
38
38
|
Run exactly the command the nudge printed, from the game project root:
|
|
39
39
|
|
|
40
40
|
```bash
|
|
41
|
-
npm i -D @genex-ai/cli-demo@
|
|
41
|
+
npm i -D @genex-ai/cli-demo@dev # the genex CLI (a dev dependency)
|
|
42
42
|
npm i @genex-ai/embed-sdk@latest # identity/saves SDK (ships inside the game)
|
|
43
43
|
npm i @genex-ai/multiplayer@latest # multiplayer SDK (only if the game uses it)
|
|
44
44
|
```
|
|
@@ -1,46 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: genex-threejs-atmosphere-aerial-perspective
|
|
3
|
-
description: Implement sky and aerial perspective for Genex Three.js games. Use for planetary atmospheres, ground-to-space transitions, Rayleigh/Mie-style scattering, sun and moon discs, depth-based haze, distance color, atmospheric lighting, and scale-readable outdoor scenes.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Genex Three.js Atmosphere And Aerial Perspective
|
|
7
|
-
|
|
8
|
-
**Static sky at a fixed time of day → `$genex-ai-skybox` instead** (one command,
|
|
9
|
-
a real 360° image + lighting). This skill is for dynamic, animated, or
|
|
10
|
-
scale-transitioning skies (time-of-day, ground-to-space).
|
|
11
|
-
|
|
12
|
-
Treat sky rendering and aerial perspective as two views of the same scattering model. They must share radii, density profiles, coefficients, sun direction, exposure scale, and coordinate transforms.
|
|
13
|
-
|
|
14
|
-
## Choose the implementation tier
|
|
15
|
-
|
|
16
|
-
- Small scene with no orbital camera: analytic height/distance approximation.
|
|
17
|
-
- Planetary ground-to-space camera: ray integration or precomputed LUTs.
|
|
18
|
-
- Large geospatial world: LUTs plus world-to-planet transform, altitude correction, and depth-aware aerial perspective.
|
|
19
|
-
|
|
20
|
-
Read [references/atmosphere.md](references/atmosphere.md)
|
|
21
|
-
before implementation. It separates the LUT/ellipsoid architecture from
|
|
22
|
-
dynamic integration and the shell/post handoff.
|
|
23
|
-
|
|
24
|
-
## Required outputs
|
|
25
|
-
|
|
26
|
-
- sky radiance;
|
|
27
|
-
- sun transmittance/color;
|
|
28
|
-
- segment transmittance from camera to visible surface;
|
|
29
|
-
- segment inscattering;
|
|
30
|
-
- optional sky irradiance for materials;
|
|
31
|
-
- explicit scale conversion between world units and atmosphere units.
|
|
32
|
-
|
|
33
|
-
## Failure conditions
|
|
34
|
-
|
|
35
|
-
- sky and terrain haze use different sun directions or coefficients;
|
|
36
|
-
- the atmosphere is a uniformly transparent sphere;
|
|
37
|
-
- camera altitude is measured in a local flat frame during orbital motion;
|
|
38
|
-
- scene depth is treated as linear when it is not;
|
|
39
|
-
- exposure is used to hide incorrect radiance scale;
|
|
40
|
-
- atmosphere fades abruptly at shell entry.
|
|
41
|
-
|
|
42
|
-
## Routing boundary
|
|
43
|
-
|
|
44
|
-
This skill owns molecular/aerosol sky scattering and surface-segment aerial
|
|
45
|
-
perspective. Use `$genex-threejs-volumetric-clouds` for weather-shaped cloud density,
|
|
46
|
-
temporal cloud reconstruction, and cloud shadows.
|
package/templates/skills/genex-threejs-atmosphere-aerial-perspective/references/atmosphere.md
DELETED
|
@@ -1,213 +0,0 @@
|
|
|
1
|
-
# Atmosphere system contract
|
|
2
|
-
|
|
3
|
-
Use this contract to choose between a precomputed LUT/ellipsoid atmosphere and bounded dynamic integration while keeping sky, aerial perspective, surface lighting, and coordinate transforms coherent.
|
|
4
|
-
|
|
5
|
-
## Contents
|
|
6
|
-
|
|
7
|
-
- Shared parameter model
|
|
8
|
-
- LUT atmosphere implementation LUT contract
|
|
9
|
-
- Ellipsoid and depth ownership
|
|
10
|
-
- planet-space implementation body profiles
|
|
11
|
-
- planet-space implementation integration
|
|
12
|
-
- Shell/post handoff
|
|
13
|
-
- Implementation limits
|
|
14
|
-
- Diagnostics
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
## Shared parameter model
|
|
18
|
-
|
|
19
|
-
`LUT atmosphere implementation` keeps one atmosphere object for sky and aerial perspective.
|
|
20
|
-
Earth-like defaults:
|
|
21
|
-
|
|
22
|
-
```text
|
|
23
|
-
solar irradiance = (1.474, 1.8504, 1.91198)
|
|
24
|
-
sun angular radius = 0.004675 rad
|
|
25
|
-
bottom radius = 6,360,000 m
|
|
26
|
-
top radius = 6,420,000 m
|
|
27
|
-
Rayleigh scattering = (0.005802, 0.013558, 0.0331)
|
|
28
|
-
Mie scattering = (0.003996, 0.003996, 0.003996)
|
|
29
|
-
Mie extinction = (0.00444, 0.00444, 0.00444)
|
|
30
|
-
Mie phase g = 0.8
|
|
31
|
-
absorption extinction = (0.00065, 0.001881, 0.000085)
|
|
32
|
-
ground albedo = 0.1
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
Density profiles are two-layer functions:
|
|
36
|
-
|
|
37
|
-
```text
|
|
38
|
-
density(h) =
|
|
39
|
-
clamp(
|
|
40
|
-
expTerm * exp(expScale * h)
|
|
41
|
-
+ linearTerm * h
|
|
42
|
-
+ constantTerm,
|
|
43
|
-
0,
|
|
44
|
-
1
|
|
45
|
-
)
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
The default Rayleigh exponential scale is `-0.125`, Mie `-0.833333`.
|
|
49
|
-
Absorption uses two linear layers centered around the ozone region rather than
|
|
50
|
-
another ground-heavy exponential.
|
|
51
|
-
|
|
52
|
-
One explicit meter-to-render-unit conversion is applied when parameters become
|
|
53
|
-
uniforms. Preserve this single conversion boundary.
|
|
54
|
-
|
|
55
|
-
## LUT atmosphere implementation LUT contract
|
|
56
|
-
|
|
57
|
-
The sky material and aerial-perspective effect consume the same:
|
|
58
|
-
|
|
59
|
-
```text
|
|
60
|
-
transmittance texture
|
|
61
|
-
scattering 3D texture
|
|
62
|
-
irradiance texture
|
|
63
|
-
optional single-Mie and higher-order scattering textures
|
|
64
|
-
atmosphere parameters
|
|
65
|
-
sun direction
|
|
66
|
-
```
|
|
67
|
-
|
|
68
|
-
The sky material reconstructs rays from inverse projection and inverse view
|
|
69
|
-
matrices. It can render sun, moon, ground, and shadow-length integration.
|
|
70
|
-
|
|
71
|
-
The aerial-perspective effect owns:
|
|
72
|
-
|
|
73
|
-
```text
|
|
74
|
-
camera projection/view and inverses
|
|
75
|
-
camera world position
|
|
76
|
-
depth
|
|
77
|
-
optional normal buffer
|
|
78
|
-
ellipsoid radii
|
|
79
|
-
world-to-ECEF transform
|
|
80
|
-
altitude correction
|
|
81
|
-
geometric-error correction
|
|
82
|
-
overlay/cloud shadow/light-mask inputs
|
|
83
|
-
```
|
|
84
|
-
|
|
85
|
-
Default composition enables segment transmittance and inscatter. Direct sun
|
|
86
|
-
light and sky-light relighting are separate switches. Do not collapse these
|
|
87
|
-
signals into one fog color.
|
|
88
|
-
|
|
89
|
-
## Ellipsoid and depth ownership
|
|
90
|
-
|
|
91
|
-
The geospatial path defaults to `Ellipsoid.WGS84` and can correct both
|
|
92
|
-
camera altitude and geometry error. Atmosphere altitude is therefore not
|
|
93
|
-
`worldPosition.y`.
|
|
94
|
-
|
|
95
|
-
Required coordinate contract:
|
|
96
|
-
|
|
97
|
-
```text
|
|
98
|
-
world position
|
|
99
|
-
-> world-to-ECEF
|
|
100
|
-
-> ellipsoid-relative position
|
|
101
|
-
-> corrected altitude
|
|
102
|
-
-> LUT coordinates / segment scattering
|
|
103
|
-
```
|
|
104
|
-
|
|
105
|
-
The aerial effect declares depth ownership through its post-processing effect
|
|
106
|
-
attribute. It also supports octahedral normals or normal reconstruction when
|
|
107
|
-
lighting terms require orientation.
|
|
108
|
-
|
|
109
|
-
## planet-space implementation body profiles
|
|
110
|
-
|
|
111
|
-
planet-space implementation derives profiles by body kind and density. Terrestrial baseline:
|
|
112
|
-
|
|
113
|
-
```text
|
|
114
|
-
Rayleigh = (0.0058, 0.0135, 0.0331)
|
|
115
|
-
Mie scattering = (0.0022, 0.0022, 0.0022)
|
|
116
|
-
Mie extinction = (0.0032, 0.0032, 0.0032)
|
|
117
|
-
Rayleigh scale height = lerp(7.2, 10.8, normalized density) km
|
|
118
|
-
Mie scale height = lerp(0.9, 1.7, normalized density) km
|
|
119
|
-
Mie g = 0.76
|
|
120
|
-
ozone extinction = (0.00065, 0.001881, 0.000085)
|
|
121
|
-
solar intensity = 13.8
|
|
122
|
-
```
|
|
123
|
-
|
|
124
|
-
Rocky bodies reduce scattering and remove ozone. Gas/ice giants use much
|
|
125
|
-
larger scale heights and `g` around `0.80–0.82`.
|
|
126
|
-
|
|
127
|
-
The implementation enforces:
|
|
128
|
-
|
|
129
|
-
```text
|
|
130
|
-
mieExtinction[channel] >= mieScattering[channel] + 0.0001
|
|
131
|
-
g <= 0.92
|
|
132
|
-
```
|
|
133
|
-
|
|
134
|
-
This prevents negative absorption and unstable phase behavior.
|
|
135
|
-
|
|
136
|
-
## planet-space implementation integration
|
|
137
|
-
|
|
138
|
-
For each camera ray, planet-space implementation:
|
|
139
|
-
|
|
140
|
-
1. intersects the top atmosphere sphere;
|
|
141
|
-
2. clamps the segment against the surface sphere;
|
|
142
|
-
3. marches `ATMOSPHERE_VIEW_SAMPLES`;
|
|
143
|
-
4. accumulates Rayleigh, Mie, and triangular ozone depth;
|
|
144
|
-
5. at every view sample, marches a sun segment with
|
|
145
|
-
`ATMOSPHERE_LIGHT_SAMPLES`;
|
|
146
|
-
6. tests planet occlusion of the sun;
|
|
147
|
-
7. evaluates Rayleigh and anisotropic Mie phase;
|
|
148
|
-
8. returns in-scattered radiance and view transmittance.
|
|
149
|
-
|
|
150
|
-
It adds an upper-Rayleigh exponential term and fades density over the final
|
|
151
|
-
`24%` of atmosphere thickness to soften the shell edge.
|
|
152
|
-
|
|
153
|
-
The compact path includes a small multiple-scattering approximation derived
|
|
154
|
-
from `1 - transmittance`; it is not equivalent to the precomputed higher-order
|
|
155
|
-
scattering available in `LUT atmosphere implementation`.
|
|
156
|
-
|
|
157
|
-
## Shell/post handoff
|
|
158
|
-
|
|
159
|
-
planet-space implementation renders a double-sided shell and a depth-aware post path from one
|
|
160
|
-
profile. Runtime face-opacity weights avoid a hard front/back cull switch.
|
|
161
|
-
|
|
162
|
-
The post blend is based on altitude above the atmosphere top:
|
|
163
|
-
|
|
164
|
-
```text
|
|
165
|
-
entry blend near = 140 km
|
|
166
|
-
entry blend far = max(448 km, visual atmosphere height * 0.58)
|
|
167
|
-
post blend = 1 - smoothstep(near, far, altitudeFromTop)
|
|
168
|
-
```
|
|
169
|
-
|
|
170
|
-
The post path applies only where scene depth represents a surface. The shell
|
|
171
|
-
continues to own sky pixels and limb appearance.
|
|
172
|
-
|
|
173
|
-
Preserve:
|
|
174
|
-
|
|
175
|
-
```text
|
|
176
|
-
one body center and radius
|
|
177
|
-
one atmosphere profile
|
|
178
|
-
one sun direction
|
|
179
|
-
one unit conversion
|
|
180
|
-
surface-depth classification
|
|
181
|
-
continuous shell/post blend
|
|
182
|
-
```
|
|
183
|
-
|
|
184
|
-
## Implementation limits
|
|
185
|
-
|
|
186
|
-
- planet-space implementation performs nested dynamic integration and is expensive compared with
|
|
187
|
-
LUT lookup.
|
|
188
|
-
- Its atmosphere uses spheres, while `LUT atmosphere implementation` supports an ellipsoid
|
|
189
|
-
and ECEF correction.
|
|
190
|
-
- planet-space implementation’s multiple-scattering term is an artistic approximation.
|
|
191
|
-
- `LUT atmosphere implementation` is version-sensitive and built around its own
|
|
192
|
-
post-processing/coordinate utilities; adapt the architecture, not imports
|
|
193
|
-
blindly.
|
|
194
|
-
- Do not combine LUT radiance and dynamic integrated radiance at full weight.
|
|
195
|
-
Choose ownership or a validated transition.
|
|
196
|
-
|
|
197
|
-
## Diagnostics
|
|
198
|
-
|
|
199
|
-
Expose:
|
|
200
|
-
|
|
201
|
-
```text
|
|
202
|
-
planet/ECEF coordinates and corrected altitude
|
|
203
|
-
top and bottom intersections
|
|
204
|
-
Rayleigh, Mie, and absorption density
|
|
205
|
-
view and sun optical depth
|
|
206
|
-
sun visibility
|
|
207
|
-
segment transmittance
|
|
208
|
-
single and multiple scattering
|
|
209
|
-
sky versus surface depth classification
|
|
210
|
-
shell front/back opacity
|
|
211
|
-
post blend
|
|
212
|
-
LUT coordinates and texture slices
|
|
213
|
-
```
|
|
@@ -1,44 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: genex-threejs-bloom
|
|
3
|
-
description: Implement controlled HDR bloom for Genex Three.js games. Use for selective emission, glow hierarchy, bloom thresholds, multi-scale blur, material restoration, effect isolation, exposure coupling, and diagnostics where glow supports form without replacing it.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Genex Three.js Bloom
|
|
7
|
-
|
|
8
|
-
Bloom is a camera/display response to bright HDR signal. Establish scene exposure and emissive luminance before tuning blur.
|
|
9
|
-
|
|
10
|
-
## Workflow
|
|
11
|
-
|
|
12
|
-
1. Inspect pre-tone-map luminance.
|
|
13
|
-
2. Choose which scene values should bloom.
|
|
14
|
-
3. Choose a single-node or dual selective-render ownership model.
|
|
15
|
-
4. Calibrate threshold, radius, smooth width, and strength in HDR.
|
|
16
|
-
5. Restore all substituted materials transactionally for selective passes.
|
|
17
|
-
6. Composite before exposure/tone mapping.
|
|
18
|
-
7. Validate base, contribution, and final views.
|
|
19
|
-
|
|
20
|
-
Read [references/bloom.md](references/bloom.md) for the
|
|
21
|
-
HDR ordering, dual selective-bloom transaction, compact emissive hierarchy,
|
|
22
|
-
and the costs and limits of each ownership model.
|
|
23
|
-
|
|
24
|
-
Apply the material substitution/restoration ownership pattern in the
|
|
25
|
-
reference before adding selective bloom to a composed scene.
|
|
26
|
-
|
|
27
|
-
## Failure conditions
|
|
28
|
-
|
|
29
|
-
- bloom creates the only visible form of an effect;
|
|
30
|
-
- all bright materials share one arbitrary emission multiplier;
|
|
31
|
-
- threshold is tuned after tone mapping;
|
|
32
|
-
- selective bloom requires mutating scene materials every frame without restoration guarantees;
|
|
33
|
-
- transparent particles disappear from extraction because pass ownership is unclear;
|
|
34
|
-
- bloom radius changes wildly with resolution;
|
|
35
|
-
- highlights become gray because energy is clamped too early;
|
|
36
|
-
- bloom ships un-tiered: phone tiers run the light post level
|
|
37
|
-
(`$genex-threejs-adaptive-quality`) — bloom is a desktop-tier pass, and its
|
|
38
|
-
full-res HDR target is exactly the allocation phones get killed for.
|
|
39
|
-
|
|
40
|
-
## Routing boundary
|
|
41
|
-
|
|
42
|
-
Use `$genex-threejs-exposure-color-grading` for metering, adaptation, tone mapping,
|
|
43
|
-
and LUTs. Load `$genex-threejs-image-pipeline` only when bloom must be composed with
|
|
44
|
-
several shared image-space systems.
|