# Task: Camera Preset Consistency Audit

## Objective
Stress test camera preset switching with 3 presets and verify reliability under repeated and rapid switching, focus/target consistency, transition behavior, and final state correctness.

## Vanilla three.js
-Possible: Yes
-Reliability verdict: Reliable
-Notes:
  - Code uses one `PerspectiveCamera`, a fixed `target` vector, and three preset positions (`front`, `side`, `topAngled`).
  - Repeated switching is reliable because each switch only updates `desiredPosition`; no competing camera instances.
  - Rapid switching is predictable: latest click/key wins, and camera lerps toward that final preset.
  - Focus is consistent because `camera.lookAt(target)` runs every frame.
  - Transition is smooth (`lerp` with factor `0.08`).
  - Final camera state matches the selected preset in practice (converges over frames; not mathematically exact in one frame due to lerp).
-Key concepts:
  - Preset map
  - Single camera state machine
  - Frame-loop interpolation
  - Deterministic target locking
-Complexity: Medium

## R3F
-Possible: Yes
-Reliability verdict: Reliable
-Notes:
  - Uses React state (`preset`) with a `CameraController` that updates camera in `useFrame`.
  - Repeated and fast switching stay stable because only one active preset state is used at a time.
  - Focus is predictable (`camera.lookAt(target)` each frame).
  - Transitions are smooth and consistent (same lerp strategy as vanilla).
  - Final state converges to whichever preset was selected last.
-What R3F abstracted:
  - Input/state separation from camera movement logic
  - Render-loop integration via `useFrame`
  - Cleaner UI-to-camera flow with less manual wiring
-Complexity: Easy

## Thob Page Builder
-Possible: Partial
-Reliability verdict: Partially Reliable
-Notes:
  - I found two ways to approach this.
  - Way 1 (reliable workaround): I built 3 individual meshes/scenes with one perspective camera per setup and fixed positions, then toggled mesh visibility with radio buttons. This worked consistently.
  - Way 2 (direct preset intent, unreliable): I tried one mesh/geometry with 3 perspective cameras and toggled `Make Default` with radio buttons. This was unreliable.
  - Observed behavior in Way 2:
    - Sometimes works once, then does not appear after 1-2 toggles.
    - Sometimes appears only at certain positions and fails at others.
    - Final camera state is not always the expected selected preset.
  - Conclusion: direct multi-camera preset switching feels fragile in current builder flow; multi-mesh visibility toggle is a workaround, not true camera-preset reliability.
-Builder steps:
  1. Built three separate mesh setups with one camera and fixed positions.
  2. Added radio buttons to toggle visibility and verified stable behavior.
  3. Rebuilt as single mesh + three cameras.
  4. Tried toggling camera `Make Default` via radio buttons.
  5. Stress tested repeated and fast toggles, then observed instability.
-Complexity: Hard

## Comparison Summary
-Possible in all 3? Partial
-Main differences:
  - Vanilla/R3F keep one camera pipeline and update only target position.
  - Thob direct multi-camera default switching can become inconsistent under rapid toggles.
  - Thob workaround (visibility switching) can look stable but does not validate true camera preset authoring reliability.
-Where Thob is better:
  - Fast visual assembly and no-code experimentation.
-Where Thob is weaker:
  - Camera state authoring clarity.
  - Deterministic behavior when switching default camera repeatedly.
-What feels awkward or unclear:
  - How radio/button interactions should safely control camera default state and final active camera.

## Use Case Suitability
-Product inspection: Vanilla/R3F = good. Thob = partial (workaround possible, direct camera preset flow unreliable).
-Guided tours: Vanilla/R3F = good. Thob = partial to fragile if relying on rapid camera default switching.
-Storytelling: Vanilla/R3F = good. Thob = partial for simple flows, risky for frequent camera jumps.

## Limitation Type (if any)
-[x] Editor UX limitation
-[x] Runtime limitation
-[ ] Schema / data model limitation
-[x] Component limitation
-[x] Event system limitation
-[ ] Asset pipeline limitation
-[ ] Unknown / needs investigation

## Workaround
-Is there a workaround?
  - Yes, partial workaround.
-If yes, what is it?
  - Build separate meshes/scenes and toggle visibility with radio buttons while keeping camera setup simple per view.
  - This gives stable visual switching but is not the same as robust camera preset switching on one shared scene/camera model.

## Suggested Improvement
-What should improve in Thob?
  - Add first-class camera preset authoring (preset list with position + target/focus).
  - Add one explicit "switch to preset" action for buttons/radios.
  - Ensure deterministic final state when interactions fire quickly.
  - Improve `Make Default` behavior and lifecycle when multiple cameras exist.
  - Show active camera and target/focus clearly in editor and runtime inspector.
-Is it:
  - editor
  - runtime
  - component
  - UX

## Difficulty Estimate
-Hard

## Business Value
-High

## Recommendation
Yes, Thob should support this better. Camera preset reliability is critical for product inspection, guided tours, and storytelling, and current direct multi-camera switching behavior is not predictable enough for production confidence.