SWWheel Saga — AI Chatlog

I spotted three issues in swWheelSagaIndex.html and fixed them all in one pass:

• Stage 1 card link bug fix swWheelSagaIndex.html

  Changed stage1.html → swWheel1.html.
• Modal id mismatch bug fix swWheelSagaIndex.html

  The modal was still named swCharSagaInfoModal (carried over from the template), but the hero button already targeted swWheelSagaInfoModal, so the info button never opened anything. Both id and aria-label are now consistently swWheelSagaInfoModal.
• Modal content feature swWheelSagaIndex.html

  Replaced the generic template checklist with SWWheel-specific content: the four component classes (SWDisk, SWLine, SWPoint, SWColor) and their roles; the AI-assisted rapid development angle; and a brief saga road map.

Read both CSS files first to match the visual ecosystem precisely, then:

• Created swWheelChatlog.html feature swWheelChatlog.html (new)

  A styled chat-bubble transcript page matching the saga’s Bootstrap/Oswald theme. User messages appear in brand-gold bubbles on the right; Copilot responses in soft-indigo bubbles on the left. Each exchange includes annotation pills marking bug fixes, features, and affected files. A sticky legend at the top explains how to read the log.
• 💬 Chatlog nav link added feature swWheelSagaIndex.html

  Added a 💬 Chatlog link to the nav bar so learners can jump directly to the transcript from the index page.

Teaching note: This chatlog itself is a live artifact — every future exchange will be appended here, so learners see the complete arc of AI-assisted development from first prompt to finished class.

Three files changed — the SWWheel class is live on the canvas.

• SWWheel class new file shapeClasses/swWheel.js

  Wagon-wheel composed of two SWDisk objects (hub + rim) and an SWLine[] spoke array. Key methods: rotate(degPerSec, t), breathe(sinusoid, t), reset(), plus a full suite of setters. Draw order: rim → spokes → hub.
• Sketch rewritten rewrite sketches/swWheel1Sketch.js

  Wheel placed at the grid origin; tElapsed accumulates deltaTime each frame (capped at 100 ms) so pause/resume is seamless. Start → loop(); Pause → noLoop(); Reset zeros tElapsed and calls wheel.reset(). wireWheelControls() wires all 11 panel controls.
• HTML updated feature swWheel1.html

  Four changes in one pass: (1) swWheel.js script tag added; (2) 🎡 Wheel card with 11 controls (radius, hub, spokes, weights, three color pickers, rotation speed, breathe toggle + period); (3) modal back-link fixed (swSagaIndex.html → swWheelSagaIndex.html) and body updated; (4) 💬 Chatlog nav link added.

Design note: Positive wheelDegPerSec is CCW in user space (CW on screen). Spokes are repositioned by recomputing ptB each frame via _repositionSpokes(), avoiding floating-point drift.

Read the slider value= attributes directly from the HTML, then updated the wheel constructor in setup() to match:

• Constructor defaults synced update sketches/swWheel1Sketch.js

  Four properties read from the HTML slider value= attributes and matched in setup(). The hubRadius, colors, rotation speed, and breathe period were unchanged and left as-is. The slider max for both weight controls was also bumped: 8→16.

  property	was		now
  outerRadius	80	→	120
  numSpokes	8	→	10
  spokeThickness	2	→	8
  rimThickness	3	→	8

Four changes across three files, all in one pass.

• Background color applies immediately bug fix sketches/swWheel1Sketch.js

  syncBg() now calls redraw() when paused, so color and opacity changes are visible without needing to press Start.
• Modal id mismatch fixed bug fix swWheel1.html

  The modal still had the template id swSagaTemplateInfoModal, but the hero button targeted #swWheelSagaInfoModal, so the info button never opened. Both now align on swWheelSagaInfoModal.
• Modals updated feature swWheel1.html swWheelSagaIndex.html

  Stage 1 modal gets a new title (“🎡 Stage 1 — SWWheel”) and the screenshot at the top of the body. Index modal road map now shows Stage 1 with a green complete! badge.
• Stage 1 card gets the screenshot feature swWheelSagaIndex.html

  Replaced the emoji-gradient placeholder with swWheel1_2026-03-25T18-57-14.png; image link now navigates to swWheel1.html.

