QymCAD: a parametric Rust CAD on an OpenCASCADE B-rep kernel

Sketch, part, assembly, one project file

QymCAD is a desktop CAD for mechanical parts and assemblies, aimed at housings, brackets, mechanisms and printed or milled work. The tagline is the workflow: sketch, then part, then assembly, in one program with one project file, no cloud and no subscription.

The modelling model is the familiar parametric one, and the README describes it precisely. A sketch becomes a solid by extruding, revolving or sweeping, and the solid then takes holes, fillets, a shell and patterns. Parts come together into an assembly through joints, and the listed joint types are revolute, slider and rigid. The model is parametric in the strong sense: change a dimension in any operation and everything below it in the timeline rebuilds, the assembly included.

That last clause is the one that matters. A rebuild that propagates through the assembly is what makes the tool a CAD rather than a modeller, because a change to a part that other parts depend on has to propagate to the assembly, to the joints, and to the interference check, and a tool that gets that wrong gives you a model that looks fine and is wrong.

The associated reference is described as associative. A sketch can be placed on the face of a neighbouring part as an associative reference, so change the neighbour and the dependent part rebuilds. That is the same principle applied at the assembly level rather than inside one timeline.

The programme is written in Rust, the interface is available in English, Kazakh, Ukrainian and Russian, and the homepage is cad.qymis.tech. The author is Denis Kazachenkov, and the company behind it is QymIs Tech.

Exact solids on the OpenCASCADE kernel, and STEP with everything else

The geometry engine is the technical centre of the project. The README says the geometry is exact and solid, B-rep, computed by the OpenCASCADE kernel, the same one FreeCAD runs on.

The consequences of that choice are concrete. You get precise surfaces instead of meshes, correct fillets, and exchange through STEP with other CAD systems. That is a different world from a mesh-based modeller, where a fillet is a visual approximation and a STEP export is not possible at all. If you intend to send a part to a machinist or a 3D print service that reads STEP, this is the part of the project that decides whether you can.

The kernel is OCCT 7.9.3, and the project is specific about what it takes to build it. On Linux the command is `just pkg-linux` with Docker required, on Windows it is MSVC with the kernel built from source, and on macOS the kernel is built from source as well and then packaged with `packaging/macos/bundle.sh`.

The reason for building from source rather than using a system package is spelled out in the README, and it is worth knowing before you switch anything. A system OCCT package may differ in three ways that matter. It may be another version, in which case you get a warning at build time because the programme is written and tested against 7.9.3. It may have `BUILD_RELEASE_DISABLE_EXCEPTIONS` left at `ON`, which compiles OCCT's own checks out, so a degenerate input is no longer refused. And it may not convert signals, so the `OCC_CONVERT_SIGNALS` behaviour is absent and a fault inside OCCT closes the programme instead of being refused.

Those are not pedantic differences. Turning off the exception checks in a geometry kernel means the kernel stops validating its own input, which is the sort of thing that turns a modelling mistake into a crash.

The licence structure is worth noting too. The code is AGPL-3.0-or-later, so a fork and any derived build stay under the same licence with open sources. The OpenCASCADE kernel comes under LGPL-2.1 with an exception and is linked dynamically, and the fonts and icons have their own licences, all listed in THIRD-PARTY-NOTICES.md, which is placed beside the programme in every package.

The document format breaks on every release, and a script brings it forward

The status section of the README is unusually blunt, and the first item is the one that will affect you most.

The document format changes with no backward compatibility. A file saved by an earlier version may not open. The project describes itself as a development build that works and is fit for real parts but is updated daily, and the format consequence is the price of that.

The recovery path is a script at the repository root, `convert_qcad.py`:

python3 convert_qcad.py part.qcad    # converts in place, keeping part.qcad.bak beside it

The script brings a document forward from any earlier version in one pass, and it is idempotent, so running it twice changes nothing the second time. The backup behaviour is the practical part: it converts in place and keeps `part.qcad.bak` beside the file, so the original survives.

For a project that saves as `.qcad`, this is a real workflow constraint. A part you modelled today may not open in tomorrow's build, and a part you modelled last year may need a conversion script to be usable at all. If you keep a library of designs, the habit to build is to convert a copy before opening it, check the result, and keep the backup, rather than converting the only copy in place and trusting it.

The other two status items are about the platform rather than the format. The CNC, or CAM, module does not work. The settings do carry a Machining tab with a CAM checkbox, but what is behind it is groundwork, part of the code came from an earlier version and is not maintained, and the module returns for the stable alpha. On macOS the build carries no Apple signature, so macOS marks a downloaded application as quarantined and refuses to open it, saying it is damaged, which it is not. The mark is cleared once with one command, written out step by step in the notes inside the archive.

What the modelling feature set actually covers

The feature list is long and worth walking through in detail, because the gaps in it are as informative as the entries.

Sketching covers lines, arcs, circles, ellipses, splines, polygons, slots and text. Constraints and dimensions are solved together, and dimensions are parametric, so a dimension can be an expression such as `w/2` or `sin(a)` rather than a number. There is construction geometry and the projection of a body's edges into the sketch, which is how you place a hole on a curved face without the two drifting apart.

