Making 3D Designable Inside Framer

Overview

Framer x ThreeJS Runtime là một lightweight Three.js runtime được xây dựng dành cho designer.

Mục tiêu của dự án là giúp designer có thể tạo và điều khiển 3D scene trực tiếp trong Framer mà không cần viết code hay hiểu sâu về Three.js.

Thay vì phải thiết lập renderer, camera, animation, lighting hay interaction bằng code, designer chỉ cần upload model và làm việc với những control quen thuộc của Framer.

Why It Exists

Hầu như designer nào cũng muốn làm một website 3D cho riêng mình.

Tuy nhiên, việc xây dựng một website Three.js vẫn là một rào cản lớn.

Trong khi Framer giúp designer xây dựng website nhanh hơn bao giờ hết, workflow cho 3D vẫn phụ thuộc vào các công cụ bên ngoài như Spline hoặc các custom component rời rạc.

Điều đó tạo ra một khoảng trống khá rõ:

Designer có thể build website trong Framer.

Nhưng lại không thể build trải nghiệm Three.js trong chính workflow đó.

Câu hỏi đặt ra là:

Nếu designer có thể tự xây website trong Framer, tại sao họ không thể tự xây một website Three.js theo cùng cách đó?

The Gap Between Spline and Custom Three.js

Khi bắt đầu nghiên cứu workflow 3D cho Framer, tôi nhận ra hầu hết mọi người thường rơi vào một trong hai hướng.

Hướng đầu tiên là sử dụng các công cụ như Spline. Đây là cách nhanh nhất để đưa một model 3D lên website. Tuy nhiên khi dự án cần nhiều tương tác hơn, logic animation phức tạp hơn hoặc cần gắn chặt với layout và content của website, workflow này bắt đầu bộc lộ giới hạn.

Hướng thứ hai là xây dựng trực tiếp bằng Three.js. Điều này mang lại khả năng kiểm soát gần như không giới hạn, nhưng đổi lại là độ phức tạp kỹ thuật rất cao. Designer gần như phải trở thành developer để có thể tiếp tục.

Khoảng trống nằm ở giữa hai cách tiếp cận đó.

Tôi không muốn tạo ra một công cụ thay thế Three.js.

Tôi cũng không muốn tạo thêm một trình editor 3D khác.

Mục tiêu là tạo ra một runtime cho phép designer làm việc với 3D bằng chính workflow mà họ đã quen thuộc trong Framer.

The Challenge

Vấn đề không nằm ở việc render được model 3D.

Vấn đề nằm ở việc biến một thư viện kỹ thuật như Three.js thành một công cụ mà designer có thể sử dụng được.

Điều này tạo ra ba thách thức lớn:

Thách thức lớn nhất là tìm ra đâu là những phần quan trọng nhất của Three.js cần được expose, và đâu là những phần nên được ẩn đi.

The biggest challenge was not rendering 3D.

The biggest challenge was deciding what not to expose.

Three.js cung cấp hàng trăm API, setting và khái niệm kỹ thuật khác nhau. Nếu expose toàn bộ, sản phẩm sẽ nhanh chóng trở thành một developer tool thay vì một design tool.

Core Idea

Thay vì đưa toàn bộ Three.js vào Framer, tôi chọn cách ngược lại:

Chỉ mang những gì designer thực sự cần.

Designer không cần hiểu:

• Renderer

• Scene Graph

• Animation Mixer

• Raycaster

• Render Loop

• Environment Pipeline

Designer chỉ cần:

• Upload model

• Scroll xuống

• Model chuyển trạng thái

• Hover vào object

• Trigger animation

Mục tiêu của runtime là biến các khái niệm kỹ thuật thành những control quen thuộc bên trong Framer.

Approach

Step 01 — Define the Minimum Runtime

Tôi bắt đầu bằng việc xác định những tính năng thiết yếu nhất cho một website 3D hiện đại:

• Model import

• Camera control

• Scroll-driven animation

• Hover interaction

• Lighting

• Environment

• Material control

Ngoài ra runtime cần hỗ trợ:

• Upload model bằng local file hoặc URL

• Camera scroll-drive theo section

• Position, Rotation, Scale animation

• Scroll appear

• Scroll transform

• Scroll animation

• State transition

Tất cả đều phải bám sát mental model mà designer đã quen thuộc trong Framer.

Step 02 — AI-Assisted Development

Đây là một lĩnh vực hoàn toàn mới đối với tôi.

Thay vì build toàn bộ bằng tay, tôi sử dụng AI agent để tăng tốc quá trình nghiên cứu và phát triển.

Agent được trang bị hai nhóm kiến thức chính:

• Framer Component Architecture

• Three.js Runtime Architecture

Song song đó tôi nghiên cứu Framer Developer API và phân tích nhiều website Three.js khác nhau để hiểu những pattern phổ biến trong thị trường.

Step 03 — Build First, Optimize Later

Ở giai đoạn đầu, tôi chủ động bỏ qua kiến trúc.

Mục tiêu duy nhất là:

Build tất cả những gì có thể build.