You’re right — Turn 3 was generated with a completely different set of class names (chat-row, chat-bubble, chat-avatar) that don’t exist in the stylesheet, while Turns 1 & 2 used the correct msg-row / avatar / bubble / change-list / annotation pattern. Fixed, and the missing turns appended:

• Turn 3 re-structured style fix swWheelChatlog.html

  Rebuilt using msg-row, avatar, sender-label, bubble, change-list, and annotation subclasses to match Turns 1 & 2 exactly.
• Turns 4, 5 & 6 added feature swWheelChatlog.html

  All three new exchanges documented in the same consistent msg-row / bubble / change-list style.

Teaching note: The index modal was already up to date (Stage 1 road-map entry shows the green “complete!” badge) so no further changes were needed there.

Two small changes to support a zero-weight (invisible) rim.

• Rim slider min lowered to zero feature swWheel1.html

  Changed rimThickSlider min from 1 → 0 so the control can reach zero.
• Rim draw guarded at zero weight feature shapeClasses/swWheel.js

  Added if (this.rimThickness > 0) guards in both draw() and drawOnGrid(), so the rim annulus is simply skipped rather than drawn at a “zero” stroke width.

Restructured all AI bubbles for a cleaner single-column layout.

• New two-row item layout style swWheelChatlog.html

  Added .change-header (flex row: bold title + annotation pills) and .change-detail (indented description with a soft left border) CSS rules. Each change-list item now wraps its content in a single <div>, cleanly separating the title line from the descriptive prose below.
• Turn 4 value table style swWheelChatlog.html

  The “Constructor defaults synced” item replaced its inline property 80→120, … run with a .value-table showing each property, its old value, and its new value in a scannable tabular layout.

Having just built and debugged SWWheel from the inside, here is an honest assessment. The short version: the component approach was the right call for a teaching context, but it carries real costs that Stage 2 should think about deliberately.

▲ Pros

• Zero raw p5 boilerplate inside SWWheel

  Every fill, stroke, push/pop, and coordinate transform lives inside SWDisk and SWLine. SWWheel.draw() is three lines — rim, spokes loop, hub. That is a remarkable ratio of behavior to code.
• Grid-coordinate drawing came for free

  Because SWDisk and SWLine both know about SWGrid, drawOnGrid() required no extra math in SWWheel — just delegate to each component. A from-scratch wheel would have needed manual coordinate mapping throughout.
• SWColor is a genuine accelerator

  Passing one SWColor object through the constructor wired up the hub, rim, and spokes consistently. The HSB model also made the color pickers in the control panel trivial to hook up. Without SWColor, the sketch would be managing naked hue/saturation/value variables everywhere.
• Rapid AI development was genuinely faster

  Because the SketchWave components were already known to the AI as a consistent, documented API, Stage 1 went from prompt to working, animated wheel with 11 UI controls in a single exchange. Building raw p5 from scratch would have required at least 2–3 more back-and-forth turns.
• Pedagogical transparency

  Students reading swWheel.js can see plainly that a wheel is a hub + rim + spokes because each part is named as its class. The composition pattern teaches object thinking at the same time as it teaches drawing.

▼ Cons

• Spoke repositioning is redundant work

  Every animation frame, _repositionSpokes() writes into spoke.ptA.x/y and spoke.ptB.x/y of each SWLine object, which then internally re-reads those same coordinates to draw. A native implementation would just compute the angle and call line() directly — no intermediate objects, no property writes. At low spoke counts it doesn’t matter; at high counts or many wheels it adds up.
• SWDisk carries features SWWheel doesn’t need

  SWDisk tracks shouldShowCenter, shouldShowRadius, and other display flags that SWWheel immediately sets to false and never touches again. The component is slightly over-specified for this role. This is the classic “square peg, round hole” cost of general-purpose components.
• setStrokeWeight lives on SWDisk only through a custom setter — API surface is uneven

  To change rim thickness, SWWheel calls rim.setStrokeWeight(), but for spokes it writes directly to spoke.thickness. That inconsistency (method vs. property) leaked out of the underlying components into SWWheel’s setters, making the code slightly harder to read and potentially fragile if SWLine ever encapsulates thickness behind a setter.
