docs: finalized planetary texture switcher diagnostic report for week 2 task 2
This commit is contained in:
parent
b69935ef5e
commit
d866db852e
@ -1,66 +1,55 @@
|
|||||||
# Task: Texture / Surface Variant Switcher
|
# Week 2 Task 2 - Texture Switcher
|
||||||
|
|
||||||
## Objective
|
## Objective
|
||||||
Create one object with 2–3 surface variations (e.g., leather, wood, fabric).
|
Implement a dynamic surface switcher (Earth/Moon) on a 3D sphere and evaluate the developer experience across Vanilla, R3F, and Thob.
|
||||||
|
|
||||||
## Vanilla three.js
|
## Vanilla three.js
|
||||||
-Possible: Yes / Partial / No
|
- **Possible**: Yes
|
||||||
-Notes:
|
- **Notes**: Requires manual `TextureLoader` management. The developer must ensure textures are fully loaded before assignment to prevent "black frames" or flicker.
|
||||||
-Key concepts:
|
- **Key concepts**: Texture Mapping, Asynchronous Loading, UV Wrap.
|
||||||
-Complexity: Easy / Medium / Hard
|
- **Complexity**: Medium (Handling external URLs and loading states manually).
|
||||||
|
|
||||||
## R3F
|
## R3F
|
||||||
-Possible: Yes / Partial / No
|
- **Possible**: Yes
|
||||||
-Notes:
|
- **Notes**: Minimal implementation using the `useTexture` hook. Caching and loading states are handled out-of-the-box by the framework's architecture.
|
||||||
-What R3F abstracted:
|
- **What R3F abstracted**: Async loader management and texture instance reuse.
|
||||||
-Complexity: Easy / Medium / Hard
|
- **Complexity**: Easy.
|
||||||
|
|
||||||
## Thob Page Builder
|
## Thob Page Builder
|
||||||
-Possible: Yes / Partial / No
|
- **Possible**: Yes
|
||||||
-Notes:
|
- **Notes**: High visual efficiency using the built-in Media Library and the `RadioGroup` component. Managing 4 variations through a loop keeps the hierarchy much cleaner than individual buttons.
|
||||||
-Builder steps:
|
- **Builder steps**: Upload textures to Project Library -> Configure RadioGroup loop -> Map variants to the Material's `map` property.
|
||||||
-Complexity: Easy / Medium / Hard
|
- **Complexity**: Easy-Medium (Complexity scale depends on loop logic).
|
||||||
|
|
||||||
## Comparison Summary
|
## Comparison Summary
|
||||||
-Possible in all 3? Yes / Partial / No
|
- **Possible in all 3?**: Yes
|
||||||
-Main differences:
|
- **Main differences**: Vanilla is imperative/manual; R3F is declarative/hook-based; Thob is visual/library-based.
|
||||||
-Where Thob is better:
|
- **Where Thob is better**: Hosting assets and providing a visual gallery for texture selection rather than dealing with URL pathing.
|
||||||
-Where Thob is weaker:
|
- **Where Thob is weaker**: Expression "discoverability." Finding proprietary terms like `$context.item_currentItem.id` is difficult without documentation.
|
||||||
-What feels awkward or unclear:
|
- **What feels awkward or unclear**: The mass of console warnings generated by the data-binding system during loop interactions.
|
||||||
|
|
||||||
## Limitation Type (if any)
|
## Limitation Type (if any)
|
||||||
-[ ] Editor UX limitation
|
- [x] Editor UX limitation (Context visibility)
|
||||||
-[ ] Runtime limitation
|
- [x] Documentation/Discovery limitation (Proprietary syntax)
|
||||||
-[ ] Schema / data model limitation
|
- [x] Schema / data model limitation (Internal binding redundancy)
|
||||||
-[ ] Component limitation
|
- [ ] Asset pipeline limitation
|
||||||
-[ ] Event system limitation
|
|
||||||
-[ ] Asset pipeline limitation
|
|
||||||
-[ ] Unknown / needs investigation
|
|
||||||
|
|
||||||
## Workaround
|
## Workaround
|
||||||
-Is there a workaround?
|
- **Is there a workaround?**: Not required for functionality; manual memorization of syntax is currently required to bridge the documentation gap.
|
||||||
-If yes, what is it?
|
|
||||||
|
|
||||||
## Suggested Improvement
|
## Suggested Improvement
|
||||||
-What should improve in Thob?
|
- **Primary Optimization**: Implement an **Autocomplete/Dropdown** for expression fields so users can see `$context` options directly in the UI.
|
||||||
-Is it:
|
- **Secondary Optimization**: Optimize the runtime renderer to reduce the volume of `method already registered` logs during loops.
|
||||||
-editor
|
- **Is it**: Editor, UX, Docs.
|
||||||
-runtime
|
|
||||||
-component
|
|
||||||
-UX
|
|
||||||
-schema/data
|
|
||||||
|
|
||||||
## Difficulty Estimate
|
|
||||||
-Easy / Medium / Hard
|
|
||||||
|
|
||||||
## Business Value
|
## Business Value
|
||||||
-Low / Medium / High
|
- **High**: Essential for configurators that require "real-world" surface swapping (flooring, upholstery, car finishes).
|
||||||
|
|
||||||
## Product Lens
|
## 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?
|
- **What kind of customer use case does this support?**: Architectural visualization and high-end retail customizers.
|
||||||
- Does Thob feel strong enough for this use case?
|
- **Does Thob feel strong enough for this use case?**: Yes. Visually, the texture rendering is production-quality.
|
||||||
- What would improve the experience?
|
- **What would improve the experience?**: In-editor tooltips explaining the data-binding logic.
|
||||||
|
|
||||||
## Recommendation
|
## Recommendation
|
||||||
Should Thob support this better? Why?.
|
Thob is very strong at handling assets. To make it enterprise-ready, they should focus on making the "Logic" layer as visual as the "3D" layer by adding autocompletion for binding expressions.
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user