From 29f0625b8cb04a718adc42522ace6424e4c5fff0 Mon Sep 17 00:00:00 2001 From: anshk Date: Tue, 21 Apr 2026 17:17:37 +0530 Subject: [PATCH] docs: update week2 task4 docs --- Week-2/Task-4/ProductLens.md | 1 + Week-2/Task-4/TaskNotes.md | 2 ++ Week-2/Task-4/builder/BuilderNotes.md | 3 ++- 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/Week-2/Task-4/ProductLens.md b/Week-2/Task-4/ProductLens.md index 5b8bc90..b5bff13 100644 --- a/Week-2/Task-4/ProductLens.md +++ b/Week-2/Task-4/ProductLens.md @@ -6,6 +6,7 @@ - Motion design layouts where one parent motion drives a cluster of elements. - Does Thob feel strong enough for this use case? - Partial. The mesh-inside-mesh pattern works for parent-child inheritance, but Perspective Camera rotation seems broken because objects disappear no matter which rotation axis is used. + - For step-selection interactions, button-driven setup was not reliable end-to-end; radio-button switching between preconfigured states is a more dependable fallback. - What would improve the experience? - Fix Perspective Camera component rotation so scene objects do not disappear during camera rotation. - Add reusable presets for common parent-child motion examples. diff --git a/Week-2/Task-4/TaskNotes.md b/Week-2/Task-4/TaskNotes.md index 6bbc888..26cd206 100644 --- a/Week-2/Task-4/TaskNotes.md +++ b/Week-2/Task-4/TaskNotes.md @@ -34,6 +34,7 @@ Build a step-based scene where a parent group is translated and rotated, while c - We can make things like this by following the simple mesh-inside-mesh design. - Rotate the parent object, and children inherit the rotation and move with the parent while maintaining offset distance. - This matches the same parent-child transform behavior used in vanilla and R3F. + - For guided step switching, my first intuition was to use button-driven setup, but that interaction flow was not reliable enough to trust end-to-end. - Perspective Camera component rotation feature appears broken right now: no matter how much camera rotation is changed on any axis, objects disappear. -Builder steps: - Create a parent mesh/group container. @@ -74,6 +75,7 @@ Build a step-based scene where a parent group is translated and rotated, while c - Keep parent/child group rotation for the main motion behavior. - Avoid rotating the Perspective Camera component for now. - Use camera position changes and look target adjustments instead of direct camera rotation. + - For step selection UI, prefer radio-button switching between preconfigured states while camera rotation remains unstable. ## Suggested Improvement -What should improve in Thob? diff --git a/Week-2/Task-4/builder/BuilderNotes.md b/Week-2/Task-4/builder/BuilderNotes.md index 3524300..56be0cb 100644 --- a/Week-2/Task-4/builder/BuilderNotes.md +++ b/Week-2/Task-4/builder/BuilderNotes.md @@ -20,7 +20,7 @@ 5. Validate whether grouped motion plus camera framing can be repeated reliably. - **Complexity:** Easy for hierarchy behavior, Medium for complete camera-guided flow due runtime issues. - **Main limitation signals:** Runtime + Editor UX + Unknown investigation needed. -- **Workaround status:** Partial workaround only (keep parent-driven motion, avoid direct camera rotation, prefer camera position/look target adjustments). +- **Workaround status:** Partial workaround only (keep parent-driven motion, avoid direct camera rotation, prefer camera position/look target adjustments, and use radio-button switching for preconfigured step states when button bindings are unreliable). ## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning @@ -63,5 +63,6 @@ - Task 4 core hierarchy behavior works in builder: parent rotation correctly drives child motion with preserved local offsets. - The major blocker is camera reliability: direct Perspective Camera rotation can make objects disappear, reducing feature parity confidence. +- For guided step selection controls, radio-button switching between preconfigured states is currently more dependable than button-heavy interaction wiring. - Repeated binding-registration and controlled/uncontrolled warnings suggest editor/runtime instability that can amplify interaction and camera issues. - Product priority for this task should focus on camera rotation reliability first, then interaction-state stability for repeatable multi-step scene authoring.