• Color copying has a footgun

  setSpokeColor() calls SWColor.copy(swColor) for each spoke to prevent aliasing, but the other setters (setRimColor, setHubFillColor) pass the reference directly. If a caller mutates a shared SWColor instance, some parts of the wheel update unexpectedly while others do not. This class of bug is invisible until it bites.

Bottom line: For a single, screen-sized wheel in a teaching context the component approach is a clear win — readability, rapid development, and grid-coordinate support all outweigh the overhead. Stage 2 should watch two things: (1) if we add many wheels or drive spoke counts high, benchmark and consider a native draw path as an alternative; and (2) harden SWColor handling to copy-on-assign everywhere so the aliasing footgun is eliminated before it appears in student code.

A footgun is programmer slang for a feature or pattern that makes it easy to accidentally hurt yourself — as in, “a gun you can easily shoot yourself in the foot with.” The code looks perfectly reasonable on the surface, nothing warns you, and yet a completely natural thing to do produces a subtle bug.

Here is exactly what the footgun looks like in SWWheel:

// Create one SWColor and hand it to the wheel
const rimCol = new SWColor(120, 80, 90);   // green-ish
wheel.setRimColor(rimCol);

// Later, somewhere else in the sketch …
rimCol.setHue(0);   // "I just want to make this variable red now"

// RESULT: the wheel's rim is now red — but you never called setRimColor again.
// The wheel holds a reference to the SAME object, not a copy.

Now compare that to spokes, which do copy:

const spokeCol = new SWColor(200, 60, 95);
wheel.setSpokeColor(spokeCol);   // ← internally calls SWColor.copy() for each spoke

spokeCol.setHue(0);   // mutate the original
// RESULT: spokes are UNAFFECTED — they own separate copies.
// Rim and hub would have changed; spokes would not.

The footgun is not the mutation itself — mutation is normal. The footgun is the inconsistency: half the wheel defends against it and half does not. A student who stumbles into this will see the rim color changing unpredictably while the spokes hold steady, and tracing that back to an aliased reference is genuinely hard to debug.

The fix is simple and should be applied uniformly before Stage 2 code starts passing SWColor objects around:

// In every setter that accepts an SWColor, copy on arrival:
setRimColor(swColor) {
    this.rimColor = swColor ? SWColor.copy(swColor) : undefined;
    this.rim.setStrokeColor(this.rimColor ? SWColor.copy(this.rimColor) : undefined);
    this.hub.setStrokeColor(this.rimColor ? SWColor.copy(this.rimColor) : undefined);
}

// Rule of thumb: if you store it OR forward it, copy it.

Teaching note: This kind of bug belongs to a broader family called aliasing errors or reference vs. value confusion. JavaScript passes objects by reference, not by value, so two variables can silently point to the same data. Defensive copying (“copy on intake”) is one of the core patterns for making classes safe to use. The rule is easy to state: if a class stores something mutable, it should own its own copy.

Two files changed, three setters hardened. Both cons from the Stage 1 review are now closed.

• SWLine gets setThickness(w) feature shapeClasses/swLine.js

  Added a proper setter method so SWLine now matches the setter-based API that SWDisk already used. setSpokeThickness() in SWWheel is updated to call spoke.setThickness(w) instead of writing spoke.thickness = w directly. If SWLine ever encapsulates thickness behind validation logic in the future, callers will automatically benefit.
• Color footgun eliminated — copy-on-intake everywhere bug fix shapeClasses/swWheel.js

  All three color setters now follow the same rule: copy on intake, forward a fresh copy.

  setter	stored ref before	stored ref now	forwarded copy before	forwarded copy now
  setSpokeColor	raw ref	copy	copy ✓	copy of copy ✓
  setRimColor	raw ref	copy	copy ✓	copy of copy ✓
  setHubFillColor	raw ref	copy	raw ref ✗	copy of copy ✓

  Each setter now reads: this.xColor = swColor ? SWColor.copy(swColor) : undefined then forwards SWColor.copy(this.xColor) to the component. No mutation of the caller’s original object can ever silently reach inside the wheel.

Teaching note: The pattern “copy on intake, forward a copy” is sometimes called defensive copying. It is the standard remedy for the aliasing footgun. Once you adopt it consistently in every setter that accepts a mutable object, the entire class becomes caller-proof — it can never be broken from the outside by ordinary code. The extra SWColor.copy() calls are cheap and the safety guarantee is permanent.

