Filament vendors publish settings as slicer profiles in at least five incompatible vocabularies — Cura fdm_material XML, PrusaSlicer INI, Orca/Bambu JSON, OFD JSON, datasheet PDFs. None of them can carry a mechanical test result, and a mechanical-test paper can rarely be joined back to a purchasable product. The settings world and the properties world do not meet.
Open3DPP is the join: identity, composition, process, geometry, structure, properties, moisture and provenance in one flat, analysis-ready record. Every column has exactly one name, one unit and one meaning. Absent means unknown — a field is omitted rather than zero-filled or guessed.
Material identity plus process conditions do not determine printed properties. The same filament at the same settings yields different strength in different part geometries, because geometry sets the thermal and load context: layer time drives the interlayer healing window; feature size and thermal mass drive cooling rate and crystallinity; orientation drives anisotropy. A settings-only format structurally cannot carry this, which is why Open3DPP exists alongside spool-tag formats rather than competing with them.
The useful value is goal-dependent: studies report interlayer strength increasing toward the upper part of a vendor range, while vendors also cap the range for surface quality and dimensional control. Open3DPP preserves both endpoints for nozzle, bed and chamber so the trade-off stays visible to the analyst instead of collapsing to a midpoint. This is a data-modelling rationale, not printing advice.
| Identity | 19 |
| Composition | 23 |
| Process | 37 |
| Geometry | 18 |
| Structure | 8 |
| Properties | 17 |
| Moisture | 11 |
| Provenance | 19 |
Equipment, environment, measurement method and external artifacts are deliberately outside a core record: a core row is one observation, and that context describes the run which produced it. Three sidecar schemas carry it, each referencing a core record and versioning independently — so a core release never invalidates a sidecar, and a record is complete without one. Read the addendum →
Schemas are version-exact: schema_version is pinned by
const and unknown properties are rejected, so validate a
record against the schema matching its own version. There is
deliberately no latest alias — a moving pointer would
break every consumer the moment a version shipped.
check-jsonschema --schemafile \
https://open3dpp.org/schemas/core/v0.1.0/open3dpp-record.schema.json \
my-record.json