openNURBS reads and writes 3DM files without a Rhino licence

A 3DM file format library, not a CAD application

The openNURBS Initiative publishes C++ source code whose job is to read and write openNURBS 3D model files, the format with the .3dm extension. The repository description states the point directly: the libraries let anyone read and write the 3DM file format without needing Rhino. That is a narrow and useful promise. A company building a viewer, a converter, a web front end for geometry, or an automated pipeline has usually run into the same wall, where geometry arrives from a Rhino user and there is no way to open it except by installing the commercial application that wrote it. openNURBS removes that dependency. The README adds that more than 400 software development teams and applications, Rhinoceros among them, exchange 3D models using the openNURBS file format, which explains why the format is treated as an interchange target rather than a private format. It also explains the shape of the audience, developers at CAD, CAM, CAE and graphics companies who need geometry to move between applications accurately.

File format code and NURBS evaluation live in the same tree

Look at the top-level entries and the scope becomes clear. Alongside the format layer, with files such as opennurbs_3dm.h, opennurbs_3dm_attributes.cpp, opennurbs_3dm_properties.cpp, opennurbs_3dm_settings.cpp and opennurbs_archive.cpp, there is a geometry layer with per-curve and per-surface sources: opennurbs_arc.cpp, opennurbs_bezier.cpp and opennurbs_beam.cpp among them, plus opennurbs_bounding_box.cpp, opennurbs_bitmap.cpp and the base array and archive machinery. The README describes the Toolkit as providing NURBS evaluation tools and elementary geometric and 3D view manipulation tools on top of the file format code. So a caller can do two distinct jobs: read a document into memory, or evaluate a NURBS curve or surface directly to get points, derivatives and the like. The header set exposed through opennurbs.h and opennurbs_3dm.h is what a consumer program includes, and everything is C++ with a compile-time include path and automatic linking, which is a heavier coupling than a C API would give you.

Building the 8.x branch from opennurbs_public.sln

The getting started steps are short enough to quote. You clone the repository, open opennurbs_public.sln, pick a platform and a configuration, and rebuild everything, then create a C++ project that will use opennurbs. Those steps carry an assumption worth naming: a Visual Studio solution is the primary build path. The repository also carries a CMakeLists.txt and a makefile at the top level, so a non-Microsoft build path exists, but the README does not walk through either one, and it does not document the supported compiler list locally. The README instead sends readers to the Getting started guide on developer.rhino3d.com for supported compilers, build instructions and a description of the examples. Practically, expect the first build to be the slow part: a full rebuild of a large C++ geometry library, with no published binary packages, no container image and no GitHub releases to download, since the repository has none. There is a plugin and mobile footprint too, with an opennurbsRhino_iOS.xcodeproj directory, an opennurbsRhinoInfo.plist and an android_uuid directory, but none of that is described in the README.

Wiring the header into a consuming project with pragmas

Once the library is built and installed, the consumer side is a small set of defines in stdafx.h. The README gives the block and instructs you to replace the install path with the full path where you installed openNURBS, using forward slashes as directory separators:

    // defining OPENNURBS_PUBLIC_INSTALL_DIR enables automatic linking using pragmas
    #define OPENNURBS_PUBLIC_INSTALL_DIR "<MY_INSTALLPATH>"
    // uncomment the next line if you want to use opennurbs as a DLL
    //#define OPENNURBS_IMPORTS
    #include "<MY_INSTALLPATH>/opennurbs_public.h"

Two things fall out of those four lines. The first is that the install location is baked into the source as a macro, so shipping a build to another machine means changing that path, and the comment makes clear the macro exists so the header can trigger automatic linking with compiler pragmas rather than forcing you to write a project file with the right library paths. The second is the choice between static linking and a runtime DLL, controlled by a single commented define, OPENNURBS_IMPORTS. If you take the DLL route you have to solve deployment yourself, because the README does not document which runtime libraries ship alongside the binary, how the DLL is located at load time, or how version mismatches behave. The example programs in the tree also use a header called examples_linking_pragmas.h, which suggests the pragma approach is the intended pattern across the sample code.

The example programs are the documentation