As a teacher, I would optimise for one thing above all else: maximum payoff per new concept introduced. Stage 1 gave students a working animated object and full UI control. Stage 2 should extend that success, not restart it. Here are the three directions I’d prioritise, in order:

• 1. The Rolling Wheel highest priority math ↔ code bridge

  A wheel that rolls without slipping along a surface is one of the most satisfying visual proofs in high school mathematics. The constraint is elegant:

  horizontal velocity = angular velocity × radius   (v = ωr)

  Coding this requires students to connect two things they already have — rotate() and a moving center point — so the code delta is small while the conceptual moment is large. When they see a wheel rolling cleanly without sliding, the formula stops being abstract. This is the most reliable “aha” moment I know of in creative coding.

• 2. Multiple Wheels in a Scene high priority OOP scaling

  Once a student can make one wheel, they need to discover the most important scaling skill in object-oriented programming: if one object is good, an array of objects is better. A bicycle (two rolling wheels + a frame), a cart, a ferris wheel with gondolas — any scene with two or more coordinated wheels forces students to confront:

  • how to manage a collection of objects
  • how to coordinate their positions and speeds
  • z-ordering (what draws on top of what)
  • why defensive copying matters — a shared SWColor aliasing bug would immediately break two wheels at once, making the footgun visible rather than hypothetical

  This stage also naturally introduces a scene object or at least a clear drawScene() / updateScene() separation — concepts students will use in every future project.

• 3. Mouse / Touch Interaction high engagement event handling

  Students who can grab their wheel and interact with it feel genuine ownership over the code. Even a simple click-to-spin or drag-to-move triggers more investment than any passive animation. Concrete ideas in rough order of complexity:

  • Click to toggle spin direction — trivial, immediate payoff
  • Mouse proximity speeds up nearest wheel — teaches distance calculations
  • Drag to reposition — teaches hit-testing and delta tracking
  • Flick to spin (momentum + decay) — introduces the idea of friction as a multiplier applied each frame

  This is the stage I’d save for last in Stage 2, because it works best once there is more than one wheel to interact with.

• (Stage 3) Inheritance — SWFerrisWheel, SWPinwheel save for later

  Extending SWWheel via extends / super() into specialised subclasses is the natural next step after students have the composition pattern solid. Introducing it too early muddies the “composition vs. inheritance” lesson — a distinction that trips up even experienced developers. Let Stage 2 deepen composition; let Stage 3 introduce inheritance as a deliberate contrast.

Suggested Stage 2 sequence: Rolling wheel → Multiple wheels in a scene → Mouse interaction. Each step adds exactly one new concept while the visual fun compounds. What directions were you thinking?

Heard of it — and I think it’s the best possible choice for Stage 2. Let me take both ideas in turn.

• Troxler’s Effect — what it is and why it works neuroscience + code

  Described by Swiss physician Ignaz Paul Vital Troxler in 1804: when you hold your gaze on a fixed central point, stationary stimuli in the periphery gradually fade and vanish, then snap back when your eyes move. The mechanism is neural adaptation — peripheral neurons that receive a constant, unchanging signal stop reporting it. The brain interprets silence as “nothing there” and fills the region with the surrounding background color.

  The effect is strongest when the peripheral shapes are:

  • low contrast against the background
  • soft-edged or blurry
  • genuinely stationary (no jitter or drift)

  A grid of faint, thin-spoked plus signs on a near-matching background is close to ideal. Students will stare at a central dot, watch the plus signs vanish one by one, then blink and watch them reappear instantly. That experience is unforgettable as a classroom moment.

• SWCross as a subclass of SWWheel inheritance, perfectly timed

  I suggested deferring inheritance to Stage 3 as a contrast to composition — but SWCross is actually the ideal first inheritance example, precisely because it introduces the concept while adding almost no new complexity:

  • The constructor is a single super() call with hard-wired defaults: numSpokes:4, rimThickness:0, hubRadius:0.
  • No methods need to be overridden. draw(), drawOnGrid(), rotate(), breathe() all inherit silently.
  • The visual result — a cross shape — is dramatically different from the parent wheel, which makes the power of inheritance visible rather than theoretical.

  This gives students a genuine “I changed one line and got a completely different shape” moment. Save the deeper inheritance discussion (method overrides, polymorphism) for when the second subclass arrives.