Tôi muốn hiểu giới hạn của Three.js, giới hạn của Framer và giới hạn của chính runtime trước khi bắt đầu tối ưu hệ thống.

Step 04 — Become the User

Đây là giai đoạn tốn nhiều thời gian nhất.

Tôi liên tục sử dụng chính sản phẩm mình tạo ra dưới góc nhìn của một designer.

Mỗi control đều phải trả lời một câu hỏi:

Nó có dễ dùng hơn việc mở code editor không?

Nếu câu trả lời là không, control đó sẽ bị thiết kế lại.

Nhiều nhóm setting kỹ thuật được gom thành object đơn giản hơn để giảm cognitive load cho designer.

What I Built

Phiên bản đầu tiên đã bao phủ gần như toàn bộ workflow cần thiết cho một website Three.js trong Framer.

Scene Control

• Model Import

• Camera Setup

• Environment Control

• HDRI Setup

• Lighting Control

• Material Control

• Post Processing

• Debug Helper

Motion & Interaction

• Scroll Animation

• Scroll Appear

• Scroll Transform

• State Machine

• Hover Interaction

• Click Interaction

• Lerp Animation Smoothing

Điểm quan trọng nhất là tận dụng event system có sẵn trong Framer thay vì tạo ra một workflow hoàn toàn mới.

Designer vẫn làm việc theo cách quen thuộc của Framer.

From Model Interaction to Object Interaction

Ở giai đoạn đầu, runtime chỉ hỗ trợ model-level interaction.

Designer có thể:

• Move model

• Scale model

• Rotate model

• Trigger animation

Điều này đủ để tạo ra các landing page 3D cơ bản.

Tuy nhiên sau nhiều vòng thử nghiệm, tôi nhận ra vấn đề không nằm ở model.

Vấn đề nằm ở các object bên trong model.

Ví dụ một chiếc xe không phải là một object duy nhất.

Nó bao gồm:

• Door

• Wheel

• Dashboard

• Steering Wheel

Designer không chỉ muốn xoay cả chiếc xe.

Họ muốn:

• Hover vào bánh xe

• Click vào cửa xe

• Trigger animation cho dashboard

• Thay đổi trạng thái của từng object riêng lẻ

Điều này dẫn tới việc tôi xây dựng hệ thống Object Interaction.

Thay vì điều khiển model ở cấp độ scene, runtime có thể expose interaction ở cấp độ object bên trong model.

Điều này mở ra nhiều khả năng hơn cho product showcase, storytelling website và interactive experience.

The Hardest Problem

Bài toán khó nhất không phải animation.

Mà là rendering.

Ban đầu mỗi component đều sở hữu một WebGL renderer riêng.

Cách tiếp cận này hoạt động tốt với các website đơn giản.

Nhưng khi layout trở nên phức tạp hơn, vấn đề bắt đầu xuất hiện:

• GPU memory tăng nhanh

• Render cost tăng theo số lượng canvas

• Mobile browser dễ crash hơn

• Layout phức tạp khó kiểm soát

Vấn đề thực sự không nằm ở model.

Vấn đề nằm ở số lượng WebGL context được tạo ra.

Root / Slot Renderer Architecture

Để giải quyết điều đó, tôi thiết kế một kiến trúc mới mang tên:

Root / Slot Renderer Bridge

Thay vì mỗi component tạo ra một renderer riêng.

Toàn bộ website chỉ sử dụng một renderer duy nhất.

Các Slot chỉ có nhiệm vụ khai báo dữ liệu, trạng thái và instruction.

Renderer trung tâm sẽ chịu trách nhiệm render toàn bộ scene.

Đây cũng là phần tốn nhiều thời gian nghiên cứu, build và debug nhất trong toàn bộ dự án.

Outcome

Runtime giúp biến workflow Three.js từ một bài toán engineering thành một workflow gần hơn với cách designer đang làm việc trong Framer.

Designer có thể:

• Upload model

• Thiết lập animation

• Điều khiển state

• Tạo scroll interaction

• Xây dựng landing page 3D

mà không cần thiết lập Three.js từ đầu.

Quan trọng hơn, toàn bộ trải nghiệm vẫn giữ được mental model quen thuộc của Framer thay vì buộc designer phải học một workflow hoàn toàn mới.

What I Learned

Dự án này dạy tôi rằng build feature dễ hơn rất nhiều so với thiết kế control.

Phần khó nhất không phải render được một scene 3D.

Phần khó nhất là biến những khái niệm kỹ thuật thành những control mà designer có thể hiểu ngay khi nhìn thấy.

Một runtime tốt không phải là runtime expose nhiều tính năng nhất.

Mà là runtime expose đúng những tính năng cần thiết.

Dự án cũng củng cố một bài học tôi gặp đi gặp lại trong design system, developer tools và creative software:

Người dùng không học API.

Người dùng học mental model.

Càng bám sát mental model sẵn có của người dùng, sản phẩm càng dễ tiếp cận và dễ sử dụng.

Với Framer x ThreeJS Runtime, thành công lớn nhất không phải là render được 3D trong Framer.

Mà là biến một workflow vốn dành cho engineer thành một workflow mà designer có thể sử dụng hằng ngày.