Procedural geometry는 규칙, 데이터, 상호작용을 형태로 바꾼다는 점에서 매력적이다. Three.js와 WebGPU의 procedural geometry, Three.js와 TSL 기반 인터랙티브 3D 클러스터는 시간이 흐르며 생성되고 변하는 웹 장면으로의 이동을 보여 준다.

여기서 필요한 관점 전환은 만들 수 있는 형태의 수를 먼저 묻지 않는 것이다. 프레임 하나가 수행해도 되는 작업량부터 정해야 한다.

생성형 형태는 복잡도의 출처를 옮긴다

미리 만든 asset은 복잡도의 상당 부분을 콘텐츠 제작 단계에 둔다. Procedural geometry는 생성 규칙, 파라미터, 애니메이션, 입력이 장면을 계속 바꾸기 때문에 그 일부를 런타임으로 옮긴다.

반응적인 경험에는 장점이지만 복잡도를 알아차리기 어려워진다. 작은 파라미터 변경도 요소 수나 장면 갱신 작업량을 크게 늘릴 수 있다.

통제 가능한 수치로 장면 예산을 설계하라

모든 프로젝트에 맞는 단일 수치는 없다. 대신 instance 수, subdivision 깊이, 파티클 밀도, render resolution, 입력 반응 주기처럼 장면에 맞는 제한을 고른다.

이 제한은 frame rate가 떨어진 뒤의 응급 처방이 아니라 설계의 일부여야 한다. 품질을 낮춰야 할 때도 가장 중요한 시각 신호와 상호작용은 유지해야 한다.

상호작용 모델과 그리기 모델을 분리하라

사용자는 많은 event를 만들 수 있지만 화면이 그릴 수 있는 주기는 유한하다. event 하나마다 장면 하나를 다시 만들지 말고, 입력을 다음 frame에서 렌더러가 읽을 목표 상태로 누적한다.

애니메이션에도 같은 원칙이 적용된다. frame 주기에 맞춰 갱신하고 상태 변경이 만드는 작업량을 제한한다.

procedural geometry가 맞는 경우

• 생성 규칙이 경험의 서사나 상호작용에 포함될 때 적합하다.
• 구조화된 시각화와 탐색형 경험에 잘 맞는다.
• 정적 이미지나 영상이 같은 정보를 잘 전달한다면 적합하지 않다.
• 효과를 필수로 보기 전에 제약된 하드웨어에서 시험한다.

5분 요약

• Procedural geometry는 asset의 복잡도를 런타임으로 옮긴다.
• 장면 예산은 측정 가능한 제한으로 정해야 한다.
• event마다 재생성하지 말고 입력을 누적해 frame 단위로 그린다.
• 생성 규칙이 실제 사용자 가치를 만들 때 3D를 사용하라.

참고 자료

• Sixty Frames for the Record: A Three.js Game, Seven Fly-Throughs, and a Wall of CRTs
• Run Rob Run: Building a Music-Reactive Goo with Three.js and WebGPU
• Relighting Images with Depth Maps and Three.js
• Creating an Interactive 3D Cluster with Three.js, TSL and Three Start
• Exploring Procedural Geometry with Three.js and WebGPU
• Garden Anomaly: A Tiny WebGPU and TSL Experiment
• High-Frequency Real-Time Data in React: From Ring Buffers to OffscreenCanvas