113 lines
5.3 KiB
Markdown
113 lines
5.3 KiB
Markdown
# 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. |