# threejs-3dmodel-edit and a browser based 3D model configuration editor

> threejs-3dmodel-edit is a Vue 3, Vite, Element Plus and Three.js application for loading 3D models and editing their presentation in the browser: materials, lights, animation, background and panorama, axis helpers, glow, model decomposition, multi model scenes and 3D labels, with the configuration saved to localStorage and exported as glb, obj or usdz. It fits a visualisation engineer who needs a configurable 3D preview, and it is memory hungry by design.

**zhangbo126/threejs-3dmodel-edit** — 基于three.js开发的3D模型可视化编辑器、three.js编辑器。包含模型加载，模型文件导入导出，模型背景图，全景图，模型动画，模型灯光，模型定位，辅助线，模型辉光，模型拖拽，模型拆解， 模型材质等可视化操作编辑系统，模型编辑数据保存预览和代码嵌入 

- Repository: https://github.com/zhangbo126/threejs-3dmodel-edit
- Website: http://threeflowx.cn/open/
- Stars: 630 · Forks: 130
- Language: JavaScript
- License: MulanPSL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/zhangbo126-threejs-3dmodel-edit

## The feature list is a control panel, not a data model

The project describes itself as a 3D model visualisation editing system built on Three.js, Vue 3, TypeScript and Element Plus, and the module table in the documentation is the best description of what it actually does.

The Background module loads background images, panorama images, external panoramas in hdr, jpeg or png format, and external video. The Material module switches material types, selects materials, edits material properties such as colour, wireframe and opacity, and changes material textures. The Post-processing module handles model decomposition, dragging, scaling and translating model materials, and a glow effect with colour, intensity and radius.

Then the scene itself. The Model Lighting module edits ambient light, directional light, point light and spot light. The Model Animation module plays animations, edits animation configuration and rotates the animation axis on x, y and z. The Helpers and Axes module rotates axes, moves the model, and toggles grid and coordinate axis helpers. The Geometry module selects and configures geometry. The 3D Label module drags, loads, renders, selects and edits labels. The Multi-model module handles selection effects, position, axis rotation and scale for several models at once.

Two panels close the loop. The left bar switches the editing scene, adds geometry and loads external models, and supports multi model dragging. The top bar gives model preview, model export in glb, obj and usdz formats, embedded code, and saving of the edit data.

So this is a visual configuration surface for a 3D scene. The editable state is presentation, and the outputs are a preview, an export in three interchange formats, and a snippet of code to embed the result.

## Four branches, and the TypeScript one is still in progress

The branch table is short and it matters, because the project is not on a single stack.

The master branch is `Vue3+Pinia+Javascript`, and it is where the latest features, issues and bug fixes land. The `ts-master` branch is the TypeScript version of master, and the documentation says the latest TypeScript code is still being developed. The `develop` branch is also `Vue3+Pinia+Javascript`, and it is where uncertain features and code refactoring happen. The `gh-pages` branch is the online package branch, which the documentation says can be ignored.

So the default branch a clone gives you is JavaScript with Pinia for state, and the TypeScript variant is a parallel effort rather than a mirror. That is worth knowing before you plan around either.

The stack table lists the versions the project was written against: Vue 3.5.13, Vite 4.3.x, Element Plus 2.4.x, Three 0.169.x, Pinia 2.1.x, Vue3-Draggable-Resizable 1.6.x, Mitt 3.0.x and Axios 1.5.0. The development environment table gives node 21.3.0, npm 10.2.4, yarn 1.22.21, pnpm 9.15.1, and Windows 10 for the last two.

The package manifest in the repository is a little ahead of that table, with Three at `^0.179.0`, Vue at `^3.5.13`, Element Plus at `^2.6.1`, Pinia at `^2.1.7` and Vite at `^5.2.0`, and the project states that the Three.js version follows the official version continuously. There is a mismatch between the documented version table and the manifest, which is a sign the table is maintained by hand and drifts.

The manifest also carries Vuex at `^4.0.0` as a dependency alongside Pinia, and the store directory listing shows a `pinia.js` for Pinia configuration and a `meshEditStore.js` for model editing state, so Pinia is the live choice and Vuex appears to be residue.

## Yarn, pnpm or npm, and the two build targets

The install and launch section is a list of package manager commands, and the documentation points at `package.json` for the details.