• The grid of SWCross instances OOP scaling

  This is also where the “array of objects” lesson from Turn 12 arrives naturally. A uniformly spaced grid fits into a nested loop:

  for (let row = 0; row < ROWS; row++) {
    for (let col = 0; col < COLS; col++) {
      signs.push(new SWCross({ center: new SWPoint(col*gap, row*gap), … }));
    }
  }

  To maximise the effect: low-opacity spoke color close to the background hue, thin spoke weight (1–2 px), a solid central fixation dot, and a text prompt telling the viewer where to stare. A subtle slow rotation added to each sign can enhance fading by teasing peripheral neurons without breaking fixation.

• swWheelReference.html documentation

  A reference guide is the right investment to make before Stage 2 writing begins, not after. Once SWWheel’s API is documented clearly — constructor options table, method signatures, a live mini-canvas showing each setter in action — students (and the AI) have a single authoritative source to consult as the subclasses grow. Building SWCross right after the reference is done means the reference immediately has a concrete “see also: subclass” example to point to.

Suggested Stage 2 order: swWheelReference.html → SWCross extends SWWheel → Troxler’s Effect grid sketch → rolling wheel. The reference pays dividends immediately; the plus sign delivers the inheritance lesson cheaply; the Troxler grid is the “wow” moment that makes the whole saga shareable. The rolling wheel stays the strongest finishing demonstration of v = ωr.

Created swWheelReference.html — a seven-section class reference guide with live source viewing and one-click copy.

• New file — swWheelReference.html new file

  A standalone reference guide for the SWWheel class structured in seven sections linked by a sticky quick-nav pill bar at the top of the content area.

  Section	What it covers
  1 — Overview	Component-composition diagram, design rationale, and key constraints (e.g., min-spoke 2 guard, defense copying on all color setters)
  2 — Dependencies	Table of all five internal objects (SWDisk, SWLine × spokes, SWColor × 3) with the script tag required for each
  3 — Constructor	Two-column options table (name / type / default / notes) plus a highlighted note about defensive copying on color intake
  4 — Properties	All public readable properties with type, access mode (read-only vs. use setter), and live default
  5 — Methods	Four subsections: Drawing & Animation, Setters, Utility, and Private helpers — each with signature, return type, and description
  6 — Examples	Five annotated code snippets: minimal wheel, custom colors + rotation, breathing (radius animation), invisible-rim plus sign, and UI slider wiring
  7 — Source Code	Live fetch('shapeClasses/swWheel.js') loads the actual file at runtime into a scrollable dark-themed viewer; a Copy Source button writes the full text to the clipboard with “✓ Copied!” / “⚠ Failed” feedback that auto-resets after 2.2 s

  The nav bar on all four project pages (swWheelSagaIndex, swWheel1, swWheelChatlog, and the reference itself) now includes a 📖 Reference link inserted before the 💬 Chatlog link.

Built all three files. Here are the key design decisions:

• SWCross extends SWWheel inheritance

  The constructor calls super() with three hard-wired constraints: numSpokes:4, rimThickness:0, and hubFillColor:null / rimColor:null (invisible hub and rim outline). Everything else — drawOnGrid(), breathe(), all the setters — inherits silently from SWWheel.

  numSpokes is not a constructor option — it is locked at 4 so students cannot accidentally produce a 3- or 5-armed shape while exploring the controls.

• initialRotation — baked into rotate() new property

  rotate(degPerSec, t) is overridden to:

  this.rotationAngle = this.initialRotation + degPerSec * t;

  At t = 0 the arms rest at the pre-tilt angle. reset() is also overridden to return to initialRotation (not 0). The live setter setInitialRotation(deg) repositions arms immediately; the sketch resets tElapsed = 0 so animation restarts cleanly from the new base angle.

• Files created 3 new files

  shapeClasses/SWCross.js

  Class with locked constraints, overridden rotate() and reset(), and new setInitialRotation().

  sketches/swCross1Sketch.js

  Full sketch wiring arm length, weight, color, initial rotation, rotation speed, breathe, and breathe period controls.

  swCross1.html

  Stage 2 app page with full control panel, nav links, and an info modal previewing Stage 3 Troxler’s Effect.