Parts cover extrude, revolve, sweep, loft, fillet including a variable radius set at vertices, chamfer, shell, draft, holes in plain, counterbored and countersunk form, thicken, patch, stitch, trim, split of faces and of a body, face copy and face push, linear and circular patterns, mirror, booleans, and the primitives box, cylinder, sphere, cone, torus and prism. Threads are built from a real helical profile with run-outs, which is the difference between a thread that looks like a thread and one that a machining tool can cut.

Assemblies cover parts and sub-assemblies, joints of the types rigid, revolute, slider, cylindrical, planar, ball, pin-slot and parallel, limits and drives, degrees of freedom, and an interference check.

Exchange covers STEP, STL, and DXF and SVG for sketches, all of them import and export. Either the whole project or a single part or sub-assembly picked in the tree can be written out, which is the workflow that makes a library of parts reusable.

The project tree backs this up with example files you can open: `Filter-v2.qcad`, `QymBoxPc-Case.qcad`, `Table_CNC_WORK.stp`, `plate.dxf` and `rama_cut.dxf`. A STEP file, a DXF file and two project files in one examples directory is a reasonable sample of the exchange paths in use.

The documentation is in `docs/help` with illustrations, and the built-in help opens with F1.

A workspace where the lint rules are the interesting part

The Cargo workspace lists nineteen crates, and the split maps onto the architecture of the application.

The core is `qymcad-core`, with `qymcad-kernel` as the OpenCASCADE binding layer, then `qymcad-io` for file and exchange, `qymcad-scheme` for the document format, `qymcad-paths` for path resolution, and `qymcad-i18n` for the four languages. The feature crates are `qymcad-sketch`, `qymcad-part` and `qymcad-assembly`, with `qymcad-render`, `qymcad-pick` and `qymcad-ui-state` for the interface, `qymcad-help` for the built-in documentation, `qymcad-update` for updates, `qymcad-meshfit` for mesh related work, `qymcad-testkit` and `qymcad-acceptance` for testing, and `qymcad` and `qymcad-shell` as the application and its shell. There is a `library/` directory at the top level alongside `machines/`, `examples/`, `i18n/`, `packaging/`, `posts/` and `tools/`.

What is genuinely interesting is the comment block in the workspace manifest, which the author calls the most important thing in the file. The project had 175 warnings, and real trouble drowned in them twice: an F1 that never reached five written articles, and a dimension field refusing in silence while the text explaining it stood ready beside it. Both times the compiler said it plainly, with a never used warning, and both times it was inaudible among a hundred unused return value lines from the headless checks.

The fix is two lint rules at the workspace level. `dead_code` is the guard on what was never wired up, so a function written but never given a path from the interface turns the build red the same minute rather than a month later. `unused_must_use` holds down the thrown-away results that were making everything else invisible.

The rule lives in the manifest rather than in the source on purpose. A `deny(warnings)` attribute in the code would get in the way of working, since something half-written would stop compiling in the middle of an edit, whereas in the manifest the ban strikes the finished tree and leaves local work alone, so `cargo check` shows the error where the warning would have been shown.

That is a small thing that says a lot about the project. A CAD where a dimension field can silently stop working is a CAD that quietly produces wrong geometry, and this is an unusual and sensible defence against it.

Against FreeCAD and against a cloud CAD service

The comparison worth making is with FreeCAD, since QymCAD uses the same kernel, and with a hosted CAD service.

FreeCAD is the reference point because the geometry engine is identical. The difference is everything above the kernel. FreeCAD is a large, long-lived project with a plugin ecosystem, a Python scripting layer and a parameter-driven model that is closer to a spreadsheet than to a timeline. QymCAD is a newer, smaller programme with a Rust core, four languages in the interface, a timeline model where changing a dimension rebuilds everything below it, and a document format that is not backward compatible.

That last point cuts both ways and is the key trade. A format that changes with no compatibility layer is hostile to a decade of accumulated design work, and it is also what lets the programme be updated daily without carrying a migration layer for every historical feature combination. QymCAD has taken the second option and shipped a conversion script as the escape hatch, which is a coherent position for a project that is still finding its shape, and a bad one for a studio with an existing library of parts.

The other FreeCAD difference is the language and the interface. A Rust core with a `dead_code` lint enforced at the workspace level is a very different engineering discipline from a large C++ and Python codebase, and it shows in the shape of the feature list, which is broad in a CAD sense and shallow in a community sense. There is no plugin system mentioned, no scripting API described, and no object types beyond the primitives, holes and threads listed.

Against a cloud CAD service the difference is the obvious one, and the README states it plainly with no cloud and no subscription. A browser CAD with a shared project database is the right answer when a team needs to work on the same model together and the hardware is a laptop with no GPU. QymCAD is the right answer when the model is yours, the file is a file, and the same document format works on Linux, Windows and macOS without an account. It is a desktop tool with a local file, and the STEP and STL exchange is the boundary where it hands work to everyone else.

Editorial conclusion

Adopt QymCAD if you want a single desktop program for sketches, parts and assemblies with exact B-rep geometry, STEP export and no cloud dependency, and if you can live with a document format that changes between versions. Do not adopt it if you need CAM output or long-lived archival files today, because the Machining module is unfinished and the format carries no backward compatibility, and check first that your Linux glibc is 2.35 or newer and that you run the convert_qcad.py script on any file saved by an earlier build.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. QymIs-Tech/QymCAD on GitHub
4. README
5. Releases