amagine-ai /Amagine3D
Amagine3D: From hardware requirements to editable 3D designs
★ 6,279⑂ 536👁 56⑃ 12● 28▤ 0◈ 0
6,279
stars
+-2
536
forks
56
watchers
12
prs
28
issues
0
releases
0
discussions
README
Amagine3D From hardware requirements to editable 3D designs Amagine3D is the open-source 3D capability layer Amagine is developing for hardware creation. Give it a product description and reference images, add the key dimensions, and Amagine3D can design an enclosure and assembly structures around the internal components while producing source code that remains editable. STEP, STL, and 3MF files can be exported as needed. Capabilities · Example · Quick Start · 简体中文 From Requirements to Editable Hardware Structures Amagine3D currently focuses on printable intelligent-hardware enclosures and related structures, creating complete designs from natural-language requirements, reference images, dimensions, and existing geometry. The design process starts with internal components, arranging mounts and interfaces before creating the enclosure, controls, and thermal-management structures. When a design needs multiple parts, covers, hinges, or latches are developed together with assembly clearances and printing tolerances. For rigid mechanisms such as hinged or sliding covers, the system can also check collisions and operating clearances along a defined motion path. Every generation records one semantic scene containing its parts, features, interfaces, materials, and BRep masters. Manufactured geometry retains editable Python and build123d source and exports genuine STEP. Product envelopes start from a few key sections joined by lofts; extrusions, revolutions, sweeps, and BRep features shape the rest of the design. Ruled or segmented surfaces are useful when they preserve the intended form. The same geometry produces STL, display STEP, and a profile-bound 3MF package when required, including permanent color regions inside a physical part. Behind the scenes, the 3D-native Agent turns the request into an immutable intent and one mutable semantic scene. BRep and color exporters compile that scene into one evidence contract. The Agent sees measured dimensions and checks for feature ownership, wall thickness, print orientation, plate fit, connectivity, interference, and exported-file readback, then renders and reads the latest result before accepting it. A cavity formed by subtracting an inner loft is checked for actual wall thickness; section insets alone do not guarantee constant normal thickness. For appearance-led requests without a supplied visual reference, the workflow asks the Agent to use the selected search backend—preferably local a3d search with Tavily—to find a few relevant sources when network access is enabled. Search snippets remain untrusted leads; the Agent must actually retrieve and view any image used for visual judgment. Engineering dimensions still come from component drawings or explicit assumptions. Visual review uses the generated five-view preview (isometric, front, side, top, bottom) and requires image perception in the configured model/provider. A rendered PNG or successful text resp
Top issues
#1Support for more common component parameters to ease shell construction2 comments · 2026-08-23#30Could there be a shared session root abstraction between chat route and tRPC?1 comments · 2026-10-07#28Express security hardening deserves a note in the architecture docs1 comments · 2026-10-04#27No request rate limiting on the /api/chat endpoint — is this intentional?1 comments · 2026-10-01#39Featured Amagine3D on BrandifyDomains Showcase & Verified Asset Index!0 comments · 2026-10-27#38RFC: 为 a3d search 增加可选的 Keenable 后端(无需密钥,默认不变)0 comments · 2026-10-27