```
yarn  / yarn serve  / yarn build(yarn build:pro)
pnpm install / pnpm serve / pnpm build(pnpm build:pro)
```

The scripts behind those names are in the manifest. `dev` and `serve` both run `vite`, `build` runs `vite build --mode development`, and `build:pro` runs `vite build --mode production`. There is a third mode file per environment, `.env.development` and `.env.production`, which is how the two build targets pick up different configuration.

There is also an e2e script, `test:e2e`, which runs `vue-cli-service test:e2e`, and a `cypress.json` at the root plus a `@vue/cli-plugin-e2e-cypress` dev dependency, so there is an end to end test setup even though the main build tooling is Vite. The `prepare` script runs `husky install`, and the repository has a `.husky/` directory, so the commit hooks are set up to run on install.

The deployment note is the one thing to do before you ship: to build for a server, modify the base path in `vite.config.js` to match the domain path you are deploying under. That is a single setting, but forgetting it produces an application whose assets resolve to the wrong URLs, which is the classic static build failure.

The preview notes also warn that some model files are large and the first load takes a long time, and recommend using the Chrome browser.

## Configuration lives in localStorage, and that has consequences

The persistence model is short and has real limits, and the documentation states them plainly.

Model editing configuration is stored in `localStorage`, and if you hit a data related error you clear the local cache and enter again. There is no server, no account and no sharing, and the documentation says the same about external models: they do not support effect preview, and they do not support data saving.

So the configuration a user produces is local to their browser profile, and an externally loaded model is a viewing and manipulation object rather than a source of saved state. That is a sensible design for a preview tool, and it is a hard limit for anything collaborative. A team that wants a scene configuration to travel between people, or to be reviewed and approved, has to build that on top, because the edit data lives in one browser.

The top bar offers model export in `.glb`, `.obj` and `.usdz` formats, and an embedded code option, which is the path for taking a configuration out of the tool. The export format is the interchange with the rest of your pipeline, and the choice of three is useful: glb is the compact binary form, obj is the older text form most tools read, and usdz is the one Apple platforms prefer.

The memory warning in the documentation is the other thing to take seriously. Some features depend heavily on how much memory the computer has, and if you hit stuttering you should make sure there is enough memory available. It recommends Chrome, and it warns that 3D models depend heavily on performance and that a model library component configured above four may cause the browser to crash, and that loading some special model files and large model files may cause the system to stall for a long time.

That last warning is the real constraint on this project. It is a browser application doing real time rendering of user supplied geometry, and the documentation is candid that the ceiling is your machine's memory.

## The project is a storefront for a commercial editor

There is a commercial dimension to the repository that a reader should know about before adopting it.

The documentation asks for a star, offers to buy the author a coffee, and then points at a separate product, ThreeFlowX, described as a 3D low code scene editor, with a link to get authorisation and a docs site at threeflowx.cn/docs. The project also states that if another project meets your needs you can contact the author for consultation, and there is a code image in the repository for that.

So the relationship is: an open source implementation with a permissive licence, and a commercial product that appears to be the supported, documented version. The open repository is a demonstration and a starting point, and the paid product is presumably where the ongoing work and the support live.

The licence is MulanPSL-2.0, the permissive Chinese open source licence, which is a reasonable choice for a project that wants to be usable in commercial products and also wants a copyleft option. There is a `LICENSE` file at the root of the repository.

For an adopter this shapes the questions. If you are going to build on the open code, you need to know how closely the commercial product tracks it, and the answer is in the repository itself: the Three.js version is stated to follow the official version continuously, which means a Three.js release can change behaviour under you at any time, and the documentation asks for an issue if a version upgrade causes a bug.

The other consideration is support. The commercial route exists, which is a reasonable answer to the question of who fixes a regression, and it is worth pricing before you commit to a dependency on this code for something that has to keep working.

## Where a browser 3D editor is the wrong choice

There are three cases where this project does not fit, and the third is the most common one for a team that reaches for a 3D editor in the first place.

The first is an offline or desktop deliverable. Everything here happens in a browser, with WebGL rendering, and the documentation recommends Chrome, so a deployment that has to run on a locked down workstation or offline kiosk is out of scope.

