References (Official)
Basic Policy of This Skill
- Structure: The Scene-Camera-Renderer trinity is the starting point for everything.
- Memory management: GPU resources are not automatically GC'd. dispose() is mandatory.
- Optimization: Reducing draw calls (batching/instancing/LOD) and compressed textures (KTX2) are key.
- R3F: In a React environment, React Three Fiber is the first choice (a complete wrapper for Three.js, with no overhead).
Philosophy (Decision Rules)
- Scene-Camera-Renderer — Everything starts from these three elements. Do not omit them.
- GPU memory is managed manually — Explicitly dispose() geometry/material/texture/renderTarget.
- Reduce draw calls — Avoid generating large numbers of individual meshes by using batching/instancing.
- Compress textures — PNG/JPEG are fully expanded on the GPU (200KB PNG → 20MB+ VRAM). Use KTX2/Basis Universal to reduce to about 1/10.
- Manually update static objects —
matrixAutoUpdate = false+ on change, callupdateMatrix(). - R3F is a thin wrapper — Anything that works in Three.js works as-is in R3F. Features from new versions are also immediately available.
Draft a Structural Specification Before Building
Without building right away,first verbalize the structureand then begin. List the scene graph composition, object placement and scale ratios, and camera field of view and distance as bullet points,predict common breakdownsand enumerate them (e.g., inconsistent scale standards / subject outside the camera frustum / faces overlapping and causing z-fighting).
Output Format (Always in This Order)
- Recommended policy (1–3 lines)
- Rationale (performance / memory / maintainability)
- Design proposal (scene structure / memory strategy / rendering optimization / R3F usage)
- Checklist (confirm before implementation)
- Pitfalls (to avoid)
- Next actions (order for trying small steps)
Checklist
- Are there any missed dispose() calls (geometry/material/texture/renderTarget)?
-
renderer.info.memoryAre you monitoring the resource count with ? (If the number keeps increasing, it is a leak) - Are you setting
matrixAutoUpdate = falseon static objects? - Are textures using a compressed format (KTX2/Basis)?
- Are you using instancing for large numbers of identical meshes?
- Is there cleanup processing to stop the animation loop?
- Are you updating the camera aspect ratio and renderer.setSize on window resize?
- Did you write the structural specification (scene composition/scale ratio/camera) and breakdown list before building?
Common pitfalls
- Memory leaks from forgetting dispose() (the biggest pitfall)
- Every frame,
new THREE.Vector3()and similar object creation (reuse them outside the loop) - Conflict between CSS transitions and Three.js animations
requestAnimationFrameis called in multiple places- VRAM waste from overusing PNG/JPEG textures
- Cramming everything into one file (split Scene management into modules)
- Forgetting to clean up event listeners (resize, etc.)
- Starting to build from the details without drafting a structural specification (you won't notice the overall breakdown)