From c49060e09a29eb50493c916a4928c4fbb6ed52e1 Mon Sep 17 00:00:00 2001 From: anshk Date: Tue, 7 Apr 2026 11:12:52 +0530 Subject: [PATCH] docs: task2 notes --- Week-2/Task-2/ProductLens.md | 11 +++- Week-2/Task-2/TaskNotes.md | 67 ++++++++++++++++------- Week-2/Task-2/builder/BuilderNotes.md | 77 +++++++++++++++++++++++++++ 3 files changed, 134 insertions(+), 21 deletions(-) diff --git a/Week-2/Task-2/ProductLens.md b/Week-2/Task-2/ProductLens.md index ba487ce..fa85ae6 100644 --- a/Week-2/Task-2/ProductLens.md +++ b/Week-2/Task-2/ProductLens.md @@ -1,5 +1,12 @@ ## 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? + - Guided product stories where objects appear/disappear across steps. + - Feature comparison scenes with predefined arrangements. + - Presentation flows where one click changes scene composition and framing. - Does Thob feel strong enough for this use case? -- What would improve the experience? \ No newline at end of file + - Partial. The pattern is possible by combining object visibility states and Perspective Camera positions, but button-triggered updates are not reliably synchronized. +- What would improve the experience? + - One button should update all linked properties simultaneously, or fast enough that transitions feel instant. + - Better multi-target binding UX for visibility, transforms, and camera props. + - Clearer feedback/debugging for whether each bound prop was successfully updated. \ No newline at end of file diff --git a/Week-2/Task-2/TaskNotes.md b/Week-2/Task-2/TaskNotes.md index e8be752..3d5426b 100644 --- a/Week-2/Task-2/TaskNotes.md +++ b/Week-2/Task-2/TaskNotes.md @@ -1,60 +1,89 @@ -# Task: [Feature Name] +# Task: Scene State Switching (Visibility + Transform Presets) ## Objective -What is the feature trying to do? +Switch between predefined scene states where each state controls object visibility, object transforms, and scene framing behavior. ## Vanilla three.js --Possible: Yes / Partial / No +-Possible: Yes -Notes: + - Uses a `states` map with three scene presets (`state1`, `state2`, `state3`). + - Each state defines object `position`, `rotation`, and `visible` values. + - Buttons and keyboard shortcuts apply state changes, and transforms are smoothed with lerp. -Key concepts: --Complexity: Easy / Medium / Hard + - State configuration object + - Visibility toggling per object + - Transform interpolation + - UI-triggered state transitions +-Complexity: Medium ## R3F --Possible: Yes / Partial / No +-Possible: Yes -Notes: + - Uses React state (`stateKey`) to drive active scene state. + - `SCENE_STATES` config mirrors vanilla behavior in a declarative structure. + - `useEffect` updates visibility/targets and `useFrame` handles smooth interpolation. -What R3F abstracted: --Complexity: Easy / Medium / Hard + - Render-loop management via `useFrame` + - State-driven scene updates through React + - Cleaner component organization for scene objects +-Complexity: Medium ## Thob Page Builder --Possible: Yes / Partial / No +-Possible: Partial -Notes: + - We can make things like this by creating combinations of object visibility and Perspective Camera position, but the button issue persists. + - We should be able to click the button and it all should be simultaneously or fast enough to not notice. + - Current button flow is not reliable enough for multi-property state switching. -Builder steps: --Complexity: Easy / Medium / Hard + - Create scene objects and define visibility combinations. + - Set Perspective Camera positions for each target state. + - Add state buttons. + - Try binding each button to all required prop changes (visibility + transforms + camera). +-Complexity: Hard ## Comparison Summary --Possible in all 3? Yes / Partial / No +-Possible in all 3? Partial -Main differences: + - Vanilla and R3F both support clean, predictable state switching. + - Thob can represent the same state idea, but synchronized multi-prop button updates are not smooth/reliable yet. -Where Thob is better: + - Fast visual setup of objects, visibility states, and camera values. -Where Thob is weaker: + - Button-driven multi-target updates are difficult to make feel atomic. -What feels awkward or unclear: + - Mapping one button to many coordinated prop updates without visible delay or missed updates. ## Limitation Type (if any) --[ ] Editor UX limitation +-[x] Editor UX limitation -[ ] Runtime limitation -[ ] Schema / data model limitation -[ ] Component limitation --[ ] Event system limitation +-[x] Event system limitation -[ ] Asset pipeline limitation -[ ] Unknown / needs investigation ## Workaround -Is there a workaround? + - Partial workaround. -If yes, what is it? + - Manually set visibility and camera values in sequence. + - Use simpler, fewer state transitions to reduce button binding complexity. ## Suggested Improvement -What should improve in Thob? + - Allow one button to trigger bundled multi-component updates in one action. + - Ensure updates happen simultaneously (or visually instant) for all linked props. + - Improve binding UX so multi-target mappings are easy to build and verify. -Is it: - -editor - -runtime - -component - -UX - -schema/data + - editor + - UX + - component ## Difficulty Estimate --Easy / Medium / Hard +-Medium ## 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 because state-based visibility and framing transitions are common in demos and guided presentations. Reliable one-click synchronized updates would significantly improve real project usability. \ No newline at end of file diff --git a/Week-2/Task-2/builder/BuilderNotes.md b/Week-2/Task-2/builder/BuilderNotes.md index e69de29..579a172 100644 --- a/Week-2/Task-2/builder/BuilderNotes.md +++ b/Week-2/Task-2/builder/BuilderNotes.md @@ -0,0 +1,77 @@ +# Builder Notes (Thob) — Task 2: Scene State Switching + +## Thob Observations from Task Notes + +- **Possible:** Partial +- **Implementation used:** Combinations of object visibility states and Perspective Camera positions, with button-based switching attempts. +- **What worked as expected:** + - Visibility states can be configured for multiple objects. + - Camera position presets can be prepared for different scene views. + - Base scene composition is quick to assemble in the editor. +- **Main limitation observed:** + - One button updating multiple targets (visibility + transforms + camera) is not consistently reliable. + - Updates should happen simultaneously (or fast enough to feel instant), but current behavior can feel staggered/inconsistent. + - Button binding flow remains hard to reason about for multi-prop state orchestration. +- **Builder flow used:** + 1. Create scene objects and set initial visibility/transform states. + 2. Add Perspective Camera and set target positions per scene state. + 3. Add state buttons in UI. + 4. Attempt to bind each button to all required prop updates. + 5. Validate whether transitions are synchronized and repeatable. +- **Complexity:** Hard +- **Main limitation signals:** Editor UX + Event system + Runtime stability concerns. +- **Workaround status:** Partial workaround only (manual or simplified transitions; full one-click synchronized switching is not dependable yet). + +## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning + +### warn: `Found both blacklist and siteRules — using siteRules` +- **Type:** Configuration precedence warning. +- **Probable meaning:** Multiple rule sets are available and runtime is choosing one path (`siteRules`). +- **Impact:** Usually low, but indicates overlapping configuration paths. + +### warn: `... changing from uncontrolled to controlled` and `RadioGroup is changing from uncontrolled to controlled` +- **Type:** React state-management warning. +- **Probable meaning:** UI controls start with unstable values and later switch to controlled mode. +- **Impact:** Property panel/control behavior can become inconsistent during binding setup. + +### warn: `Permissions-Policy header: Unrecognized feature: 'browsing-topics'` +- **Type:** Browser/header compatibility warning. +- **Probable meaning:** Response headers include unsupported policy directives for current browser. +- **Impact:** Low direct impact on scene logic; mostly environment noise. + +### warn: `Unchecked runtime.lastError: The message port closed before a response was received` +- **Type:** Browser runtime/extension messaging warning. +- **Probable meaning:** A message channel closed before callback completion. +- **Impact:** Usually non-fatal, but adds noise and can complicate debugging. + +### warn: `GetBindingData method already registered` (repeated) +- **Type:** Duplicate registration warning. +- **Probable meaning:** Binding handlers are being registered repeatedly across rerenders/remounts. +- **Impact:** High relevance for this task; can cause duplicate triggers and unreliable button-driven state updates. + +### warn: `update-static-component-prop method already registered` +- **Type:** Duplicate update pipeline warning. +- **Probable meaning:** Static prop update handler is attached more than once. +- **Impact:** Can produce repeated writes and non-atomic multi-prop transitions. + +### warn: `resetPOI method already registered` +- **Type:** Duplicate command registration warning. +- **Probable meaning:** Camera/POI reset command is mounted multiple times. +- **Impact:** Camera behavior may drift or feel inconsistent during state switching. + +### error: `Failed to load resource: 404` +- **Type:** Network/resource error. +- **Probable meaning:** Missing/stale project asset or endpoint. +- **Impact:** Can partially break expected editor/preview behavior. + +### error: `THREE.WebGLRenderer: Context Lost` +- **Type:** Graphics runtime error. +- **Probable meaning:** WebGL context dropped due to resource pressure, remount loops, or browser/GPU reset. +- **Impact:** Preview instability can invalidate transition testing. + +## Overall Read + +- Task 2 concept is achievable in thob at a basic level: visibility and camera state combinations can be authored. +- The key product gap is synchronized execution: one button should apply all linked updates simultaneously, but current binding behavior is not reliably atomic. +- Recurring duplicate-registration warnings strongly match the interaction issues seen during multi-prop button setup. +- Improving binding lifecycle stability and one-click bundled updates should be the highest priority for this task pattern.