From 2a7f7561b68ff956e9c48249fccbc3c7a25722b6 Mon Sep 17 00:00:00 2001 From: anshk Date: Mon, 13 Apr 2026 17:15:28 +0530 Subject: [PATCH] docs: week 3 task 1 docs --- Week-3/Task-1/ProductLens.md | 16 +++++- Week-3/Task-1/TaskNotes.md | 95 ++++++++++++++++++++++++++++-------- 2 files changed, 88 insertions(+), 23 deletions(-) diff --git a/Week-3/Task-1/ProductLens.md b/Week-3/Task-1/ProductLens.md index ba487ce..ed5a4ab 100644 --- a/Week-3/Task-1/ProductLens.md +++ b/Week-3/Task-1/ProductLens.md @@ -1,5 +1,17 @@ ## Product Lens -- Is this pattern useful for real customers? Yes / Partial / No +- Is this pattern useful for real customers? Yes - What kind of customer use case does this support? + - Product inspection: users switch between front/side/top detail viewpoints. + - Guided tours: sequenced camera jumps between key points of interest. + - Storytelling/marketing: deliberate framing changes to control narrative focus. - Does Thob feel strong enough for this use case? -- What would improve the experience? \ No newline at end of file + - Partial. + - From my Task 1 test, there are two ways: + - Way 1: three separate meshes/scenes with one perspective camera setup each, then toggle visibility using radio buttons. This was stable. + - Way 2: one mesh + three perspective cameras, toggling `Make Default` using radio buttons. This was unreliable (sometimes appears, then disappears after repeated toggles; sometimes works only at certain positions). + - So today, Thob is okay for workaround-based flows, but direct camera preset switching reliability is not strong enough yet. +- What would improve the experience? + - Native camera preset system with explicit position + target/focus per preset. + - Clear interaction binding: control -> target camera/preset -> action. + - Deterministic behavior under fast repeated switching. + - Better visual/debug indication of which camera is active and why. \ No newline at end of file diff --git a/Week-3/Task-1/TaskNotes.md b/Week-3/Task-1/TaskNotes.md index e8be752..1ed3f44 100644 --- a/Week-3/Task-1/TaskNotes.md +++ b/Week-3/Task-1/TaskNotes.md @@ -1,60 +1,113 @@ -# Task: [Feature Name] +# Task: Camera Preset Consistency Audit ## Objective -What is the feature trying to do? +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 / Partial / No +-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: --Complexity: Easy / Medium / Hard + - Preset map + - Single camera state machine + - Frame-loop interpolation + - Deterministic target locking +-Complexity: Medium ## R3F --Possible: Yes / Partial / No +-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: --Complexity: Easy / Medium / Hard + - 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: Yes / Partial / No +-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: --Complexity: Easy / Medium / Hard + 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? Yes / Partial / No +-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) --[ ] Editor UX limitation --[ ] Runtime limitation +-[x] Editor UX limitation +-[x] Runtime limitation -[ ] Schema / data model limitation --[ ] Component limitation --[ ] Event system 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 - -schema/data + - editor + - runtime + - component + - UX ## Difficulty Estimate --Easy / Medium / Hard +-Hard ## Business Value --Low / Medium / High +-High ## Recommendation -Should Thob support this better? Why? \ No newline at end of file +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. \ No newline at end of file