I feel your pain. I have been down this rabbit hole too many times, but I will share what I’ve learned.
3MF is supposed to be a standard, but as an old mentor of mine once said about industry standards:
“We have standards so that we know what we deviate from…”
Sadly, the 3MF standard leaves room for implementation differences. That is especially true once slicers start adding their own project data, thumbnails, colors, plates, printer settings, AMS/CFS-style material data, and vendor-specific metadata.
In other words, a file can be a valid 3MF and still not behave cleanly when moved between slicers.
A few tests I would try:
- Load the 3MF into a non-slicer program, such as a CAD program or 3D viewer.
If it opens there, the file may not be corrupt. The problem may be slicer-specific metadata.
- Re-export the file from another program if possible.
This may strip or rebuild some of the slicer-specific project data.
- If the 3MF has more than one build plate, save each plate separately.
I have seen multi-plate 3MF files create problems. Saving plates individually may help isolate whether one model, one plate, or one setting is causing the issue.
- Try an older version of Bambu Studio or OrcaSlicer.
If the same file worked before and now fails, that tells you the problem may have been introduced by a recent slicer change.
And I would not rule out Bambu as the source of the incompatibility.
Given Bambu’s recent hostility toward third-party control and support, it would not surprise me if a newer Bambu Studio 3MF includes project data or behavior that OrcaSlicer does not support cleanly yet.
That does not automatically mean the file is corrupt.
It may mean Bambu Studio and OrcaSlicer are no longer treating the same 3MF project data the same way.