89 lines
3.4 KiB
Markdown
89 lines
3.4 KiB
Markdown
# Task: Scene State Switching (Visibility + Transform Presets)
|
|
|
|
## Objective
|
|
Switch between predefined scene states where each state controls object visibility, object transforms, and scene framing behavior.
|
|
|
|
## Vanilla three.js
|
|
-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:
|
|
- State configuration object
|
|
- Visibility toggling per object
|
|
- Transform interpolation
|
|
- UI-triggered state transitions
|
|
-Complexity: Medium
|
|
|
|
## R3F
|
|
-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:
|
|
- Render-loop management via `useFrame`
|
|
- State-driven scene updates through React
|
|
- Cleaner component organization for scene objects
|
|
-Complexity: Medium
|
|
|
|
## Thob Page Builder
|
|
-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:
|
|
- 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? 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)
|
|
-[x] Editor UX limitation
|
|
-[ ] Runtime limitation
|
|
-[ ] Schema / data model limitation
|
|
-[ ] Component 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
|
|
- UX
|
|
- component
|
|
|
|
## Difficulty Estimate
|
|
-Medium
|
|
|
|
## Business Value
|
|
-High
|
|
|
|
## Recommendation
|
|
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. |