PicoGK is a deliberately small geometry kernel, and the reduction is the point

A reduced instruction set, stated as a deliberate choice

PicoGK, pronounced peacock, is described as a compact, open source geometry kernel developed by LEAP 71, and it serves as the foundation of a broader technology stack for Computational Engineering, a paradigm the company says it pioneered.

The name stands for Pico, meaning tiny, Geometry Kernel, and the README is explicit about the design intent. The library offers a deliberately reduced yet powerful instruction set designed to create computational geometry for engineering applications, and it links to an article about the power of reduced instruction sets to make the argument.

That is the defining characteristic and it deserves to be read as a constraint rather than as a limitation. A general purpose CAD kernel exposes hundreds of operations, each with options, and the surface area is where the complexity lives. A reduced instruction set is a bet that a smaller set of primitives, composed well, covers the same ground, and that a smaller surface is easier to learn, easier to keep correct and easier to make fast.

The README also notes that while it may appear minimal on the surface, PicoGK is used to generate advanced physical components, from electric motors and heat exchangers to 3D printed rocket engines and bio-inspired structures. The claim is that the output is not minimal even though the interface is.

The licence is Apache-2.0, which is a permissive grant with an explicit patent clause and is the right choice for a library intended to sit under other people's engineering tools.

The repository is organised by concern, and the folders describe the kernel

The top level of the repository is a C# solution with a directory layout that says more about the design than a README full of feature bullets would.

There is a `Base/` directory, which in a kernel of this kind holds the foundational types, and a `Types/` directory, which is where the primitive geometry lives, the points, vectors, planes, boxes and curves that everything else is expressed in. A `Shapes/` directory sits next to it and is where the higher level objects are, the solids and the composite shapes built out of the primitives. `Numerics/` handles the arithmetic that the kernel depends on.

The rest of the tree is infrastructure, and the names are informative. `Library/` is the public surface, `Internals/` holds the implementation that is not meant to be called directly by consumers, and `Utils/` holds shared helpers. `IO/` is where reading and writing happen, and given the topic list includes OpenVDB, that directory is where the sparse volume format support lives, which is the standard interchange format for volumetric data in graphics and in additive manufacturing workflows. `Diagnostics/` is the error reporting layer, and having a dedicated directory for it in a geometry kernel is a sign of how much of the difficulty in a kernel is reporting a bad input clearly rather than producing wrong geometry silently.

`Viewer/` is a separate directory, which tells you there is a visualisation component in the same solution. `native/` is the native code, and its presence confirms the C# library is not pure managed code, which for a geometry kernel with a performance requirement is expected, since the hot paths want to be in native code with a thin managed surface.

`PicoGK.csproj` and `PicoGK.sln` are at the root, along with `assets/` for resources and an `Internals/` sibling for the private implementation.

It sits inside a wider stack, and that is the intended use

PicoGK is not presented as a standalone product but as the foundation of a broader technology stack, and the README points at the Computational Engineering material on the LEAP 71 site as the wider context.

The framing matters for adoption. If you are evaluating a geometry kernel the way you would evaluate a general purpose mesh library, the comparison will be misleading, because the library is designed to be the geometric substrate for a specific way of working, in which the design intent is expressed directly and the geometry is a consequence.

The examples given in the README point in that direction. Electric motors and heat exchangers are both objects whose complexity comes from repeated geometric operations on a parametric description rather than from a single hand-modelled solid. A 3D printed rocket engine is an object where the geometry has to be manufacturable, which means lattice structures, clearances and material constraints all have to be expressible. Bio-inspired structures point at the generative side.

The topic list reinforces this. Alongside 3dprinting, additivemanufacturing and digitalmanufacturing, there is computationalgeometry, designautomation, engineering and generativedesign, and openvdb.

The name has a second meaning worth noting because it tells you about the project. PicoGK is also a nod to the peacocks that roam the streets of Dubai, which the README identifies as the home city of LEAP 71 and the birthplace of this technology. A library that is part of a larger commercial and research effort, with a public repository and a public documentation site at picogk.org, will have a different maintenance rhythm and a different set of priorities than a hobby project, and knowing which you are dealing with helps when you file an issue.

Evaluating a kernel with a small README means reading the site

A practical note on how to evaluate this project, given how little the repository itself tells you.

The repository is a README, a LICENSE and a source tree. The README establishes what the library is, who builds it and what it is for, and then points at the project website, PicoGK.org, and the LEAP 71 Computational Engineering material for everything else. There is no API reference in the repository, no tutorial, no example code file in the top level entries, and no changelog.

That is a real constraint on adoption, and it is worth being honest about it. A kernel is a library you adopt by reading its documentation and then by reading its source, and the source here is the only artefact in the repository. The code is organised in a way that makes the architecture legible, with the primitives in one directory and the composites in another, so a reader can reconstruct the layering from the file names alone. But the names of the operations, their signatures and their behaviour live on the website.

The `Base/` directory sitting alongside `Types/` is a hint about how to read the tree. A base layer with the fundamental numerical machinery, a types layer with the geometric primitives, and a shapes layer for the higher level objects, is a classic kernel layering, and it means the first thing to check in the source is what the primitive type actually is and how it represents a curve or a plane, because everything above it depends on that choice and the representation is where the numerical behaviour comes from.

The `Diagnostics/` directory is the second place to look. For a library whose whole value is producing correct geometry for manufacturing, the error reporting tells you how much the author cared about a caller passing a degenerate input, and the presence of a dedicated directory rather than scattered exception throwing suggests the error paths were designed rather than accumulated.

So the evaluation order is the website for the API, the source tree for the representation choices, and the diagnostics for the failure modes. The `native/` directory raises one further question worth answering early, which is how the native code is built and linked on your platform, because that determines whether a C# project can consume it with no more than a package reference.

Version 2.x and a release cadence of weeks

The release history shows an active project on a version 2 line. PicoGK-v2.3.0 was released on 2026-08-05, v2.2.0 on 2026-06-05 and v2.1.0 on 2026-05-25.

The tags are `PicoGK-v2.3.0`, `PicoGK-v2.2.0` and `PicoGK-v2.1.0`, so the third component is a patch number in the usual sense and the second is the minor. What matters practically is that the project has moved through several minor versions of the 2.x line in a period of about two months, which means the API is still settling.

The last push to the repository was on 2026-08-27, roughly three weeks after the 2.3.0 tag, and the repository is not archived. So the project is being worked on between releases rather than in bursts before a tag, which is a good sign for a library that people are putting into their engineering workflows.

For a library in this position, the practical advice is to pin a version rather than track the main branch, and to read the changes between the minor versions before you take them. A kernel is exactly the kind of software where a rename in a method signature costs more than it looks, because the call sites are scattered across an engineering codebase, and a reduced instruction set makes a rename more likely to be a breaking change than in a large API where a deprecated alias is cheap to keep.

The documentation lives on the project website rather than in the repository, and the README points at picogk.org for more. The repository itself is a README plus a LICENSE and the source tree, which means a reader learns the API from the site and the code from the repository, and a new contributor would want the site open alongside the code.

Editorial conclusion

Adopt PicoGK if you are working in computational engineering in C#, you want an open geometry kernel rather than a commercial CAD kernel, and you are willing to work inside a deliberately small API. Do not adopt it as a general purpose CAD kernel, because the reduced instruction set is a design constraint rather than a limitation to be worked around, and the documentation lives on the project website rather than in the repository. Verify first that the operations your workflow needs are in the instruction set you are given, that your build can compile the native component in the native directory, and that the version you pin corresponds to the API you have read about.

Frequently asked questions

Official sources

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