Great catch — and a perfect teachable moment about p5.js global state.

• Why the tips were rounded — p5 global state p5.js gotcha

  p5.js defaults strokeCap(ROUND) globally. SWLine never called strokeCap() at all, so it silently inherited whatever cap state p5 happened to have at draw time — and that default is ROUND. The fix requires understanding that strokeCap() is global state, not per-object state.

  Analogy: it’s like a shared pen whose tip shape you have to set before each use, because whoever drew last might have left it in a different mode.

• capStyle added to SWLine new property

  Added this.capStyle = 'ROUND' to the SWLine constructor (preserving existing behavior as the default). Both draw() and drawOnGrid() now bracket the line() call:

  strokeCap(window[this.capStyle] ?? ROUND);
  line(x1, y1, x2, y2);
  strokeCap(ROUND);   // restore default

  The window[this.capStyle] ?? ROUND pattern resolves a string like 'SQUARE' to the actual p5 constant at draw time, without needing p5 globals to be available when the class is first defined.

• setSpokeCapStyle() on SWWheel; SQUARE default for SWCross setter + subclass default

  SWWheel.setSpokeCapStyle(cap) propagates the cap string to every spoke via spoke.setStrokeCap(cap). SWCross’s constructor ends with this.setSpokeCapStyle('SQUARE') — flat tips look significantly cleaner for a geometric crosshair.

  A dropdown (Round / Flat square / Projected) was added to the swCross1.html control panel so students can compare all three visually with a thick stroke weight.

Done. Updated four locations across three files:

• swCross1.html HTML controls

  Arm weight slider value="5" → value="25"; arm color picker value="#1a1066" → value="#ff0000".
• swCross1Sketch.js sketch init

  spokeThickness: 5 → 25; color '#1a1066' → '#ff0000' in the SWCross constructor call.
• SWCross.js class defaults

  JSDoc comment default note and constructor destructured default: spokeThickness = 5 → 25.

All five pieces are in place:

• swWheelSagaIndex.html — Stage 2 card wired

  The placeholder Card 2 was replaced with a real SWCross card: screenshot thumbnail, description mentioning inheritance and initialRotation, and a link to swCross1.html. The index modal road map now shows Stage 2 as complete and previews Stage 3 Troxler’s Effect.
• swCrossReference.html new file

  Nine-section reference guide for SWCross, modeled on swWheelReference.html:

  • Overview + inheritance ASCII diagram
  • Inheritance table (locked / overridden / new)
  • Dependencies (adds swWheel.js)
  • Constructor options + locked values tables
  • Properties (inherited + new)
  • Methods (overrides, new setter, inherited)
  • Cap Styles section — explains p5 strokeCap() global state, the window[cap]??ROUND pattern, and all three options side-by-side
  • Six annotated usage examples
  • Live source viewer with copy button (fetches SWCross.js)
• swCross1.html — modal + nav updated caps discussion

  The info modal now includes a p5.js Global State: strokeCap() section explaining why tips can look rounded, what the three cap options do, and why SWCross defaults to SQUARE. The modal footer Reference button and the nav bar Reference link both now point to swCrossReference.html.
• Nav links updated across pages navigation

  Added ✚ Stage 2 nav item to swWheelChatlog.html and swWheelReference.html. Also added 🎡 Stage 1 to the chatlog nav (it was previously absent).
• Chatlog — Turns 15–18 documentation

  The Stage 2 placeholder session header was replaced with four documented turns: the SWCross build (15), cap style feature and p5 global state discussion (16), default weight/color change (17), and this documentation turn (18).

Built both files for Stage 3a.

• troxler1Sketch.js new file feature

  A 5×5 grid of SWCross instances in soft purple at low alpha (default 35/100) on a light-grey canvas. The centre cell is null — a small fixation dot drawn in screen-pixel coordinates sits there instead. buildCrossGrid() places each sign in user-space at multiples of SPACING from the origin. The right panel has sliders for arm alpha, arm length, thickness, grid spacing, rotation speed, and a colour picker. Setting rotation speed > 0 spins each sign individually, which immediately destroys the fading — a live “kill switch” for the illusion.
