Skip to content

Engine comparison: two engines side by side with synchronised cameras and matched components #4

Description

@PouyanJay

Seven engines in one app invite the obvious question: what is actually different between a turbojet and a turbofan, or between a V8 and an inline-four? Right now the answer requires switching engines and remembering what you saw. A comparison view puts two engines next to each other with the same camera and the same component lit up in both.

What is needed

A split view showing two engines side by side, with:

  • One orbit control driving both cameras so the models stay aligned.
  • Matching components highlighted together. Selecting "Compressor" on the left highlights the compressor on the right, and the detail card explains both.
  • A shared separation slider and shared cutaway depth, so both engines explode or section together.
  • A short comparison summary per pair, for example bypass ratio, spool count, or firing order, written in plain language.
  • A way to swap either side and to leave comparison mode.

Success criteria

  • Any two of the seven engines can be compared, including across families (a turbine next to a piston engine).
  • Components are matched by a stable id map, not by list position. Where there is no counterpart (a propeller against a turbofan fan, a rotor against pistons) the card says so instead of highlighting the wrong thing.
  • Both models fit their half of the viewport at every aspect ratio, and the split stacks vertically below 900 px wide.
  • The two scenes share geometry builders; a comparison does not double the build time compared with loading the two engines one after the other.
  • The engine check runs the component matching table and asserts that every mapped id exists on both sides.
  • Memory returns to the single-engine baseline after leaving comparison mode; no leaked renderers, materials or listeners.

Suggested approach

  • The cleanest structure is one WebGL renderer with two viewports using scissor tests, each with its own scene, camera and controller. That avoids two contexts and lets both halves share the same render loop. The existing EngineScene component would need to be split into a scene instance class and a thin React wrapper; do that refactor first as its own pull request.
  • Synchronise cameras by copying the orbit target and spherical coordinates from the driven camera to the other after each control update, scaled by the ratio of the two models' bounding radii so a small rotary and a large turbofan both stay in frame.
  • Put the component matching table in lib/engine/engine-data.ts. Turbine engines already share ids (fan, compressor, combustor, turbine, nozzle, casing, shaft), and piston engines share theirs. Add an explicit cross-family map with null for no counterpart.
  • Reuse ViewerState as the shared state and add compare: { engine: EngineType } | null. The slider, cutaway, labels and quality settings then apply to both halves without new plumbing.
  • Write the pair summaries as data keyed by a sorted pair of engine keys. Seven engines give 21 pairs; start with the pairs inside each family and the two or three most instructive cross-family pairs.

Out of scope

Comparing more than two engines at once, and overlaying the two models in one viewport.

Touchpoints

components/engine/engine-scene.tsx, app/page.tsx, lib/engine/engine-data.ts, app/globals.css, scripts/check-explosion.mjs

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: sceneThree.js scene, geometry, cameras, renderingarea: uiControls, panels, layout, interactionenhancementNew feature or requestfeatureA new user-facing capabilitypriority: mediumImportant, after the high itemssize: XLMulti-week, should be split into sub-tasksv0.2.0Planned for the v0.2.0 release

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions