Into the 3MF Specification Wilderness: Reading 1000+ Pages of Specifications

Series: Building lib3mf-rs

This post is part of a 5-part series on building a comprehensive 3MF library in Rust:

1. Part 1: My Journey Building a 3MF Native Rust Library from Scratch
2. Part 2: The Library Landscape - Why Build Another One?
3. Part 3: Into the 3MF Specification Wilderness - Reading 1000+ Pages of Specifications
4. Part 4: Design for Developers - Features, Flags, and the CLI
5. Part 5: Reflections and What’s Next - Lessons from Building lib3mf-rs

“How hard can it be? It’s just a file format.”

That’s what I thought before I started reading the 3MF specifications. After reading, re-reading, and getting AI to help summarize and dig deeper into the interpretations and understandings, I was ready to begin.

With nine PDFs thoroughly annotated and a 325-feature matrix documented , I had a different perspective. 3MF isn’t just a file format—it’s a carefully designed system for representing the entire additive manufacturing workflow.

This is the story of spending about two weeks, in my spare time, in the specification wilderness. Each industry consortium writes documents the way they want to write it in a format they are comfortable with. I have spent many years reading specifications, and they are all different, but the 3MF are well written and easy to understand.

The Specification Landscape

The 3MF Consortium publishes nine separate specification documents :

Each specification builds on the Core, adding capabilities:

• Core: Base geometry, units, transformations, build items
• Materials: Physical properties, colors, multi-material definitions
• Production: Manufacturing metadata, part tracking, build preparation
• Beam Lattice: Lightweight structures with variable beam radii
• Slice: Pre-computed slicing data for faster printing
• Volumetric: Voxel-based property variation throughout models
• Secure Content: Digital signatures, encryption, content protection
• Boolean Operations: Constructive solid geometry operations
• Displacement: Surface displacement mapping for fine details

Over the 1000+ pages of the nine specifications, I counted 325 features.

Week One: The First Pass

I started with the Core specification. It seemed straightforward at first:

• 3MF files are OPC (Open Packaging Conventions) containers
• ZIP archive with specific structure
• XML model files following defined schemas
• Relationships define connections between parts

But as I read deeper, complexity emerged…

Coordinate Systems and Transformations

Models can define objects with local coordinate systems, then transform them when placing in the build volume. Transforms can nest—an object can be part of a component, which is part of another component, which is placed in the build.

Computing the final position of a vertex requires walking the transform hierarchy and applying matrix multiplication in the correct order.

Property Inheritance

Material properties can be defined at multiple levels:

• Default for the entire object
• Per-triangle for specific faces
• Via property groups that triangles reference
• Inherited from parent components

When a triangle doesn’t specify a property, you inherit from the parent scope. When that scope doesn’t specify, you inherit further up. The inheritance chain requires careful implementation to match specification behavior.

Units Matter

3MF supports multiple unit systems: millimeters, centimeters, inches, feet, micrometers. A model in millimeters placed in a build volume defined in inches needs proper unit conversion.

Get the math wrong, and your model prints 25.4 times too large.

The Feature Matrix

I quickly realized I needed systematic tracking. Reading wasn’t enough—I needed to document every feature, understand its purpose, and plan implementation.

I created docs/features.md , a comprehensive matrix:

Each feature entry includes:

• Feature name and description
• XML element/attribute it corresponds to
• Data types and validation rules
• Dependencies on other features
• Implementation notes

This matrix became the roadmap for the entire project.

Week Two: The Extensions

With Core specification understood, I moved to the extensions. Each introduced new concepts:

Materials Extension: Physical Reality

Materials aren’t just colors. The specification defines:

• Base materials: Name, color, physical properties
• Composite materials: Mixing multiple base materials
• Multi-properties: Different materials for different parts of an object
• Color groups: Gradients and per-vertex colors
• Texture coordinates: Mapping 2D images onto 3D surfaces

I learned that a single model could define materials that combine:

• 60% PLA with specific color
• 40% TPU with different color
• Applied as a gradient across the part
• With additional texture mapping for surface detail

The math alone for material composition ratios and color blending was more complex than I expected.

Slice Extension: Pre-Computed Paths

