Can Feather 3D be vibe coded?
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.
Jump to the build brief ↓Legacy-calibrated assessment
Checked Aug 2026
low editorial confidence
Tracked separately from the pricing check
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- 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.
The parts a prompt cannot buy
- 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
- The last 20 percent is sync, migration fidelity, speed, and edge cases.
Build, switch, or keep paying
Narrower, with trade-offs
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.
Use the build brief ↓No checked option yet
Compare the prior art below or build only the workflow you need.
Recommended
Because the alternative is Blender, and for a large group of people Blender is a cliff. A focused 3D tool that opens fast, gives you sensible defaults and gets a decent render out the other side is worth money precisely because someone else absorbed the tedium of making a viewport pleasant. A DIY composer is fine for a repeated, narrow task like laying out product shots from assets you already own. It is a bad trade if 3D is something you want to actually get better at.
Visit Feather 3D ↗Why people still pay
Because the alternative is Blender, and for a large group of people Blender is a cliff. A focused 3D tool that opens fast, gives you sensible defaults and gets a decent render out the other side is worth money precisely because someone else absorbed the tedium of making a viewport pleasant. A DIY composer is fine for a repeated, narrow task like laying out product shots from assets you already own. It is a bad trade if 3D is something you want to actually get better at.
The last 20 percent is sync, migration fidelity, speed, and edge cases.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to Feather 3D
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? · Full report: https://www.canitbevibecoded.com/feather-3d
You still own the product
- 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.
Projects built from this idea
No reviewed implementation has been linked for Feather 3D yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of Feather 3D?Submit the project as evidence for this report.
Before you start
Can Feather 3D be vibe coded?
Not faithfully. 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.
What can an AI coding agent reproduce from Feather 3D?
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.
What will a DIY Feather 3D replacement still be missing?
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; The last 20 percent is sync, migration fidelity, speed, and edge cases.
What do I still own after building a Feather 3D alternative?
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.