smoothlife/plans/README.md

SmoothLife Rust/raylib reimplementation plan

Mission

Reimplement the legacy SmoothLife collection as one modern Rust 2024 application using raylib for the window, input, and presentation. The result is a configurable simulation laboratory, not a line-by-line port. It must expose the internal logic of every simulator through inspectable fields while preserving the documented mathematics and making legacy defects explicit rather than accidental.

This plan is implementation-oriented: execute the macrosteps in order and use each exit gate as the prerequisite for the next step. Later work should rely on the in-repository contract and tests produced by Macrostep 00, not repeatedly reopen the legacy tree.

The original source position is ~/Nextcloud/VecchiProgetti/SmoothLifeAll/

Required release scope

Legacy component	New application responsibility
SmoothLife/	Periodic 1-D, 2-D, and 3-D model; discrete/growth/relaxation dynamics; Euler, AB3, and RK4; both RK4 relaxation references; standard and legacy packed-unitary FFTs; inspection and 3-D rendering.
SmoothLifeSDL/	Subsumed by the portable raylib shell. Its one-pass Euler behavior is covered by the base Euler path, not a separate simulator.
SmoothLifeMultiscale/	Corrected three-scale 2-D growth/relaxation model, two neighborhood interpretations, three composition policies, and either GPU FFT algorithm.
SmoothLifeSphere/	Corrected sphere default plus one coherent retained legacy sphere model; both use safe deterministic resources.
SmoothLifeDT/	Periodic 2-D field with initialized 16-frame circular history and one causal radius-dependent delay policy.
FreeBasic/Matlab	Independent CPU oracles, FFT/integrator validation, and a numerical comparison tool.
GliderConstructor.bas	Optional post-v1 inverse-design tool; it is not a general simulation backend and does not block the main release.

Product principles

1. Pure core, graphical shell. The model must run headlessly without raylib. Rendering consumes snapshots and inspection channels; it does not own simulation truth.
2. CPU oracle before GPU optimization. Every GPU pass is checked against a deterministic CPU implementation.
3. One shared rule implementation. All variants use the same typed rule configuration and equivalent Rust/GLSL formulas.
4. Inspectable by design. A, M, N, target S, derivative/increment, kernels, scale outputs, history layers, and topology diagnostics are first-class channels.
5. Historical simulation behavior is exceptional and local. There is no general legacy engine or compatibility profile. Only the explicitly retained RK4 relaxation reference, packed-unitary FFT, and sphere model are selectable; all other simulation behavior follows the new deterministic design.
6. Deterministic replay and continuation. A run is identified by schema version, preset ID, seed, shape, backend, only the localized historical options relevant to that run, and step count. Restart-state files reset numerical history; exact checkpoints additionally store AB history, DT history/head, generation, and deterministic RNG state.
7. No runtime dependency on the old project. Legacy catalogues are imported once and committed in the new schema.
8. No steady-state allocation or readback. Buffers and plans are reused; GPU readback is only for tests and explicit exports.

Intended repository shape

smoothlife/
├── Cargo.toml
├── src/
│   ├── lib.rs                    # raylib-free public core
│   ├── main.rs                   # application entry point
│   ├── config/                   # schema, validation, preset library/import
│   ├── field/                    # shapes, storage, indexing, inspection data
│   ├── math/                     # curves, rules, kernels
│   ├── integration/              # discrete, Euler, AB3, RK4
│   ├── convolution/              # direct oracle and FFT implementations
│   ├── simulation/               # common commands and backend facade
│   ├── variants/                 # planar, multiscale, sphere, delayed time
│   ├── gpu/                      # isolated rlgl/OpenGL resources and passes
│   ├── app/                      # scheduler, actions, lifecycle
│   ├── render/                   # palettes, 1-D/2-D/3-D/sphere rendering
│   └── ui/                       # panels, HUD, help, notifications
├── assets/
│   ├── presets/
│   └── shaders/
├── tests/
├── benches/
└── plans/

Start as one Cargo package. Make raylib and GPU code optional behind features so cargo test --no-default-features exercises the mathematical core without a graphics context. Create a workspace only if later standalone tools justify it.

