How the 3MF Export Plugin Works
A look under the hood at what the plugin does between you clicking Export in HueForge and your slicer opening a ready-to-print .3mf.
What's Actually in a 3MF
A .3mf is a ZIP archive with a fixed internal layout. Unlike STL — which carries geometry and nothing else — a 3MF carries the entire project state your slicer needs to print:
Geometry
3D/3dmodel.model— the root XML scene, lists every object and how they assemble onto the build plate3D/Objects/object_N.model— per-object geometry for multi-volume / multi-plate prints- Vertex pools deduplicated so each volume only carries the vertices its triangles reference
Print Configuration
Metadata/project_settings.config— the slicer's full settings tree (filament temps, speeds, wipe-tower flush volumes, start/end G-code, you name it)Metadata/model_settings.config— per-part metadata (filament assignment, custom layer ranges)Metadata/custom_gcode_per_layer.xml— tool changes and pause-on-colour entries the slicer must honourMetadata/layer_config_ranges.xml— height-range modifiers (e.g. cap layer at a different layer height)
The Export Pipeline
From the moment you hit Export, the plugin runs four stages in parallel:
1. Assemble the Model
HueForge hands the plugin a mesh (or, for FlatForge / ColorDrop / Split-by-Color, a stack of per-colour meshes). Vertices are compacted so each per-colour mesh only carries the vertices its own triangles use — no full-pool duplication.
2. Build Slicer Metadata
The plugin loads the printer profile you picked, applies your HueForge layer-height + colour-stack overrides, and synthesises every .xml / .config the slicer expects. Per-filament arrays are normalised against your colour count so the slicer doesn't reject a length mismatch.
3. Serialise In Parallel
Each metadata file builds on its own worker thread; mesh XML serialisation overlaps with PNG thumbnail rendering. On a multi-mesh export every per-object file builds concurrently — saving real seconds on big colour stacks.
4. Pack the Archive
CRC and deflate run per-entry across the thread pool, then the central directory writes serially. Each ZIP entry uses a fresh z_stream so the parallel deflate stays thread-safe.
One Plugin, Five Layouts
HueForge can hand the plugin meshes in five different shapes, depending on the mode and which sibling plugin produced them. The 3MF Export plugin picks the right slicer-side layout automatically:
| Source mode | Output shape | What you get in the slicer |
|---|---|---|
| Standard print | Single object, single volume | One mesh, tool changes injected per layer for colour swaps |
| FlatForge / FlatFill | One object, N volumes (one per colour) | Each colour as its own part — slicer assigns filaments by volume metadata |
| ColorDrop (nested layers) | One object, N volumes; name-based extruder mapping | Volumes named after your filaments; the plugin matches them by longest filament-name prefix |
| Split-by-Color | One object, N volumes; count-based mapping | Same FlatForge layout, but extruder slots derived from origToUnique counts |
| HueForge tile mode | N plates, one mesh per plate, colour stack replicated | Multi-plate .3mf — each plate prints the full project independently |
Smart Profile Detection
When you click Import in the Import Template row, the plugin opens the archive you picked and figures out which slicer it came from — even across forks that share an ancestor.
Prusa Family
PrusaSlicer, SuperSlicer and QIDISlicer each brand themselves in the Application metadata inside 3D/3dmodel.model. The plugin reads that string and routes accordingly.
Bambu / Orca Family
Most Orca derivatives — OrcaSlicer, Snapmaker Orca, Creality Print, Anycubic Slicer Next, Orca Flashforge — inherited Bambu Studio's writer and still emit "BambuStudio-X.X.X" in their Application metadata. The plugin uses the version field's format inside project_settings.config instead: real Bambu Studio writes zero-padded segments (02.05.00.66), every Orca derivative uses an unpadded SemVer (2.3.0.2). Elegoo Slicer is the one exception — it brands itself in the Application string ("ElegooSlicer-1.5.1.6"), so the plugin checks for that first and falls back to the version-format heuristic for the rest.
Bulk-Config Zips
Slicers' "Export Configs" feature produces a .zip rather than a .3mf. When the archive's only top-level folder is a known slicer name (OrcaSlicer/, BambuStudio/, etc.), the plugin uses that as the detection signal — stronger than version-string heuristics for Orca forks.
Layout-Tolerant
The importer accepts profiles at the archive root OR one directory deep, so wrapped exports (OrcaSlicer/printer/MyProfile.json) work without rezipping.
What's Preserved From Your Profile
The plugin only overrides the HueForge-specific bits (layer height, first-layer height, colour stack, mesh assignment, layer-range modifiers for the cap). Everything else comes from the printer profile you imported — exactly as your slicer's owners tuned it.
Honoured
- Per-filament temperatures (nozzle + bed)
- Wipe-tower flush volumes — the calibrated matrix in your profile, not a hardcoded fallback
- Custom start / end / change-filament G-code
- AMS / CFS slot configuration and tool-changer extruder counts
- Filament settings IDs, vendor strings, and per-filament tuning
- Print process settings — speeds, shell layers, infill, retraction
Overridden by HueForge
layer_height— from your HueForge layer-height controlinitial_layer_print_height— from your HueForge first-layer controlfilament_colour+ per-filament temps for each slot in your colour stack- Custom G-code per-layer entries for tool changes and pause-on-colour overflows
- Layer-range modifier for a transparent cap when FlatForge requests one
Technical FAQ
How does pause-on-colour work when I have more colours than slots?
The plugin reads extruder_ams_count from your printer profile (or extruder_offset for tool-changer printers) to determine your physical slot count. Any colour that lands beyond that limit gets a type="1" entry in custom_gcode_per_layer.xml — the slicer pauses at that layer and waits for you to swap the filament manually.
Why is my filament with "Transparent" in its name working correctly now?
HueForge's FlatForge mode emits a cap mesh named exactly <projectName>_Transparent.stl. The plugin detects that exact filename and prepends a placeholder Transparent filament slot. User filaments containing "Transparent" in their name (e.g. "Bambu Transparent" → Project_Bambu_Transparent.stl) are not matched because the project-name prefix is followed by a filament-name token rather than the bare _Transparent suffix.
How does the plugin handle Bambu Studio's per-extruder-variant filament arrays?
Bambu profiles can ship filament_* arrays at length N or 2N (per-filament × per-extruder-variant — "Direct Drive Standard" + "Direct Drive High Flow"). Bambu Studio's slicer-side parser indexes every filament_* array by filament_colour.size() and throws std::length_error on mismatch. The plugin collapses any factor-N input to factor-1 by picking variant 0 of each filament, so every filament_* output array matches filament_colour's length exactly.
What does the plugin parallelise, and how much does it save?
Two layers of parallelism: every per-entry CRC + deflate runs through QtConcurrent::blockingMapped on the global thread pool, and every metadata builder (model XML, project settings, custom G-code, layer ranges, slice info, cut info, filament sequence) runs on its own thread via QtConcurrent::run. On multi-mesh exports the per-object XML serialisation also fans out. Wall-clock savings depend on mesh count and CPU width — biggest wins on FlatForge / ColorDrop projects with many large meshes.
Does the plugin re-render thumbnails or trust HueForge's?
It uses HueForge's thumbnail when one is provided in the export model. If absent, the plugin renders one via MeshThumbnail::render from the assembled geometry — the same code path HueForge uses internally, so the resulting PNG matches what you see in the host.
Is the file format stable across slicer updates?
Yes. The plugin targets the published 3MF Production Extension format plus each slicer's documented metadata files. Slicer-version drift is absorbed via your imported printer profile — the plugin always overlays your HueForge values on top of whatever your slicer's current schema is, rather than building from a hardcoded template.
Ready to Try It?
Skip the manual slicer setup. Save a print-ready .3mf straight from HueForge.