Mayo: an open source CAD viewer and converter built on Qt and OpenCascade

A viewer first, a converter second

The repository describes Mayo as a 3D CAD viewer and converter, and the order of those two words matters. It is not a CAD system in the sense that SolidWorks, CATIA or FreeCAD are. There is no feature tree you can drag dimensions against, no constraint solver, no history-based rebuild. What there is is a fast way to load a file produced elsewhere and look at it properly, which is a need that comes up constantly in manufacturing, reverse engineering and 3D printing.

The topic list is unusually honest about this. Alongside `cad` and `converter` there sit `3d-viewer`, `meshviewer`, `gltf-viewer` and `converter-cli`. A `brep` topic sits next to `ply` and `pointcloud`, which is the pairing that defines the whole tool: exact boundary representation on one side, discrete geometry on the other, and translation between them in the middle.

The underlying geometry kernel is OpenCascade, and the interface is Qt5. That combination is what makes the format coverage in the next section possible, because OpenCascade ships readers and writers for the CAD interchange formats that dominate engineering, and Qt provides the desktop shell, the menus and the file dialogs. Mayo is a competent front end over a well-established kernel rather than a from-scratch geometry implementation.

The formats table is the honest part of the README

Most project pages describe what they can open. Mayo publishes a table that distinguishes import from export for each format, and the asymmetry in that table is more informative than any feature list.

Round-trip formats, where you can both read and write, include STEP with AP203, AP214 and AP242; IGES v5.3; BREP, which is the OpenCascade native format; OBJ; glTF 1.0, glTF 2.0 and GLB; VRML v2.0 UTF8; STL in both ASCII and binary; AMF v1.2; PLY in ASCII and binary; and OFF. Image export to PNG and JPEG is listed as write-only, which makes sense for a screenshot feature.

Import-only formats are where the pattern becomes clear: DXF, 3MF, 3DS, FBX, Collada, X3D and DirectX. These are the formats that arrive from other ecosystems, mostly game engines and 3D printing tools, and they are read but not written. If your workflow needs to emit FBX, Mayo cannot do it, and the table says so before you waste an afternoon.

One detail worth noting is that AMF export is ZIP based, since AMF is a compressed archive format rather than a bare mesh file. That kind of specificity in a format table is a good sign about how the feature is actually implemented.

Inspection tools: clip planes, measurement, and exploding the tree

The feature list reads like a viewer, and that is the point. Mayo offers 3D clip planes with configurable capping, which is how you get inside a solid body and look at an internal face rather than staring at the outside of it. Capping matters because an uncapped clip looks like a hole; a capped one renders the cut surface solid so you can read the geometry.

Measurement is the other inspection feature, and the list of what it covers is longer than you would guess: circles, angles, lengths, areas and bounding box. Bounding box in particular is the measurement most people need first when they are trying to work out scale, whether a model is in millimetres or inches, or how big a print is going to be. Being able to read that directly off the model beats guessing from a UI scale.

Then there is the model tree. You can explode it to separate the assembly into its individual parts, and toggle the visibility of each node. For a STEP file with several hundred parts, which is ordinary for an assembly drawing, that is the difference between finding a component and scrolling through it.

The remaining items are conventional but pleasant: a view cube for orientation, thumbnail previews on the home page so you can pick a file by sight rather than by filename, and a CLI for batch conversion. The customizable mesh precision setting for BREP to mesh conversion is the one that will matter most to anyone producing assets for rendering or printing, because the default angular and linear deviation determines triangle count, file size and how faceted the result looks.

Navigation styles that imitate the tools people already know

Mayo ships several navigation styles, including ones that mimic CATIA and SOLIDWORKS. That is a deliberate choice aimed at engineers arriving from commercial CAD, where the muscle memory for orbit, pan and zoom is already established and learning a new set of mouse bindings is pure friction.

The default bindings follow the common desktop convention: left mouse drag rotates, right mouse drag pans, both buttons together zoom, and the wheel zooms as well. Window zoom is bound to Ctrl with a left drag, instant zoom to the space bar, and selection to a left click, with Shift extending the selection to multiple objects.

