anshk/builder-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: update week2 task4 docs

Browse Source
This commit is contained in:
anshk 2026-04-21 17:17:37 +05:30
parent ee8e2c3342
commit 29f0625b8c
3 changed files with 5 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
Week-2/Task-4/ProductLens.md
View File

@ -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.

2
Week-2/Task-4/TaskNotes.md
View File

@ -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?

3
Week-2/Task-4/builder/BuilderNotes.md
View File

@ -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.