Week 2 Task 2 - Texture Switcher

Objective

Implement a dynamic surface switcher (Earth/Moon) on a 3D sphere and evaluate the developer experience across Vanilla, R3F, and Thob.

Vanilla three.js

Possible: Yes
Notes: Requires manual TextureLoader management. The developer must ensure textures are fully loaded before assignment to prevent "black frames" or flicker.
Key concepts: Texture Mapping, Asynchronous Loading, UV Wrap.
Complexity: Medium (Handling external URLs and loading states manually).

R3F

Possible: Yes
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: Async loader management and texture instance reuse.
Complexity: Easy.

Thob Page Builder

Possible: Yes
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: Upload textures to Project Library -> Configure RadioGroup loop -> Map variants to the Material's map property.
Complexity: Easy-Medium (Complexity scale depends on loop logic).

Comparison Summary

Possible in all 3?: Yes
Main differences: Vanilla is imperative/manual; R3F is declarative/hook-based; Thob is visual/library-based.
Where Thob is better: Hosting assets and providing a visual gallery for texture selection rather than dealing with URL pathing.
Where Thob is weaker: Expression "discoverability." Finding proprietary terms like $context.item_currentItem.id is difficult without documentation.
What feels awkward or unclear: The mass of console warnings generated by the data-binding system during loop interactions.

Limitation Type (if any)

Editor UX limitation (Context visibility)
Documentation/Discovery limitation (Proprietary syntax)
Schema / data model limitation (Internal binding redundancy)
Asset pipeline limitation

Workaround

Is there a workaround?: Not required for functionality; manual memorization of syntax is currently required to bridge the documentation gap.

Suggested Improvement

Primary Optimization: Implement an Autocomplete/Dropdown for expression fields so users can see $context options directly in the UI.
Secondary Optimization: Optimize the runtime renderer to reduce the volume of method already registered logs during loops.
Is it: Editor, UX, Docs.

Business Value

High: Essential for configurators that require "real-world" surface swapping (flooring, upholstery, car finishes).

Product Lens

Is this pattern useful for real customers?: Yes.
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?: Yes. Visually, the texture rendering is production-quality.
What would improve the experience?: In-editor tooltips explaining the data-binding logic.

Recommendation

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.

3.3 KiB Raw Blame History