# Build brief — a focused alternative to Feather 3D > **Verdict:** Not faithfully · **Buildability:** 45/100 · **Category:** Design > **Source:** https://www.canitbevibecoded.com/feather-3d > Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Feather 3D. Verify current pricing and capabilities before acting. ## Context **Feather 3D** — Browser-based 3D creation tool for building, lighting and rendering scenes without living inside a full DCC suite. 3D authoring tools are the category where one-shot builds go to die. An agent will happily hand you a Three.js scene with a transform gizmo and an orbit camera with a focused implementation, and it will feel great for about ten minutes. Then you want snapping, a real undo stack, material editing, HDRI lighting that does not blow out, UVs, glTF import that survives weird exporters, and a viewport that stays at 60fps with more than a dozen objects, and you are now writing a DCC app instead of using one. None of that is conceptually hard, all of it is thousands of small interaction decisions plus GPU tuning, and that is exactly what you are paying for here. Build the toy if you want a scene composer for one specific job, not if you want a 3D tool you enjoy opening. This brief describes a focused, single-operator replacement for the part of Feather 3D that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest. ## What you are building A local Three.js scene composer: drop in glTF assets, move and rotate them with a gizmo, tweak lights and environment, then export the scene or a PNG render. - Generate a constrained editing workflow with reusable templates and deterministic exports. - A responsive interface with real empty, loading, success, and error states. ## Requirements ### Functional - Node and a browser with WebGL2. - Your own glTF/GLB assets, nothing is generated for you. - An HDRI file for environment lighting. ### Non-functional - Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support. - Security: server-side secrets, validated input, and no credentials in the client bundle. - Reliability: retries with backoff on external calls, and a clear failure state when a provider is down. - Portability: the operator can export their data and leave without losing it. ## Implementation brief Build a local-only 3D scene composer as a web app. This is a personal tool, not a product. Stack, no substitutions: Vite + TypeScript + vanilla Three.js (latest). No React, no framework. No backend, no accounts, no telemetry, no network calls at all. What it does: 1. Full-window WebGL canvas with an orbit/pan/zoom camera (OrbitControls) and a grid helper. 2. Drag and drop .glb or .gltf files onto the canvas to add them to the scene. Use GLTFLoader and fit the camera to the new object's bounding box on first load. 3. Click an object to select it. Show TransformControls with keyboard shortcuts: W translate, E rotate, R scale, X toggle world/local space, Delete removes the selection. 4. Left sidebar: scene outliner listing objects by name, click to select, double click to rename, visibility toggle per object. 5. Right sidebar: numeric inputs for position, rotation (degrees) and scale of the selection, kept in sync with the gizmo in both directions. 6. Lighting panel: one directional light with intensity, color and a draggable azimuth/elevation, plus ambient intensity. Drag and drop an .hdr file to set the environment via RGBELoader and PMREMGenerator, with an exposure slider. 7. Shadows: soft shadow map from the directional light, plus a toggleable ground plane that receives shadows only. 8. Undo/redo (Ctrl+Z / Ctrl+Shift+Z) for add, delete, transform and rename. Implement it as a plain command stack, do not try to diff the whole scene graph. 9. Save/load the scene as a JSON file: asset filenames plus transforms plus light settings. On load, re-prompt for any asset files it cannot find instead of failing silently. 10. Render button: renders the current view at a chosen resolution (up to 4x canvas size) and downloads a PNG. Also an Export glTF button using GLTFExporter. Explicitly out of scope, do not build these: mesh editing or sculpting, UV tools, material/shader authoring beyond base color and roughness sliders, animation, physics, any AI generation, any multi-user or cloud sync. Deliver: working dev server on npm run dev, a README with the shortcut list, and no .env because there are no secrets. Keep it to a handful of files with a clear scene-state module; do not invent an architecture. ## Delivery standard - Inspect the repository first, then write a short implementation plan before writing code. - Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data. - Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations. - Include responsive layouts plus genuine empty, loading, success, validation, and failure states. - Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data. - Add structured logs around every external call and return actionable errors without leaking sensitive details. - Write unit tests for the core logic and one automated test of the main user journey. - Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations. ## Acceptance criteria - [ ] A clean install starts the app using only the README and .env.example. - [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable. - [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state. - [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control. - [ ] Tests, type checking, linting, and a production build all pass with no ignored failures. - [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified. ## Non-goals Do not build these, and do not claim to have replaced them: - Actual modeling: you can arrange assets, you cannot make them. - A trustworthy undo/redo history across every operation. - Material and shader editing beyond a handful of sliders. - Viewport performance work: shadows, culling, LOD, big scenes. - Whatever asset library, templates or generation features ship with the paid product. ## What you still own after launch - Run migrations, backups, restores, and dependency updates. - Test the critical journey after every model, API, or hosting change. - Monitor failures and fix the edge cases a first prompt will miss. ## Risk **Manageable.** A personal version is realistic if you test the critical journey and keep reliable backups. Editorial confidence in this assessment: low. No reviewed project implementation is linked yet. --- Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/feather-3d