You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a multi-colour / multi-tool .3mf is imported, the per-part colour and extruder assignments are dropped. After applying a texture and exporting, the result comes back as a single untinted body, so every part has to be reassigned to its filament by hand in the slicer.
This makes BumpMesh painful to use on models that were authored as multi-material prints — which is most decorative prints with logos, lettering or accent parts.
Steps to reproduce
In Bambu Studio / OrcaSlicer, create an object made of several parts, each assigned to a different extruder (e.g. a body on T1, lettering on T2, a logo pattern on T3). Export as .3mf.
Load that .3mf into BumpMesh.
Apply any texture.
Export as .3mf.
Re-open the exported file in the slicer.
Expected
The three parts are still separate, each still assigned to its original extruder.
Actual
The exported file contains one merged object with no material data. All parts land on a single extruder and must be repainted.
The viewport gives no hint that this is going to happen either — the model renders in the usual flat teal from the moment it is imported, so there is no indication that colour information was ever present or that it has been discarded.
Where the data is going missing
A slicer-produced 3MF stores this in two separate places, and parse3MF in js/stlLoader.js reads neither:
3D/3dmodel.model — a <basematerials> resource holding a displaycolor per body, with each <object> pointing into it via pid / pindex:
parse3MF walks the build items and flattens every resolved object into a single non-indexed position array, so both the pid/pindex link and the model_settings.config mapping are lost at import time. Everything downstream (subdivision, displacement, decimation, export) then has no notion of which triangle belongs to which part.
Note that Metadata/model_settings.config is outside the 3MF core spec — it is a Bambu/Orca convention — so it needs to be treated as optional, with basematerials as the spec-compliant fallback.
Notes
STL export can't carry this, since the format has no concept of colour. 3MF export is the only path where it can be preserved, which is worth stating explicitly wherever it is documented.
Preserving this through the pipeline is not just a matter of reading it at import and writing it at export: subdivision, regularisation, decimation and T-junction repair all rewrite the triangle set, so the per-part assignment has to be carried through each stage. Decimation in particular welds coincident vertices globally, so touching parts share vertices along their contact surface and collapses there will drag one part's geometry into another's unless those vertices are pinned.
Related work (neither covers this)
Add Color Support #57 "Add Color Support" (open, draft) — a different feature: it generates colour from the displacement heightmap via a gradient editor. It does not read colour out of an imported file.
3MF-Multi-Body Support #63 "3MF-Multi-Body Support" (closed, not merged) — keeps multiple bodies separate through the pipeline and preserves their names and coordinates, but contains no handling of basematerials, displaycolor, extruder or model_settings.config, so colour and tool assignment are still lost.
Screenshots
In BumpMesh after import — flat teal, no indication the model has parts:
The same file in the slicer — three parts on three different extruders:
Summary
When a multi-colour / multi-tool
.3mfis imported, the per-part colour and extruder assignments are dropped. After applying a texture and exporting, the result comes back as a single untinted body, so every part has to be reassigned to its filament by hand in the slicer.This makes BumpMesh painful to use on models that were authored as multi-material prints — which is most decorative prints with logos, lettering or accent parts.
Steps to reproduce
.3mf..3mfinto BumpMesh..3mf.Expected
The three parts are still separate, each still assigned to its original extruder.
Actual
The exported file contains one merged object with no material data. All parts land on a single extruder and must be repainted.
The viewport gives no hint that this is going to happen either — the model renders in the usual flat teal from the moment it is imported, so there is no indication that colour information was ever present or that it has been discarded.
Where the data is going missing
A slicer-produced 3MF stores this in two separate places, and
parse3MFinjs/stlLoader.jsreads neither:3D/3dmodel.model— a<basematerials>resource holding adisplaycolorper body, with each<object>pointing into it viapid/pindex:Metadata/model_settings.config— the part → extruder map, which is the part that actually matters for a multi-tool print:parse3MFwalks the build items and flattens every resolved object into a single non-indexed position array, so both thepid/pindexlink and themodel_settings.configmapping are lost at import time. Everything downstream (subdivision, displacement, decimation, export) then has no notion of which triangle belongs to which part.Note that
Metadata/model_settings.configis outside the 3MF core spec — it is a Bambu/Orca convention — so it needs to be treated as optional, withbasematerialsas the spec-compliant fallback.Notes
Related work (neither covers this)
basematerials,displaycolor,extruderormodel_settings.config, so colour and tool assignment are still lost.Screenshots
In BumpMesh after import — flat teal, no indication the model has parts:
The same file in the slicer — three parts on three different extruders: