# Truck Rust CAD Kernel: Installation and Crate Structure > Truck is a modular Rust CAD kernel for geometric modeling, topology, meshing, rendering, STEP handling, and JavaScript access. It is most relevant to developers who want individual Cargo crates rather than one CAD application, but the repository has no GitHub releases or documented production-readiness guidance. **ricosjp/truck** — Truck is a Rust CAD Kernel. - Repository: https://github.com/ricosjp/truck - Stars: 1,682 · Forks: 130 - Language: Rust - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/ricosjp-truck ## Why Truck Is Split Across CAD Crates Truck addresses developers who need computational geometry and CAD data structures inside software they build themselves. It is not presented as a desktop CAD program or a complete modeling application. Instead, the repository provides a workspace of focused crates for NURBS geometry, B-rep topology, polygon meshes, modeling algorithms, rendering, JavaScript access, and STEP handling. This arrangement is the project's main design decision. The README explicitly describes Truck as a collection of individually optimized crates rather than one application optimized as a whole. That choice lets a consumer depend on a narrower layer when its product does not need assembly, rendering, or STEP conversion. It also means that adopting a CAD workflow may involve selecting and integrating several crates instead of installing one executable. The workspace contains additional crates beyond those explained in the README, including `truck-assembly`, `truck-derivers`, `truck-drafting`, and `truck-stepio`. Their directory names establish their roles more clearly than their internals, though, because the README does not document their APIs or supported operations. Developers should inspect each crate rather than infer complete feature coverage from its name. ## Truck's Geometry-to-Rendering Data Path Based on the crate boundaries and dependency diagram, Truck separates representation from processing and display. At the base are `truck-base`, which provides basic structures and traits such as curve and surface traits and tolerance, and `truck-geotrait`, which defines interfaces including `ParametricCurve` and `ParametricSurface`. This is the abstraction layer for code that needs to work with geometric forms without depending on one concrete representation. `truck-geometry` supplies the concrete mathematical objects described in the README, including knot vectors, B-spline forms, and NURBS. `truck-topology` then represents CAD connectivity through vertex, edge, wire, face, shell, and solid structures. Above those layers, `truck-modeling` integrates modeling algorithms across geometry and topology, while `truck-shapeops` provides boolean operations on solids. The display path is separate. `truck-polymesh` defines polygon data and algorithms that include meshing shapes, `truck-meshalgo` handles mesh algorithms and shape tessellation, and the `wgpu`-based `truck-platform` crate provides graphics utilities. `truck-rendimpl` visualizes shapes and polygon meshes through that platform layer. `truck-js` wraps Truck for JavaScript. This separation means geometry work does not inherently require a renderer, while a visual application must coordinate topology, tessellation, mesh data, and graphics components. The repository also includes `truck-stepio`, indicating STEP input or output support. The README does not specify supported STEP versions, conformance levels, import guarantees, or export limitations, so interchange suitability cannot be inferred from the crate name alone. ## Running Truck's First Cargo Example The README does not publish installation commands for Rust or individual `truck-*` crates. It directs users to examples located within each crate and provides a first command sequence for a checkout of the repository. The `.gitmodules` file and initialization command indicate that some examples may depend on repository submodules. After obtaining the repository, initialize its submodules before running the `rotate-objects` example. The first command loads those referenced submodule contents into the checkout: ```bash git submodule update --init ``` The README then uses Cargo's standard example syntax to compile and execute the rotation example: ```bash cargo run --example rotate-objects ``` This is a development-oriented route through the repository, not a documented package installation procedure. The README also says examples exist under the `examples` directory of each crate. It does not explain how Cargo selects an example when several crates contain the same name, nor does it state what output the reader should see. Consequently, the reliable expectation is limited to Cargo locating and running the example named by the command. For library use, the README links separately to crates.io and docs.rs for the named crates, but it does not reproduce dependency declarations or version constraints. The root `Cargo.toml` is a workspace definition using `resolver = "2"`; it is not an installation template. It also applies `opt-level = "z"` only to release builds of `truck-js`, which reflects a size-oriented release profile for that wrapper rather than the whole workspace. ## Where Truck's Documentation Leaves Gaps Truck's crate map is useful, but the README is light on the details needed to judge a CAD kernel for production use. It does not state minimum supported Rust versions, supported platforms, numerical guarantees, precision behavior, file-format coverage, or compatibility policies for individual crate releases. It also does not explain whether crates share versioning or how breaking changes should be assessed. This omission matters most around geometry. Tolerance appears as part of `truck-base`, and the project centers its stated modeling direction on NURBS B-rep representation, but the README does not define tolerance semantics. It gives no examples of invalid input handling, degenerate curves, self-intersections, non-manifold solids, or boolean failures. Those are central engineering questions for a CAD kernel and cannot be answered from the README. The wording about Rust is also aspirational rather than an API contract. The README says Rust is intended to avoid process-level core dumps inherited from CPU-derived implementations, but it does not identify the referenced processes or guarantee that failures can never terminate a process. Likewise, references to Rust and WebGPU maximizing performance do not provide benchmarks, target hardware, rendering backends, or comparison conditions. Readers should treat those statements as project goals, not measured operating characteristics. The repository's `CHANGELOG.md` exists at the top level, but its contents are not included in the README excerpt reviewed here. The project should not be called actively maintained merely because that file exists. The verified maintenance signal is that the repository is not archived and its last push was on 2026-09-28. ## Truck Compared with a Single-Application CAD Kernel Truck's clearest alternative approach is a single, integrated CAD application in which geometry, topology, operations, file exchange, and display are delivered together. Truck instead makes these concerns replaceable crates. That comparison is about architecture rather than a named product, because no alternative implementation is documented in the README. The crate approach can reduce the scope of an application dependency. A command-line geometry service might use `truck-geometry` and `truck-modeling` without depending on `truck-rendimpl`. A browser-based tool can consider `truck-js`, which the README describes as a JavaScript wrapper. An application requiring solid booleans can evaluate `truck-shapeops`. None of this removes integration work, since the application must select compatible crate versions and connect the necessary APIs itself. An integrated application provides a different benefit. Its maintainers can define a supported end-to-end workflow, document how the layers operate together, and provide a consistent upgrade path. Truck's modular design deliberately gives up the idea of one globally optimized application. That is reasonable for a reusable kernel, but it shifts compatibility research and assembly work toward the adopter. The choice therefore depends on the intended deliverable. A developer creating a specialized CAD service may prefer access to narrow crates. A team seeking a ready-made modeling environment still needs a separate application layer, and the README does not claim that Truck supplies one. ## Truck Licensing, Releases, and Upgrade Work Truck is distributed under the Apache License 2.0, as stated in both the README and the repository's `LICENSE` file. That identifier is the relevant licensing fact for an engineering review. The README does not describe exceptions for examples, generated code, fonts, resources, WebGPU dependencies, or JavaScript assets, so an adopter should not infer a uniform file-by-file licensing policy beyond the repository license. There are no GitHub releases associated with the repository. The README contains tutorials and sample code for Truck's v0.6.x series, but that does not establish the current version of every workspace crate. An adopter therefore needs to inspect each crate's published package version and dependency requirements before selecting packages from crates.io. The root workspace contains 17 members and uses Rust's workspace resolver version 2. A change to workspace membership or release settings can affect how the project is built as a whole, while a library consumer may depend on only a subset. The repository layout also includes CI configuration, a `Makefile.toml`, formatting configuration, and changelog files, but the README does not document their exact release procedures. The last push was on 2026-09-28, and the repository is not archived. That indicates recent repository activity, but without GitHub releases or a documented support policy it does not establish the frequency of stable releases or the long-term compatibility burden. ## Conclusion Truck suits Rust developers evaluating a replaceable, crate-oriented CAD foundation and able to inspect individual modules against their own workloads. It is a weaker fit for teams requiring a documented release cadence, a complete turnkey CAD product, or a supported end-to-end application. Verify first that the required crates expose the geometry and topology operations your workload needs, then build the documented `rotate-objects` example with the expected Cargo toolchain. ## FAQ ### What is Truck used for? Truck is a Rust CAD kernel composed of crates for NURBS geometry, B-rep topology, modeling algorithms, solid booleans, polygon meshes, tessellation, rendering, JavaScript access, and STEP-related functionality. ### How do I run a Truck example? After obtaining the repository, the README instructs users to initialize submodules and run `cargo run --example rotate-objects`. Examples are located under the `examples` directory in the crates. ### Is Truck a complete CAD application? No. Truck is described as a modular shape-processing kernel and a collection of individual crates. The repository does not present Truck as a turnkey modeling application. ### What license does Truck use? The repository identifies Truck as licensed under Apache License 2.0. The README does not add component-specific licensing exceptions. ### Does Truck document supported STEP versions? No. The repository includes a `truck-stepio` crate, but the README does not state supported STEP versions, conformance levels, or import and export guarantees. ## Sources - [Issues](https://github.com/ricosjp/truck/issues) - [License: Apache-2.0](https://github.com/ricosjp/truck/blob/master/LICENSE) - [README](https://github.com/ricosjp/truck/blob/master/README.md) - [ricosjp/truck on GitHub](https://github.com/ricosjp/truck) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ricosjp-truck