The second is a need for genuinely large assets. The warning that some model files are large and the first load takes a long time, and that large model files may stall the system for a long time, and that a model library configured above four may crash the browser, describes a tool with a real ceiling on scene complexity. A pipeline that handles architectural models or scanned environments is not what this is for.

The third is collaboration. Configuration is stored in localStorage, so it belongs to one browser profile, and external models are documented as not supporting data saving at all. A design process where a scene is configured once and then reviewed, versioned and shared has to be built on top of the exported artefacts rather than on the tool's own state.

The alternative worth naming is not another editor but a different approach: driving Three.js directly from your own code, using the same library this project uses, and treating the editor as a reference for how the scene is put together rather than as the tool that holds the state. The repository is a working example of the whole stack, Vue with Pinia, Element Plus, Vite, draggable and resizable panels, a right click context menu, a model edit panel, a model chooser and a code embed dialog, so the code is worth reading even when the application is not the right fit.

The directory listing makes that concrete. There is an `App.vue` root component with the router view and a message dialog, a `main.js` entry that initialises the Vue app and registers global components, directives and plugins, a `/components` directory with the reusable pieces, a `/config` directory holding constant definitions including shader code plus model, background and texture lists, `/layouts` with an edit view and a VR view, `/router` for the routes, `/store` with the mesh edit state and the Pinia configuration, `/style` with global styles, and `/utils` with directives and global components.

## Conclusion

threejs-3dmodel-edit fits a team that needs a configurable 3D preview for a large screen or a customer facing scene, with models added and adjusted visually rather than by editing code, and that is prepared to accept a browser based memory footprint. It is the wrong choice for production asset pipelines, since the model data is saved to localStorage and external models are documented as not supporting effect preview or data saving, and it is the wrong choice for a machine without the memory the project warns about. Before you adopt it, verify two things: that the branch you want matches your stack, since the JavaScript master branch and the TypeScript ts-master branch are separate, and that the models you intend to load fit in memory, because the documentation states that 3D models depend heavily on performance and that a model library component configured above four may crash the browser. The code is under MulanPSL-2.0, the project publishes no releases, and the last push was on 2026-08-05.

## FAQ

### What is threejs-3dmodel-edit?

It is a 3D model visualisation editing system built on Three.js with Vue 3, Vite and Element Plus, offering model loading, import and export, background and panorama images, model animation, lighting, positioning, helpers, glow, model decomposition, materials and multi model scenes, with edit data saving, preview and code embedding.

### How do I install and run threejs-3dmodel-edit?

Clone the repository and use the package manager of your choice. The documented commands are `yarn`, `yarn serve` and `yarn build` for Yarn, and `pnpm install`, `pnpm serve` and `pnpm build` for pnpm. The underlying scripts are `vite` for dev and serve, `vite build --mode development` for build, and `vite build --mode production` for build:pro.

### Which branch should I use for threejs-3dmodel-edit?

The master branch is Vue 3 with Pinia and JavaScript and receives the latest features and fixes, the ts-master branch is the TypeScript version whose latest code is still in development, develop is where uncertain features and refactoring happen, and the gh-pages branch holds the online package and can be ignored.

### Where does threejs-3dmodel-edit save my editing configuration?

Model editing configuration is stored in `localStorage`, so it belongs to the browser profile. The documentation notes that if you hit a data related error you should clear the local cache and enter again, and that external models do not support effect preview or data saving. Export is available in glb, obj and usdz formats.

### What are the known limitations of threejs-3dmodel-edit?

The documentation warns that some features depend heavily on available memory and may stutter, that large model files can stall the system for a long time, that a model library component configured above four may crash the browser, and that Chrome is recommended. The base path in `vite.config.js` must also be changed to match the deployment domain path.

## Sources

- [Issues](https://github.com/zhangbo126/threejs-3dmodel-edit/issues)
- [License: MulanPSL-2.0](https://github.com/zhangbo126/threejs-3dmodel-edit/blob/master/LICENSE)
- [Project website](http://threeflowx.cn/open/)
- [README](https://github.com/zhangbo126/threejs-3dmodel-edit/blob/master/README.md)
- [zhangbo126/threejs-3dmodel-edit on GitHub](https://github.com/zhangbo126/threejs-3dmodel-edit)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zhangbo126-threejs-3dmodel-edit