Listing these out is worthwhile because it is exactly the information people want when they install a new CAD tool and spend twenty minutes figuring out why the view is moving the wrong way. If you are migrating from a commercial package, check whether Mayo has a navigation style that matches it before you retrain yourself.

The `develop` default branch is another detail worth registering. Continuous integration runs on all three desktop platforms, with separate workflows for Windows, Linux on Ubuntu and macOS, and the badges in the README point at that branch. So the code is built continuously on each platform rather than only on the maintainer's machine, which for a project with native Qt bindings and a C++ geometry kernel is the minimum bar for taking the tool seriously.

Installing on Windows, and running headless on Linux

Mayo distributes release packages for Windows and Linux from the Releases page, and on Windows it is also available through two package managers. Winget gets you there in one command:

winget install --id Fougue.Mayo

Scoop users need to add the extras bucket first, then install from it:

scoop bucket add extras
scoop install extras/mayo

That two-step Scoop arrangement is normal rather than awkward. The extras bucket is where packages live that are not popular enough to warrant their own bucket, and Mayo is in it because the install is maintained but not individually prominent.

The Linux side is where the release notes get interesting, because they document a constraint that has bitten many Qt AppImage projects. The v0.10.0 Linux AppImage is built on Ubuntu 20.04 specifically for broad distribution compatibility, and the notes warn that older distributions may fail to run it as a result. The trade is deliberate: build on an older base and you cover more systems, build on a newer one and you cover fewer.

The more useful note in that same release is about headless operation. A virtual X server is only needed for operations that perform 3D rendering, which means image export specifically. Pure format conversion does not require a display, so the converter can run on a build server by prefixing the AppImage with `xvfb-run --auto-servernum` and passing the converter options after it.

That detail is the reason the CLI matters more than the word count suggests. If you have a pipeline that receives STEP files and needs STL or glTF out, this runs on a headless Linux box without a desktop session.

What the repository tells you about the project's shape

The tree is compact and conventional for a CMake C++ desktop project. `CMakeLists.txt` sits at the root with a `cmake/` directory beside it for module definitions, then `src/` for the application, `tests/` for the test suite, `doc/` for documentation and images, `i18n/` for translations, and `scripts/` for helper scripts. `CLA.md` is the contributor licence agreement, and `LICENSE.txt` holds the BSD-2-Clause terms.

The licence is worth a moment's attention because it is the permissive kind. BSD-2-Clause lets you use the code commercially, modify it, and redistribute it under your own terms, with two obligations that amount to keeping the copyright notice and the disclaimer intact. For a company that wants to embed CAD conversion into a larger desktop tool, that is the difference between a usable codebase and a negotiation.

Build instructions are deliberately not in the README. Instead it links to wiki pages for Windows, Linux and macOS, each maintained separately. That is a reasonable choice for multi-platform native builds where dependency versions differ, and it does mean the wiki is a required stop for anyone compiling from source.

Release cadence is steady rather than fast. v0.10.0 shipped on 2026-07-03, v0.9.0 on 2025-01-13, and v0.8.0 on 2023-12-20. The last push was on 2026-09-25, the repository is not archived, and there are 72 open issues on 2,237 stars. So this is an actively maintained project with roughly one meaningful release per year and continuous commits in between, which is a normal rhythm for a desktop application built on a stable C++ toolkit.

Editorial conclusion

Mayo occupies a specific and useful gap: it is the application you open when a STEP or IGES file arrives and you need to see what is inside it, check a dimension, or turn it into something a renderer can consume. It is not a parametric modeller, and the absence of modelling features is not an oversight to be sorry about. The project is at 2,237 stars with 366 forks, BSD-2-Clause throughout, and the default branch is `develop` rather than `main`, which tells you the release branch is treated separately. Install it on Windows with `winget install --id Fougue.Mayo` or from the Releases page, read the formats table before you assume your file is covered, and if you need repeatable conversions, use the CLI rather than clicking through the window.

Frequently asked questions

Official sources

1. fougue/mayo on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases