anshk/builder-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
builder-research/Week-3/Task-1/TaskNotes.md
anshk 2a7f7561b6 docs: week 3 task 1 docs
2026-04-13 17:15:28 +05:30

5.3 KiB
Raw Blame History

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.