• troxler1.html new file

  Full-page layout following the saga pattern: Bootstrap grid, canvas column, right-panel controls, info modal explaining Troxler’s Effect and how this sketch recreates it. Loads the standard SketchWave dependency chain plus SWCross.js and troxler1Sketch.js.

Built Stage 3b — the spinning-grid variant.

• troxler2Sketch.js new file feature

  A 9×9 grid of neon-red SWCross crosshairs on a black background. A single push() / translate / rotate / translate / pop() block carries all 81 signs around the canvas centre in lock-step — the “spinning sheet of paper” technique. After pop(), three yellow dots at equilateral-triangle vertices (circumradius 220 user units) and a green fixation dot are drawn without any rotation, so they remain perfectly stationary on screen. Staring at the green dot causes the stationary yellow dots to undergo Troxler fading even while the spinning grid keeps overall stimulation high.
• troxler2.html new file

  Full-page layout, same saga pattern as troxler1. Info modal explains the key difference: the Troxler target here is the yellow dots, not the plus signs, and the “spinning sheet” canvas-transform technique is documented step-by-step for students.

Added two new cards to swWheelSagaIndex.html.

• swWheelSagaIndex.html 1 file changed feature

  Card 3a links to troxler1.html using troxler1_2026-03-26T12-42-09.png and describes the static fixation-dot grid. Card 3b links to troxler2.html using troxler2_2026-03-25T22-55-19.png and describes the 9×9 spinning-grid with yellow triangle-vertex dots. Both follow the same h-100 shadow-sm card pattern as Stages 1 and 2.

Changed object-fit from cover to contain on both Troxler card images. cover crops and fills the box; contain scales the image down until it fits entirely within the allocated height, letterboxing any leftover space in the background colour.

• swWheelSagaIndex.html 1 file changed fix

  Stage 3a: object-fit:contain; background:#e8e8e8 — light grey matches the sketch canvas so letterbox gaps are invisible. Stage 3b: object-fit:contain; background:#000000 — black matches the sketch’s dark canvas.

Updated the index modal road map and this chatlog.

• swWheelSagaIndex.html 1 file changed feature

  Road map Stage 3 entry split into two items: Stage 3a (static grid, per-sign rotation kill-switch) and Stage 3b (spinning-grid canvas-transform, yellow triangle-vertex dots), both now marked complete!
• swWheelChatlog.html 1 file changed feature

  Session 3 header added. Turns 19–23 document the builds of troxler1 and troxler2, the index card additions, the image-fit fix, and this modal/chatlog update. Nav links for Stage 3a and Stage 3b added to the chatlog navbar.

Built Stage 4 across three files.

• lingelbach1Sketch.js new file feature

  The touching-lattice illusion. buildLingelbachGrid() computes the minimum number of SWCross instances to cover the canvas with one cell of overflow on every edge using numHalf = ceil((HALF_SPAN + spacing) / spacing). Spacing is always ARM_LENGTH × 2, guaranteeing tip-to-tip contact. SQUARE stroke caps produce perfectly flat meeting points. Each sign’s centre carries a filled ellipse (the hub) whose diameter defaults to the arm stroke weight. Controls include sliders for arm length, weight, alpha, and hub size, plus color pickers for background and arm color.
• lingelbach1.html new file

  Full-page layout following the saga pattern. Info modal documents Lingelbach’s 1994 work, its relation to the Hermann grid, and the scintillating grid published by Schrauf, Lingelbach & Wist in 1997.
• swWheelSagaIndex.html 1 file changed

  Stage 4 card added (placeholder image, navy background) and Stage 4 listed in the modal road map as complete!

Applied all adjustments across both files.

• lingelbach1Sketch.js 1 file changed feature

  ARM_LENGTH → 35; ARM_THICKNESS and HUB_DIAMETER → 15. FIX_DOT_RADIUS and fixDotColor removed from variables, init, and draw(). hubColorHex wired to a color picker. Motion variables (doSpin, spinDegPerSec, doBreathe, breatheSinusoid, BREATHE_PERIOD) added. breatheSinusoid initialised in setup() with extrema at 40–160 % of ARM_LENGTH. draw() calls ps.breathe() then ps.rotate() when enabled. wireMotionControls() auto-starts the loop.
