RFC-014 — Tiangong Explorer · 3D model pipeline & module pickability
Orrery · Open RFC · v0.1 · May 2026
Status: Draft Author: product Closes into: ADR-048 (model source + asset pipeline), ADR-049 (module-pick strategy + LOD), ADR-050 (low-end-device fallback) Slice gate: v0.5 Why this is an RFC: PRD-011 promises a rotatable 3D Tiangong where every module is clickable, panelled, and historically attributed — the same playbook as
/iss. The technical questions cluster the same way: model source (no NASA-3D Resources analogue is available for Tiangong because of the US Wolf Amendment, so the pipeline diverges from RFC-013 here), picking (mesh-per-pressurised-module + Chinarm; trusses are minimal on Tiangong so the truss-merge complexity from/issis reduced), and fallback (the?view=list+ heuristic auto-fallback pattern from ADR-042 should port cleanly).
Context
Tiangong is China's modular space station, fully assembled October 2022, continuously crewed since June 2022. Compared to ISS:
| ISS | Tiangong | |
|---|---|---|
| Pressurised modules | 17 | 3 (Tianhe / Wentian / Mengtian) |
| Visiting vehicle types | 7 (Soyuz, Progress, Crew Dragon, Cargo Dragon, Cygnus, HTV-X, Starliner) | 2 (Shenzhou crew, Tianzhou cargo) |
| Robotic arm | Canadarm2 + JEM-RMS | Chinarm + experimental small arm |
| Solar arrays | 8 wings on outboard truss | 2 large wings per lab module (4 total) |
| Truss complex | Significant (P0–P6, S0–S6) | Minimal — modules carry their own avionics |
Tiangong is simpler than ISS to model — fewer modules, fewer visitors, less truss complexity. The work pattern from /iss (PRD-010 / RFC-013 / ADR-040–042) ports directly with proportional simplification.
The one place Tiangong is harder is asset sourcing for any future Phase-B-style GLB swap — see OQ-1.
PRD-011 wants:
- 3 pressurised modules + Chinarm individually clickable
- 2 visiting vehicles individually clickable
- Mobile-friendly, INDEX drawer co-visible
- Visually faithful to the canonical T-shape silhouette
Open Questions
OQ-1 — Where does the model come from?
ISS / RFC-013 had four candidates including NASA-3D Resources. For Tiangong:
| Option | Source | Licence | Tris budget | Authoring cost |
|---|---|---|---|---|
| A. Code-built proxy (mirrors ADR-040 V1) | Hand-built cylinders/boxes from `tiangong-modules.json` | Project-owned | ~2,000 tris | ~1 session |
| B. CMSA / CNSA-released model | Chinese state agencies sometimes release station visualisations; license terms unclear | PRC government open-content; needs vetting per ADR-046 / ADR-047 | Variable | ~1 day source + vet + cleanup |
| C. Sketchfab community model (CC-BY) | Community-authored Tiangong models | CC-BY (with attribution) | Variable | ~1 day import + cleanup |
| D. Custom Blender model from scratch | Hand-authored | Project-owned (cleanest) | Target ~10k tris | ~1 week |
| E. NASA-3D Resources | — | — | — | Unavailable. Wolf Amendment legally prohibits NASA cooperation with Chinese space programmes; no NASA-authored Tiangong models exist. |
Recommendation: A for V1, defer GLB-style swap to V1.5 / V2 via a separate RFC. The code-built proxy is faster to ship, has zero asset-sourcing risk, and produces a recognisable T-shape silhouette with very few primitives (3 cylinders + 4 wings + 1 arm). A future GLB swap can pick from B / C / D when the credits-rollout work has matured the provenance pipeline enough to vet Chinese-state imagery / models cleanly.
This locks into ADR-048 alongside the nav slot.
OQ-2 — Module pickability: mesh-per-module or pick atlas?
PRD-011 wants 3 modules + Chinarm clickable. Same architectural choices as RFC-013 OQ-2.
| Option | How it works | Tris cost | Per-module operations | Memory |
|---|---|---|---|---|
| A. Mesh-per-module | Each module is a separate THREE.Mesh in a Group; Raycaster intersects against the module list | +0 | Trivial (mesh.userData.moduleId) | One draw call per module = ~5 draw calls (3 modules + Chinarm + arrays) |
| B. Single mesh + UV pick atlas | Unified mesh + colour-coded atlas; pick by reading colour | -0 | Offscreen render on every pick | Latency hit per click |
| C. Mesh-per-module + visiting fleet pickable | Each station module + each visitor as its own pickable group | +0 | Identical to ISS visitor pipeline | ~7 draw calls (3 + arm + 2 visitors + arrays merged) |
Recommendation: C — mirror the ISS pattern exactly. The visiting fleet (Shenzhou + Tianzhou) gets userData.issPickable = true with userData.moduleId = 'shenzhou' | 'tianzhou', same shape as the ISS visitor wiring. Total ~7 draw calls is comfortably under any meaningful budget.
This locks into ADR-049.
OQ-3 — Low-end-device fallback
Identical question to RFC-013 OQ-3 / ADR-042. PRD-011 promises ?view=list plus heuristic auto-fallback (no WebGL · low memory · sustained sub-20 fps).
Recommendation: copy ADR-042 verbatim. Same detection rules, same URL override, same INDEX drawer behaviour for the 3D path.
This locks into ADR-050.
OQ-4 — Earth backdrop in V1?
Same as RFC-013 OQ-4. Static Earth limb behind the station, reusing the existing 2k_earth_daymap.jpg.
Recommendation: B (static Earth limb) — matches /iss behaviour exactly. No new assets.
OQ-5 — Chinarm separately pickable?
Tiangong's robotic arms:
- Chinarm (Space Station Remote Manipulator System / 空间站机械臂) — 10 m primary arm, base on Tianhe / Wentian. Iconic, equivalent to Canadarm2 on ISS.
- Small experimental arm (Experimental Module Manipulator) — 5 m secondary arm, attached to Wentian. Used for fine-grained payload work.
| Option | V1 scope |
|---|---|
| A. Chinarm pickable, small arm not | Mirrors ISS V1 (Canadarm2 only) |
| B. Both arms separately pickable | +1 click target |
| C. Neither pickable in V1 | Smaller scope but loses an iconic surface |
Recommendation: A for V1. Chinarm is the iconic surface; the small arm is fine as visual decoration on Wentian. Promote to B if user research surfaces curiosity about the small arm.
OQ-6 — LOD (level of detail) strategy
| Option | Cost | Benefit |
|---|---|---|
| A. Single LOD | 0 | Simplest |
| B. Two-level LOD | +1 day | Smoother low-end performance |
Recommendation: A. Tiangong's ~2,000-tri proxy is so small that LOD has no meaningful payoff. Don't optimise prematurely.
OQ-7 — Where does Tiangong sit in the nav?
Current nav (post-PRD-010): EXPLORE → MISSIONS → PLAN → FLY → EARTH → ISS → MOON → MARS.
Adding Tiangong:
- After ISS (preserves "near-Earth crewed habitats" cluster — Earth → ISS → Tiangong)
- Before ISS (treat Tiangong as the more recent station, but breaks the historical sequence)
- After MARS (treat as the tail of the catalogue)
Recommendation: After ISS. Final order: EXPLORE → MISSIONS → PLAN → FLY → EARTH → ISS → TIANGONG → MOON → MARS. Both stations sit in LEO; placing them adjacent groups the LEO-habitat cluster cleanly.
This locks into ADR-048 alongside the asset-pipeline decision.
Decision criteria
We accept the resolution when:
- The 3D scene renders ~2,000 station tris (well under any meaningful budget) at ≥ 30 fps on a baseline 2020 mobile device.
- All 3 pressurised modules + Chinarm + 2 visiting vehicles are individually pickable with no false-positives.
?view=listfallback path renders all panel content without WebGL.- Heuristic auto-fallback flips to list view without flicker on detected low-end devices.
- Earth backdrop doesn't crash low-end devices (reusing the proven
/issasset). - INDEX drawer co-visible with canvas (matching
/isspost-V1 layout, not a binary view-mode flip). - Module credits (CMSA / CNSA / Wikimedia mirrors) are recorded per ADR-046 / ADR-047.
Closure path
- ADR-048 — Asset pipeline: code-built proxy + nav slot after ISS. Earth backdrop reusing
2k_earth_daymap.jpg. Future GLB swap deferred to a separate RFC. - ADR-049 — Module pickability: mesh-per-pressurised-module + Chinarm + visiting-fleet. ~7 draw calls.
- ADR-050 — Low-end-device fallback: copies ADR-042's rules verbatim.
Multi-LOD (OQ-6 option B), small-arm pickability (OQ-5 option B), and the future Phase-B-style GLB swap all deferred to V1.5 / V2.
Orrery · RFC-014 · v0.1 · Open. Update on closure with the ADR numbers landed.