Astral3D: A Vue3 and Three.js Editor for BIM and CAD on the Web

What Astral3D solves that a plain Three.js scene does not

Three.js gives you a renderer, a scene graph and loaders. It does not give you a file menu, a property panel, an animation timeline, or a way to open a Revit model in a browser tab. Astral3D is the second layer: an editor application built on Vue 3.5.22 and Three.js r176, packaged in a pnpm workspace whose root package.json is named astral3d and versioned 1.0.0. The target reader is a web developer who has been asked to put a building model or a CAD drawing on a page and does not want to write a scene editor from scratch.

The format list is where the project separates itself from generic Three.js tooling. The README claims 30+ model formats and names GLTF, OBJ, FBX, GLB, RVT and IFC, then adds DWG and DXF under CAD parsing. RVT and DWG are the interesting entries because they are proprietary Autodesk formats that Three.js loaders do not handle. How the conversion happens is not described in the README; the documentation site at editor-doc.astraljs.com is where the project points for the operational detail, and the README itself only links to it.

How the engine, the editor and the SDK fit together

The repository is a pnpm workspace. The root pnpm-workspace.yaml defines the package boundaries, and the scripts in package.json show three buildable units under packages/: sdk, editor and examples, plus a docs package. The separation matters. The sdk package is the engine, and the editor depends on a built SDK: the editor:build script is pnpm run sdk:build && pnpm run -C packages/editor build, so the editor cannot be built before the SDK exists. That is a deliberate layering, not an accident of the script order.

Around those two core packages sit the features that the README groups as extension capability: a plugin system, a script runtime, a particle system, a weather system, cloud storage integration and an asset centre. Scene data can be split and stored per package, which the README calls scene sub-package storage and loading. That is the mechanism that makes large BIM models tractable in a browser: instead of one monolithic scene file, the scene is divided and loaded in parts. The README does not document the split format or the loading strategy, so treat the phrase as a claim about capability rather than a specification.

A separate repository, yx8663/astral-service, is listed as the backend implementation. The README does not say which editor features require it. Cloud storage and the asset centre are the obvious candidates, but that is inference, not documentation.

Installing Astral3D and opening the editor for the first time

The README states two prerequisites: Node.js 23.11.x or newer, and PNPM. The root package.json is slightly more permissive, declaring engines.node as >=23.0.0, while the README asks for 23.11.x. The package manager field pins [email protected]. If your build image runs Node 20 or 22, this project is not for that image without a change you would have to make yourself.

The clone and install sequence is given verbatim in the README. Note the order: the SDK is built before the editor starts, because the editor consumes the SDK output.

git clone https://github.com/mlt131220/Astral3D.git

cd Astral3D
pnpm install
pnpm run sdk:build
pnpm run editor:dev

After pnpm run editor:dev the dev server for packages/editor starts. The README does not print the port, so read the terminal output rather than assuming a number. For a production bundle the README gives a single command, which again builds the SDK first:

pnpm run editor:build

There is also a docs pipeline in the root scripts (docs:dev, docs:build, docs:preview) that targets packages/docs, and an examples pipeline (examples:dev, examples:build) that targets packages/examples. If you want to see the engine used without the full editor, the examples package is the shorter path, though the README does not describe what the examples contain.

Where Astral3D is the wrong tool

The README is a feature list, not a manual. It does not document rollback, version migration, the scene sub-package file format, the plugin API surface, or which features need the Java backend. The documentation centre is a separate site, so anyone evaluating the project from the repository alone is working from marketing copy plus a build script. For a team that needs to audit a dependency before adopting it, that is a real gap.

The licence is the second constraint, and it is the one most likely to be missed. The project is Apache-2.0, but the README adds supplementary terms: personal study and secondary development are allowed, a copyright notice is required, commercial use requires authorisation, and use in a business competitive with Hangzhou Xingluan Digital Technology is prohibited. A permissive OSI licence with an added commercial-authorisation clause is not the same proposition as plain Apache-2.0. If your legal review treats Apache-2.0 as pre-approved, this project will not pass that check unmodified. Read LEGAL.md and take your own advice on it; this is a description of the terms, not a legal opinion.

Finally, the roadmap items are labelled as upcoming: physics engine support, WebGPU support, data components over API and WebSocket, a low-code data dashboard, and WebSocket multi-user collaboration. None of those are available today according to the README, so do not plan around them.

Astral3D compared with other browser 3D editors

The obvious alternative for a Three.js-based editor is the official Three.js editor, which ships with the library. It is a scene inspector and a light authoring tool: you add primitives, tweak materials, and export. It has no BIM or CAD import path, no plugin marketplace, no particle or weather system, and no backend. If your job is arranging GLTF assets, the Three.js editor is smaller and has no licence complications beyond Three.js itself.

The difference in approach is the file pipeline. Astral3D positions itself as the tool that ingests RVT, IFC, DWG and DXF and turns them into something a browser can render, which is a conversion problem rather than a scene-graph problem. That is also why the project carries a backend repository and a commercial clause: the hard part is not the editor UI, it is the format conversion, and the authors have chosen to license that part differently. Pick Astral3D when the input files are the problem. Pick the Three.js editor, or write directly against the Three.js loaders, when they are not.

Maintenance, upgrade cost and what the licence means in practice

The repository is not archived and the last push was on 2026-09-22, six days before this writing. The single release in the list is 1.0.0, tagged Astral 3D Engine, dated 2025-10-04. So the project is publishing code, but it is not publishing versioned releases at a cadence you can plan upgrades around: between October 2025 and September 2026 there is one release entry. If your process depends on semantic version tags rather than branch commits, you will be tracking main.

The dependency surface is a factor in upgrade cost. Three.js r176, Vue 3.5.22, Naive UI 2.43.1 and UnoCSS 0.46.5 are pinned in the README badges, and Three.js in particular moves quickly and breaks things between revisions. Upgrading Three.js inside an editor that also does RVT and IFC conversion is not a routine bump, and the README gives no compatibility statement for other Three.js revisions.

On licensing: Apache-2.0 covers the code, and the README's supplementary terms add a commercial-authorisation requirement and a non-compete restriction aimed at one named company. For an internal tool at a company outside that business, the practical question is whether your organisation accepts an added authorisation step. For anything customer-facing or revenue-generating, read LEGAL.md before you write code against this, and get your own legal review rather than relying on the README summary.

Editorial conclusion

Adopt Astral3D if you need a browser editor that opens RVT, IFC, DWG and DXF next to the usual GLTF and FBX formats, and if you can live with a README that stops at pnpm run editor:dev. Do not adopt it as a drop-in replacement for a mature Three.js scene editor: the editor package is large, the documentation lives on a separate site, and the licence adds a commercial-authorisation clause on top of Apache-2.0. Before you commit, read LEGAL.md, check whether the RVT and DWG import paths need the AstralService backend, and confirm that Node.js 23.x is acceptable on your build machines.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mlt131220/Astral3D on GitHub
3. Project website
4. README
5. Releases