• lingelbach1.html 1 file changed

  Arm-length slider default → 35, spacing readout → 70. Arm-weight slider max → 25, default → 15. “Hub & Fixation” card replaced by “Hub Nodes” card with a hubColorPicker color input (default #FFFF00) and hub size max → 30. Motion card added: spin checkbox + speed slider (5–180°/sec), breathe checkbox + period slider (0.5–8 sec). “Try it” callout rewritten to describe the dark smudge / lateral-inhibition phenomenon.

Three targeted changes.

• lingelbach1.html 1 file changed fix

  Hub size slider min changed from 1 to 0, so dragging to the left end makes hubs fully invisible.
• lingelbach1Sketch.js 1 file changed

  ARM_COLOR_HEX declaration changed to '#237113' (dark forest green). The setup() line overwriting ARM_COLOR_HEX with swMedGreen.getHexStr() removed so the new default holds through runtime.

Updated index card, modal, and this chatlog.

• swWheelSagaIndex.html 1 file changed feature

  Stage 4 card image: placeholder <div> replaced with lingelbach1_2026-03-26T13-38-59.png (object-fit:cover). Modal road map Stage 4 entry expanded to mention hub-color picker, arm-color picker, hub-size range 0–30 px, and the Motion card (spin + breathe via SWSinusoid).
• swWheelChatlog.html 1 file changed feature

  Session 4 header added. Turns 24–27 document the Stage 4 build, the control-panel refinements, the hub/color defaults, and this index / chatlog update. Stage 4 nav link added to the chatlog navbar.

Two new sections added to the saga index modal.

• swWheelSagaIndex.html 1 file changed feature

  Added a “📖 Reference Pages” section with links to swWheelReference.html and swCrossReference.html. Added a “🛠️ Updated Supporting Classes” section documenting changes to SWPoint (draw() / drawOnGrid() defaultColor param; label helpers), SWLine (capStyle / setStrokeCap(); transform(); rotateAbout(); breatheAbout(); setThickness()), and SWColor (fromHex(); cycleParameter(); createDarkerColor() / createLighterColor() / createAdjustedSaturation(); verify() now clamps instead of throwing).

Transformed the Lingelbach copy into a proper Hermann Grid demo.

• hermann1Sketch.js 1 file changed feature

  File header updated; bgHex → '#000000' (black); ARM_THICKNESS → 20; ARM_ALPHA → 100; ARM_COLOR_HEX → '#FFFFFF' (white); HUB_DIAMETER → 0; hub initialized to swWhite; hub drawing guarded by if (HUB_DIAMETER > 0); console/save identifiers updated to hermann1Sketch / hermann1_.
• hermann1.html 1 file changed feature

  All control defaults updated: bgColorPicker #000000, armColorPicker #FFFFFF, armAlphaSlider 100, armThickSlider 20, hubSizeSlider 0. Hero subtitle, tip alert text, modal title, entire modal body (Hermann history, lateral inhibition science, controls), and modal footer button all rewritten for the Hermann Grid context.

Four targeted changes to fine-tune the Hermann defaults.

• hermann1Sketch.js 1 file changed fix

  ARM_THICKNESS default changed from 20 to 15. setSpokeCapStyle('SQUARE') changed to setSpokeCapStyle('PROJECT') in buildLingelbachGrid() — PROJECT caps extend each arm slightly past its tip so opposing arm ends overlap just enough to eliminate the faint seam at junctions.
• hermann1.html 1 file changed fix

  armThickSlider display and value updated from 20 to 15. capStyleSelect default changed from SQUARE to PROJECT.

Stage 5 card, modal road map entry, and this chatlog session all added.

• swWheelSagaIndex.html 1 file changed feature

  Stage 5 card added using hermann1_2026-03-27T14-44-58.png. Road map list extended with a Stage 5 entry describing the Hermann Grid: thick white SWCross lattice, no hubs, pure black canvas, PROJECT caps, buildLingelbachGrid() engine reuse. lastUpdate bumped to 03/27/2026.
• swWheelChatlog.html 1 file changed feature

  Session 5 header added. Turns 28–31 document the saga index modal enrichment, the Hermann Grid file transformation, the defaults fine-tuning, and this index / chatlog update. lastUpdate bumped to 03/27/2026.