Moving a file between slicers
Geometry crosses between any two slicers. Print settings almost never do: each
slicer reads only the config part it wrote and ignores the other four, so a
Bambu .3mf opened in PrusaSlicer arrives as meshes on a plate with your own
profile applied.
Why do the settings not come across?
Because the 3MF specification says nothing about them. The 3MF Core Specification defines the container, the model, and the build; print configuration is not in it. Each slicer invented its own place to put it, and each reads only its own:
| Slicer | Where its settings live | Format |
|---|---|---|
| PrusaSlicer | Metadata/Slic3r_PE.config |
INI, one key = value per line |
| Bambu Studio | Metadata/project_settings.config |
JSON, one flat object |
| OrcaSlicer | Metadata/project_settings.config |
JSON, one flat object |
| Creality Print | Metadata/project_settings.config |
JSON, one flat object |
| Cura | inside 3D/3dmodel.model |
XML metadata, cura namespace |
PrusaSlicer opening a Bambu file finds no Slic3r_PE.config, so there is
nothing for it to read. The JSON is still sitting in the archive, untouched.
And even where a slicer could read another's file, the keys disagree. The nozzle
temperature is temperature in PrusaSlicer, nozzle_temperature in Bambu
Studio and OrcaSlicer, and material_print_temperature in Cura.
Print settings by name has that mapping for 60 settings, one
page each.
What survives which pairing?
| Direction | Geometry | Plate placement | Per-object settings | Print profile |
|---|---|---|---|---|
| Bambu, Orca, or Creality between themselves | yes | yes | mostly | yes |
| Bambu or Orca to PrusaSlicer | yes | yes | no | no |
| PrusaSlicer to Bambu or Orca | yes | yes | no | no |
| Anything to Cura | yes | yes | no | no |
| Cura to anything | yes | yes | no | no |
Geometry and placement always cross because they are in the model part, which is the standardised half. Everything in the right-hand columns lives in a vendor part, and crossing it means reading a file the other slicer never learned to read.
The three-way group in the first row is the exception. OrcaSlicer is a Bambu
Studio fork and Creality Print is an OrcaSlicer fork, so all three write the
same Metadata/project_settings.config with the same X-BBL-* headers. Each
has since added keys the others do not read, so some values still drop, but the
file structure is shared and most of a profile carries.
Why is PrusaSlicer's Import Config no help here?
Because it reads only its own INI. PrusaSlicer's config import expects the
Slic3r_PE.config block it writes, and a Bambu file has JSON under a different
name. Nothing is broken. You are pointing it at a format it does not parse.
Any converter has to do the same two things: read one vendor's keys, and write the other's names for the same values. The second half is the hard one, and it is what Print settings by name publishes for 60 settings.
What should I do instead?
Reslice, and set the handful of settings that matter yourself. Open the source file, read the values you care about, then type them into your own profile. Layer height, wall count, infill density and the two temperatures cover most of the difference between one person's print and another's.
Finding one setting in a file is the short version of that: open the file, read the value, close it.
How do I read the settings the other slicer ignored?
Open the file in preslice. It reads all five config formats, so a Bambu
.3mf shows its print settings whether or not PrusaSlicer can see them, and the
Raw tab gives you the config part itself as text if you want
to copy values out by hand.
Which slicer wrote a file is not always obvious from looking at it. Which slicer made this file covers how to tell.