Modern printers can accept pre-sliced data, bypassing the slicer entirely. The Slice extension defines:

• Layer-by-layer polygon representations
• Support for multiple slice stacks per model
• References to which object each slice stack represents
• Top and bottom slice references for multi-material prints

This is what enables Bambu Studio to save entire projects—not just models, but complete print instructions.

Secure Content: Supply Chain Trust

I hadn’t expected to implement cryptographic signatures, but the Secure Content extension is fascinating:

• Digital signatures: Verify content hasn’t been modified
• Encryption: Protect intellectual property
• Certificate chains: Trust hierarchies for manufacturing
• Timestamp verification: Prove when content was signed

This addresses real manufacturing needs: How do you verify a 3D model file sent from a supplier hasn’t been tampered with? How do you protect proprietary designs while sending them to contract manufacturers?

The specification supports X.509 certificates, RSA and ECDSA signatures, and AES encryption. Implementing this meant understanding not just file formats, but cryptographic standards.

Volumetric Extension: Voxel-Level Control

The most mind-bending extension was Volumetric. Instead of defining material per-triangle, you can define material properties at every point in 3D space:

• Divide the model into voxels
• Define material composition for each voxel
• Support gradients and continuous variation
• Enable truly heterogeneous objects

Imagine printing a part where the core is rigid plastic, gradually transitioning to flexible rubber at the edges, with the transition happening smoothly throughout the volume.

This is what enables functional gradients in additive manufacturing.

Surprises and “Aha” Moments

Surprise 1: OPC is Everywhere

3MF uses OPC (Open Packaging Conventions), the same container format as:

• Microsoft Office documents (.docx, .xlsx, .pptx)
• EPUB books
• XPS documents

Once I understood OPC, I understood half of 3MF. The relationship model, content types, and archive structure all come from OPC.

Surprise 2: Backward Compatibility is Hard

The specifications evolve. Version 1.4.0 of Core must still read files created with version 1.0. Extensions can be optional—a reader that doesn’t understand Beam Lattice must gracefully ignore it and still process the model.

This means validation rules have subtlety: Some elements are required in new files but optional when reading old files. Some attributes have different defaults depending on specification version.

Surprise 3: The Specification Writers Thought of Everything

Edge cases I thought were gaps? Already addressed:

• What happens when a triangle references a non-existent vertex? (Error - must validate)
• Can you apply a texture to a beam lattice? (No - beams don’t support texture coordinates)
• What if two build items occupy the same build space? (Valid - the specification doesn’t prohibit it)
• How do you handle right-to-left languages in metadata? (Unicode direction markers)

The specifications are incredibly thorough.

The Tedium and the Excitement

I won’t lie—reading specifications is tedious. Sentences like:

“The compositematerials element acts as a container for composite material resources, where each child compositeMaterial element defines a single composite material resource.”

…require careful parsing. Is “composite material resource” a term of art? (Yes.) What’s the difference between a material and a material resource? (Resources are definitions; materials are references to resources.)

But tedium mixed with genuine excitement:

• Discovering that 3MF supports non-uniform rational B-splines (NURBS) for curved beams
• Learning that you can embed complete metadata schemas using Dublin Core
• Realizing the Displacement extension could enable procedural surface detail at print time

Each specification revealed depth I hadn’t anticipated.

The Value of Deep Reading

Spending two weeks just reading before writing any code felt slow. I was eager to start building.

But this time paid dividends:

1. Correct architecture: Understanding all nine specifications before designing meant I could create abstractions that worked across all of them
2. Fewer rewrites: I didn’t build Core only to discover Materials needed fundamental changes
3. Complete implementation: The feature matrix became a checklist—nothing was forgotten
4. Better API design: Knowing how features interact led to more ergonomic APIs

If I had rushed into coding after just reading Core, I would have built the wrong thing.

What This Enabled

By the end of the two weeks, I had:

• Complete feature matrix with 325 entries
• Understanding of all specification interactions
• Notes on implementation complexity for each feature
• Architectural decisions informed by the full landscape
• Confidence that comprehensive implementation was feasible

The specifications were no longer intimidating PDFs. They were a detailed roadmap, that will be explained in the next blog post.