FllumaOne: Code-Native Multimodal CAD Dataset

• FllumaOne is a code-native multimodal CAD dataset for editable parametric CAD research, featuring executable programs, structured feature histories, aligned visual renderings, and kernel-validated geometry.
• It comprises 100,000 samples organized into four complexity regimes and validated through a rigorous multi-stage process ensuring complete, executable, and geometrically sound releases.
• The dataset supports diverse tasks such as text-to-program synthesis, image-to-CAD reconstruction, point-cloud reverse engineering, and feature-tree prediction for design editability.

Searching arXiv for the specified paper to ground the article in the source record. FllumaOne is a code-native multimodal CAD dataset for research on editable parametric computer-aided design, defined by the joint availability of executable construction programs, structured feature histories, kernel-validated geometry, and aligned multimodal observations (Zhan, 16 Jun 2026). In contrast to repositories that expose only meshes, B-Reps, or other final-shape artifacts, FllumaOne treats the canonical CAD record as an ordered construction history with operations, parameters, and dependencies. Its primary release, FllumaOne-100K, contains 100,000 accepted samples generated in Flluma, a Qt/C++ OpenCASCADE-based CAD system, and packaged with executable Python code, feature trees, a compact training IR, STEP geometry, point clouds, renderings, natural-language descriptions, and metadata (Zhan, 16 Jun 2026).

1. Conceptual basis and motivation

Parametric CAD encodes not only the final solid but also the ordered modeling process by which that solid is produced. FllumaOne was created to address the gap between datasets that reproduce a boundary representation and datasets that preserve the construction history needed for editability, variant creation, manufacturing analysis, and reverse engineering (Zhan, 16 Jun 2026). The paper defines the resource as “a code-native multimodal CAD dataset with executable programs and kernel-validated feature histories,” emphasizing that editable CAD learning requires access to modeling operations, parameters, feature dependencies, and validated geometry rather than final geometry alone.

The central representational claim is that a mesh or final B-Rep can reproduce the boundary while omitting design intent, operation order, and dependencies. Within the paper’s framing, this omission is the primary limitation of many prior CAD corpora. FllumaOne therefore centers the dataset on an inspectable construction record paired with replayable executable code and kernel-validated geometry. This suggests a shift from purely geometric recognition toward models that can reason over procedural, topological, and semantic structure in a unified way.

A closely related misconception is that “CAD understanding” can be reduced to shape reconstruction. FllumaOne explicitly rejects that reduction: the dataset is designed for editable CAD research, where the recoverable object is a modifiable feature history rather than only a visually similar or topologically valid terminal shape (Zhan, 16 Jun 2026).

2. Code-native architecture and multimodal alignment

Each accepted sample aligns multiple modalities that describe the same accepted CAD record. The included artifacts are: an executable Python CAD program, a structured feature tree, a compact training IR, STEP geometry, a surface point cloud, natural-language descriptions, metadata/provenance, and eight canonical visible-edge renderings (Zhan, 16 Jun 2026). The code-native property is fundamental: the model is represented as Python code executed in Flluma, not merely as text annotations attached to geometry.

The paper specifies the role of each aligned file type.

Component	Role
program.py	Executable source used to generate and replay the model
feature_tree.json	Ordered modeling operations, semantic roles, parameters, dependencies, and topology references
training_ir.txt	Compact serialization of the same construction history
model.step	Kernel-exported standard CAD geometry
point_cloud.npz	Surface point cloud with normals and face identifiers
images/canonical/	Eight feature-aware visible-edge renderings
text/descriptions.json	Deterministic descriptions and structured CAD facts
text/llm_descriptions.jsonl	LLM-enriched captions, technical descriptions, and user prompt variants
metadata.json	Hashes, validation summaries, sample statistics, and provenance

This alignment is not a collection of independent annotations. The paper states that the feature tree can be replayed in Flluma and converted back into executable Python code, while the renderings, point cloud, and STEP geometry are derived from the same kernel-validated construction record (Zhan, 16 Jun 2026). Consequently, predictions in one modality can be cross-checked against executable source and geometry in another modality.

The Python API is regularized for learning through explicit operation names, typed parameters, stable argument order, and direct binding of intermediate objects. This makes the executable representation more machine-readable than arbitrary user-authored scripts while remaining replayable in the CAD kernel. A plausible implication is that FllumaOne is structured not only as a data repository but also as a representational interface between procedural CAD and sequence-learning systems.

3. Release structure, scale, and complexity regimes

The primary release, FllumaOne-100K, contains 100,000 accepted samples partitioned into 80,000 train, 10,000 validation, and 10,000 test (Zhan, 16 Jun 2026). It is built from 53 template/category families. The model-facing vocabulary uses 44 operation tokens, while the feature-tree representation uses 60 feature-tree operation labels.

A defining organizational principle is the use of four template-level complexity regimes—L1, L2, L3, L4—assigned at the template level before generation, with each sample inheriting the regime of its source template. The target allocation is L1: 3,000 samples, 3%, L2: 17,000 samples, 17%, L3: 55,000 samples, 55%, and L4: 25,000 samples, 25%. The realized counts are L1: 3,056, L2: 16,966, L3: 55,219, and L4: 24,759, and the realized proportions stay within 0.25 percentage points of their targets (Zhan, 16 Jun 2026).

Regime	Realized count	Characterization
L1	3,056	Primitive or low-operation templates for syntax and geometry grounding
L2	16,966	Basic parametric feature combinations
L3	55,219	Multiple editable features and moderately involved histories
L4	24,759	Richer construction sequences, compound interactions, and more involved mechanical parts