Core data flow

validated preset + deterministic initializer
                     │
                     ▼
                 state A
                     │
         topology-specific neighborhood
                     │
              M (disk), N (ring)
                     │
             common target S(N,M)
                     │
        dynamics → derivative/increment
                     │
             selected integration
                     │
             clamp and commit A'
                     │
      inspection snapshot → raylib renderer/UI

The special variants replace only the neighborhood/topology and update policy layers:

• Multiscale: several (M,N,S) pipelines plus a composition policy.
• Sphere: direct geodesic, area-weighted neighborhoods on a cube-sphere.
• Delayed time: each radial offset selects a spatially shifted history layer.

Configuration model

Use strict, versioned TOML with string enums and a tagged variant:

Preset
├── identity/provenance
├── VariantConfig
│   ├── Planar
│   ├── Multiscale
│   ├── Sphere
│   └── DelayedTime
├── RuleConfig (one or one per scale)
├── DynamicsConfig
├── InitializerConfig
└── recommended presentation

Keep model presets distinct from user preferences (window, palette, camera, key bindings). Bundled presets are immutable; user presets and captures live in platform-specific user directories.

Historical options policy

The new deterministic implementation is always the baseline: complete kernel support, initialized state, Euler → AB2 → AB3 startup, explicit ping-pong writes, corrected multiscale evaluation, causal delayed history, fixed simulation scheduling, and strict configuration validation.

Exactly three historical choices remain:

Rk4RelaxationReference
  StageState       # default: S(stage)-stage
  StepOrigin       # historical: S(stage)-state_at_step_start

FftAlgorithm
  Standard         # default: conventional normalized FFT
  LegacyPackedUnitary

SphereModel
  Corrected        # default: complete seams and sampled normalization
  Legacy           # original atlas/seam and analytic-cap model

These are independent, local settings—not a general compatibility profile. LegacyPackedUnitary retains packed real/complex storage, half-width x spectra, historical butterfly/plan stages, unitary scaling, and the matching sqrt(N)/kernel_sum correction. SphereModel::Legacy retains the original cube-atlas geometry, side-gutter/corner masking, analytic normalization, radius conversion, direct stencil, and fixed smooth update.

Even these options use safe deterministic infrastructure. The project never preserves undefined AB buffers, uninitialized textures, texture feedback loops, unclamped acos, platform rand() streams, stale multiscale fields, additive-discrete multiscale behavior, or the delayed-time head anomaly.

Delivery milestones

Milestone	Macrosteps	User-visible result
R0: frozen contract	00	All required behavior and source provenance live in this repository.
R1: first useful simulator	01–04	Deterministic CPU SmoothLife with a professional raylib 2-D workbench and inspectors.
R2: accelerated base model	05–06	CPU/GPU base parity, 1-D history, 2-D field, 3-D slices/volume, complete base presets.
R3: all historical models	07–09	Multiscale, sphere, and delayed-time backends selectable in one application.
R4: release candidate	10–11	Reference tooling, benchmarks, packaging, portability, and complete documentation.

Macrostep index

1. Macrostep 00 — Model contract and retained historical options
2. Macrostep 01 — Project foundation and configuration
3. Macrostep 02 — Mathematical core and deterministic oracles
4. Macrostep 03 — CPU planar simulation engine
5. Macrostep 04 — Raylib visualization workbench
6. Macrostep 05 — GPU resources and 2-D FFT proof
7. Macrostep 06 — Complete base solver and dimensional rendering
8. Macrostep 07 — Multiscale backend
9. Macrostep 08 — Spherical backend
10. Macrostep 09 — Delayed-time backend
11. Macrostep 10 — Reference and analysis tools
12. Macrostep 11 — Performance, portability, and release

Definition of “macrostep complete”

A macrostep is complete only when:

• every required phase is implemented;
• its tests and diagnostics pass in debug and release where relevant;
• its deliverables are committed;
• its exit gate is demonstrated, not merely asserted;
• documentation and schema examples are updated in the same change;
• unresolved deviations are recorded as explicit issues with an owner and blocking status.

Do not begin optimization before the corresponding oracle and stage-level comparisons exist.