mikemacd/rotation

1. What this repository is

- A small desktop graphics program that loads a 3D object from a data file and renders a rotating wireframe/line drawing of it.

- The current implementation is a Go rewrite of older Amiga Basic and C/X11 versions kept in the repo for historical reference.

2. Primary runtime boundary

- The app is a single native desktop executable built with Go.

- It depends on github.com/andlabs/ui for the windowing/graphics layer, so the UI is not browser-based or server-based; it is an OS-native GUI application.

3. Main Go entrypoint

- rotation.go is the central application file.

- It likely contains startup, argument parsing, model loading, rotation math, and orchestration of the render loop.

- window.go is the UI boundary, separating window creation, control wiring, and drawing surface concerns from the core rotation/model logic.

4. Data loading subsystem

- The .dat files (icosahedron.dat, cube.dat, car.dat, boat.dat, etc.) are model inputs.

- ./rotation -f <file> indicates the app selects one of these geometry files at runtime rather than embedding a single hardcoded shape.

- These files are the main external data source and define the object being drawn.

5. Rendering flow

- The data flow is: load model file → interpret vertices/edges/faces → apply rotation transforms → draw in GUI window.

- The visual output is driven by the rotation math rather than by a complex scene graph or 3D engine.

- This suggests a lightweight custom renderer focused on simple geometric transformation and line drawing.

6. Geometry/math subsystem

- The code includes the core 3D math needed for rotating an object in space.

- Based on the README, this math is implemented directly in the application rather than delegated to a modern graphics API or 3D library.

- That makes the math layer the main computation boundary in the app.

7. Command-line and configuration

- Runtime behavior is configured primarily through command-line flags, especially -f to choose the input model file.

- -h exposes help text, implying a small CLI front end wrapped around the GUI program.

8. Build and dependency management

- The project is a Go module (go.mod, go.sum) and also vendors dependencies in vendor/.

- This matters architecturally because the build is self-contained and reproducible, with external UI dependencies pinned locally.

- The README notes platform prerequisites may be required for andlabs/ui on Linux/Windows.

9. Legacy implementations

- rotation.C and rotation.AmigaBasic.BAS are not part of the active Go runtime, but they document the program’s evolution.

- They are useful for understanding the original architecture and behavior, but the current executable path is the Go code.

10. Repository shape and likely diagram boundaries

- One clear boundary is UI/rendering versus model/maths/loader:

- UI layer: window creation, event handling, drawing surface.

- Core layer: file parsing, object representation, transforms, rotation.

- Another boundary is application code versus input assets:

- executable logic in Go

- 3D object definitions in .dat files

11. What is not present

- There is no evidence of a network service, database, background worker, or multi-process architecture.

- The program appears to be a standalone interactive desktop utility with local file input and immediate graphical output.

12. In one sentence

- This repo is a small, single-process Go desktop app that reads a selected 3D object file, computes simple rotation transforms, and renders the result in a native GUI window using andlabs/ui.