The regime structure is reflected in summary statistics. The mean feature count rises from 1.000 in L1 to 6.620 in L4, and mean B-Rep faces rise from 5.616 to 38.737 (Zhan, 16 Jun 2026). This regime design is consequential because it introduces a controlled progression from syntax and geometry grounding toward richer procedural complexity, rather than relying on post-hoc difficulty estimates derived from final geometry alone.

4. Validation pipeline and release integrity

FllumaOne accepts samples only after a multi-stage validation process. The stated pipeline is:

1. Template scheduling and candidate generation
2. Deduplication by canonical construction signatures
3. Execution in Flluma
4. Kernel-level geometry validation
5. STEP export / reload checks
6. Packaging of aligned multimodal outputs (Zhan, 16 Jun 2026)

The validation target is not merely syntactic correctness of Python code but a kernel-accepted B-Rep solid. The paper specifies that modeling operations are resolved to OpenCASCADE B-Reps, Boolean operations use BRepAlgoAPI family operators, the resulting shape is checked with the OCC B-Rep check analyzer at the face/edge/vertex level, volume and surface area are computed with BRepGProp, and STEP export/reload checks use STEPControl writer and reader APIs (Zhan, 16 Jun 2026).

The release-level integrity report is unusually explicit. It records:

• 100,000 complete samples
• 0 incomplete or unstable samples
• 0 duplicate program hashes
• 0 duplicate feature-tree hashes
• 0 duplicate training-IR hashes
• 0 duplicate solid-signature hashes
• 77 duplicate-signature retries
• 0 unrecovered generation failures
• no missing required file types
• no unstable or unreadable files (Zhan, 16 Jun 2026)

The final manifest also records 100,000 evaluated release slots and 77 retries caused by duplicate construction signatures, with no unrecovered failures. In practical terms, this means that multimodal alignment is backed by kernel execution and release auditing rather than inferred correspondence alone. This suggests that FllumaOne is intended to support not only training but also rigorous failure analysis, reproducibility checks, and modality-consistency evaluation.

5. Baseline model and reported evaluation

The baseline task is text-to-program generation: a natural-language CAD description is mapped to executable program.py. The paper fine-tunes Qwen2.5-Coder-1.5B-Instruct with LoRA on the official 80,000-sample training split (Zhan, 16 Jun 2026). Training details are: one epoch, max context length 4096, learning rate $2\times10^{-4}$, cosine scheduling, warmup ratio 0.03, LoRA rank 16, LoRA alpha 32, dropout 0.05, effective batch size 8, FP16 with TF32 enabled, and training time 27,318 seconds on one 16-GB NVIDIA RTX 5060 Ti.

On the 10,000-sample held-out split, the reported results are:

• Train loss / validation-subset loss: 0.0878 / 0.0766
• Python syntax-valid rate: 99.98%
• Required part definition rate: 99.98%
• Flluma load rate: 99.97%
• Flluma build rate: 99.97%
• Kernel solid-valid rate: 99.14%
• STEP-export-valid rate: 99.14%
• Chamfer-evaluated samples: 9,909
• Mean / median Chamfer Distance: 0.002124 / 0.001491
• P90 / P95 Chamfer Distance: 0.003502 / 0.004854
• Maximum Chamfer Distance: 0.180119
• Mean source-code similarity: 87.34%
• Operation precision / recall / F1: 99.97% / 99.95% / 99.96%
• Operation LCS ratio: 99.94% (Zhan, 16 Jun 2026)

The paper explicitly qualifies the operation-level metric: the high operation F1 is partly due to comparison by multiset overlap of API call names, without scoring argument values or call order. Order is instead measured by the operation LCS ratio (Zhan, 16 Jun 2026). Geometry quality is reflected through normalized Chamfer Distance. The normalization is defined by subtracting the reference bounding box center from both point clouds and dividing both by half of the reference box’s largest side length, so that the normalized reference spans two units along its longest axis. This evaluation design separates executable validity, operation-level agreement, and geometric similarity into distinct criteria rather than conflating them.

6. Supported research tasks and technical significance

FllumaOne is intended to support a broad set of editable-CAD tasks (Zhan, 16 Jun 2026). These include Text-to-CAD and CAD program synthesis from natural-language prompts or technical descriptions to executable Python, feature trees, or training IRs; Image-to-CAD reconstruction using the eight canonical visible-edge views as conditioning; Point-cloud-to-CAD and editable reverse engineering for recovering structured histories and programmatic CAD from point clouds; Feature-tree prediction and design auto-completion for predicting operations, parameters, dependencies, and next actions from partial histories; Cross-modal CAD retrieval from text, images, or geometry; and B-Rep feature extraction and manufacturing-oriented analysis for recognizing holes, pockets, bosses, chamfers, fillets, and repeated feature patterns from STEP geometry and aligned history.

The practical workflow orientation is explicit. The paper describes scenarios in which a scan-derived point cloud is mapped back to a modifiable feature history, and in which aligned feature trees plus STEP B-Reps help associate geometry with manufacturing decisions (Zhan, 16 Jun 2026). Because all modalities are tied to a single executable construction record, the dataset can support evaluation of whether a recovered design is not merely shape-compatible but also procedurally coherent and editable.

The broader significance of FllumaOne lies in its redefinition of what constitutes a CAD sample for machine learning. Instead of treating geometry as the sole ground truth, it jointly exposes construction logic, validated geometry, renderings, point clouds, and text. A plausible implication is that future CAD models trained on this resource may be evaluated not only on geometric reconstruction accuracy but also on replayability, feature dependency recovery, editability, and kernel-level validity. Within the paper’s own framing, that combination is the main novelty of the dataset and the basis for its use in conditioned CAD reconstruction, executable program synthesis, feature-tree prediction, B-Rep analysis, retrieval, design completion, and editable reverse engineering (Zhan, 16 Jun 2026).