Because there is no separate docs tree, the examples do the teaching. The repository has a directory for each capability: example_read, example_write, example_brep, example_convert, example_roundtrip, example_gl, example_test and example_userdata. Reading the directory names tells you the shape of the API surface. There is a reader and a writer, a BRep example that deals with boundary representation data, a converter, a round-trip example that is the obvious first thing to run because it writes what it just read, a GL viewer for a visual check, a test harness and an example for user-defined data. There is also a collection of example 3dm files in example_files/ that the README offers for testing, which means you can validate a build against known-good documents instead of manufacturing geometry first. The shared header examples.h sits at the top level next to examples_linking_pragmas.h. The one thing to keep in mind is that the description of each program lives on the external Getting started guide, so the repository gives you compilable code and sample data while the narrative explanation is hosted elsewhere.

Where openNURBS is the wrong tool

It is easy to reach for this library expecting a CAD kernel and finding a format library instead. Nothing in the README describes modelling operations, feature creation, constraint solving or a modelling user interface, and the stated scope is transferring 3D geometry between applications, so a request to build a solid, trim a surface or run a boolean is out of scope. The second limit is the format itself. Reading and writing 3DM means interoperability with the openNURBS ecosystem specifically, and a pipeline that only ever exchanges STEP or other neutral formats has no need for it. Third, the build story is a real cost for a team outside the Visual Studio world: the README's own walkthrough is Visual Studio based, and the CMakeLists.txt and makefile in the tree are not explained. Fourth, there are no GitHub releases, so a consumer has no version to pin, no binary to download and no upgrade notes to read. The README also does not document a rollback procedure, a compatibility policy between openNURBS versions, or which file format revisions the toolkit writes.

Direct format access against conversion through an intermediate format

The architectural choice worth comparing is not between libraries but between two strategies for interoperability. One strategy is a hub: every application converts to a neutral intermediate format, and the converters do the translation. The other is direct access to a native format, as openNURBS provides, where an application links the format's own reader and writer and reads a 3DM document as a first-class object model rather than as an export to be interpreted later. The trade is sharp in both directions. Direct access preserves more, because the data model of the source application, its NURBS surfaces, its attributes and its user data, stays intact instead of being flattened into a middle representation, and it removes the converter from the critical path, so there is one less place for geometry to be altered. Against that, direct access binds your program to one vendor's data model and its library's build and licence terms, and every update to the format becomes your maintenance work. The hub strategy is easier to leave and easier to serve heterogeneous inputs, at the price of lossy conversion and the operational weight of running converters. Which one wins depends on whether you need fidelity to a specific authoring tool or reach across many.

A custom licence and a last push on 2026-10-20

Two maintenance facts define the risk. The repository is not archived and the last push was on 2026-10-20, with the default branch named 8.x, so the code is being worked on, but there are no GitHub releases, which means no version tags, no published binaries and no changelog to review before you upgrade. You track a moving branch, and the upgrade cost is a rebuild plus your own regression pass against the sample 3dm files in example_files/. The second fact is the licence. The project page lists the licence as a custom one that GitHub cannot classify, and a LICENSE file sits at the top level next to the CMakeLists.txt, so the terms are defined in the repository rather than in a standard header. For a library that is meant to be linked into commercial CAD, CAM and graphics products, that distinction is not cosmetic, and the README section on the initiative does not summarise what the grant allows, whether it carries copyleft obligations, or whether redistribution of modified versions has conditions. Read the LICENSE file and have your own counsel interpret it before you ship a binary that links openNURBS, because a build dependency quietly inherited from a build system is exactly the kind of thing that surfaces during due diligence instead of during development.

Editorial conclusion

Adopt openNURBS when your product has to read or write the native 3DM format, or when it must evaluate NURBS geometry that a Rhino file carries, and your team can build a C++ library from source. Do not adopt it as a modelling kernel, as a general CAD replacement, or as a way to avoid licensing a CAD application entirely, since the README offers a file format library and evaluation tools rather than modelling commands. Verify three things first: the terms in the LICENSE file, which GitHub cannot classify, the toolchain your build environment actually supports, and how you will version a dependency that has no tagged releases, since the default branch is 8.x and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. Issues
2. mcneel/opennurbs on GitHub
3. Project website
4. README