Does an AI-Generated Label in 3MF Metadata Survive a Slicer? We Re-Saved One File in Bambu Studio, OrcaSlicer and PrusaSlicer and Diffed the Output

When you share a model made with AI as a 3MF file, it is tempting to write a label inside the file that says “this is AI-generated”. Besides its predefined names, 3MF metadata leaves room for an author to declare a namespace and add names of their own, so that is where such a label would go. The real question is what happens when the recipient opens that 3MF in a slicer and saves it again. Does the label reach the next person?

This article contains affiliate links. As an Amazon Associate, we earn from qualifying purchases.

To find out, we prepared one 3MF of a 20 mm cube. It carries seven predefined names from the 3MF Core Specification and three names in a namespace this site defined for testing. We loaded it with the CLIs of PrusaSlicer 2.9.6, PrusaSlicer 3.0.0-alpha12, OrcaSlicer 2.5.0-rc and Bambu Studio 2.8.4.57 and exported it back to 3MF. What we compared was the 3MF metadata in the output’s 3D/3dmodel.model. All versions are as of 2026-11-02, and each slicer was run once. Exporting a model from CAD code written with AI is covered in OpenSCAD LLM Workflow 2026: Writing Code CAD with ChatGPT and Claude (published 2026-07-18).

Three conclusions first. First, in this run neither PrusaSlicer version kept the “AI-generated” entries in its output. 2.9.6 rewrote Title and Description to the output file name, and 3.0.0-alpha12 wrote only three entries: two dates and Application. Second, Bambu Studio and OrcaSlicer kept the names and value strings of the “AI-generated” entries, but the preserve attribute and the namespace declaration were missing from the output. A control entry without preserve survived in exactly the same way, so the reading is that they wrote back whatever they had read, not that they honored preserve. Finally, on the specification side, none of the predefined names expresses AI or generation, and retention through preserve is only recommended (SHOULD).

3MF metadata rules: predefined names, namespaces and preserve

The 3MF Core Specification is the base 3MF specification published by the 3MF Consortium. The version read here is 1.4.0 (February 2025), and the metadata rules are collected in section “3.4.1. Metadata”. Metadata elements are placed as children of the model element, with the name in the name attribute and the value as the element content. The specification recommends (SHOULD) that producers attach information about the model file as metadata.

There are nine predefined names, and none of them means AI or generated

Table 3-1 defines the following nine names, all of which apply to the whole model (context: Model). The descriptions summarize the specification text.

As the list shows, none of the nine names records AI or generation provenance. To write “AI-generated” as an entry, you have to create a name in your own namespace, which the specification allows. In other words, it is not that 3MF lacks a way to carry a label; it is that no standard name for one has been defined yet.

Custom names must carry a declared namespace prefix (MUST)

The name attribute can hold either a predefined name or a name defined by the producer. For the latter, the specification says it MUST be prefixed with an XML namespace declared on the model element (the text reads “vendor-defined metadata, which MUST be prefixed with a valid XML namespace name declared on the” model element). Conversely, metadata without a namespace “MUST be restricted to names and values defined by this specification”. Only the nine predefined names may be written without a prefix.

In addition, two metadata entries with the same name MUST NOT be created. Producers who want interoperability with other software SHOULD publish the namespace URI, the list of names and the expected content. And as a general conformance rule of the specification, software that modifies and saves a document MUST NOT introduce non-conformance. Declared prefixes, the restriction on unprefixed names, the ban on duplicate names and not introducing non-conformance: these are the four MUST-level rules that govern how a re-saved output is written.

preserve: retention is recommended (SHOULD)

preserve is an optional attribute of the metadata element. Its type is boolean and it is treated as 0 (false) by default. The specification says that when preserve is 1 or true, software that modifies the 3MF should retain the original metadata value even if the data it references changes (the text: “Consumers that modify the 3MF file SHOULD retain the original metadata value even if the data it references is modified.”).

This SHOULD carries its RFC 2119 meaning, which the 3MF Core Document Conventions restate as: “there may exist valid reasons in particular circumstances to ignore this item”. So if an entry with preserve="1" disappears on re-save, that alone does not violate a MUST. preserve is an attribute with which the producer asks the consumer to keep something; it is not a mechanism that forces it to be kept.

The handling of unknown names is also specified. Consumers are recommended to ignore metadata whose name they do not recognize (“Consumers SHOULD ignore any metadata with a name they do not recognize”). That rule concerns reading, though; whether such entries are kept on re-save is a matter for preserve. There is no explicit text about writing back the type attribute, which states the XML type of the value (default xs:string), when re-saving. Outside metadata, there is also the MustPreserve relationship (again a SHOULD), used when a producer wants an entire custom part (file) kept, but it was not measured here.

In this article, simply loading a file with the CLI and exporting it is treated as “saving a modified version” in the sense of the specification, because each slicer adds entries of its own, such as its version, when exporting. This is this site’s interpretation.

Test conditions: 10 entries in a 20 mm cube, exported with four CLI versions

The slicers and versions used are listed below. Status and release dates come from the GitHub releases (as of 2026-11-02). Where the two slicers’ pre-releases stand is summarized in Slicer Plugins Arrive in OrcaSlicer 2.5 and PrusaSlicer 3.0 (published 2026-10-26).

As of 2026-11-02, OrcaSlicer 2.5.0 has no final release, and the latest stable version is v2.4.2. Bambu Studio’s latest final release is 2.8.2.61 Public Release (2026-08-21), which was not measured. Comparing the source at pinned commits, however, the code that reads and writes metadata is the same as in 2.8.4.

For the OrcaSlicer 2.5.0-rc portable build and the PrusaSlicer 2.9.6 and 3.0.0-alpha12 zips, the downloads were checked against the digests (SHA-256) listed on the GitHub releases, and all matched. Bambu Studio 2.8.4.57 was an existing local installation.

The input 3MF

The input is a 3MF containing one 20 mm cube (12 triangles), placed as a build item at (100,100,0), and nothing else. Its metadata holds the following 10 entries.

Every value is a test string that imagines a situation in which an AI-generated label is added. The seven Core entries have no preserve. Only the two custom-namespace entries swb:AIGenerated and swb:Generator have preserve="1", and swb:Note is a control without preserve. The control is there so that, when entries survive, we can tell whether the slicer kept them because of preserve or simply wrote back everything it had read.

In XML, the three custom-namespace entries look like this (only the metadata elements are shown):

<metadata name="swb:AIGenerated" preserve="1">true</metadata>
<metadata name="swb:Generator" preserve="1">claude-sonnet-5-5 + manifold3d</metadata>
<metadata name="swb:Note">no preserve flag on this one</metadata>

The swb prefix is declared on the model element as xmlns:swb. This prefix and the namespace URI (swiftwand.com/ns/provenance/2026, preceded by https) were defined by this site for testing and are not a standard. Readers have no reason to use the same namespace.

There is also a reason the Application value does not start with any slicer’s name. In the source at the pinned commits, PrusaSlicer 3.0 routes old-version 3MFs whose Application starts with PrusaSlicer- to its legacy loader, Bambu Studio treats a 3MF as one of its own family when Application starts with BambuStudio-, and OrcaSlicer does the same for BambuStudio- and also for OrcaSlicer-. A different load path would introduce differences unrelated to what we wanted to compare, so we avoided it.

Procedure and comparison

Every operation was the same: load the input 3MF with the CLI and export it with --export-3mf. Nothing was sliced. For PrusaSlicer and OrcaSlicer, --datadir pointed to an empty folder so that local settings were not loaded. The procedure for using --export-3mf with the Bambu Studio CLI was also used in Turning AI-Drawn Patterns into 3D Print Texture (published 2026-10-31).

The runs took place around noon on 2026-11-02 (Japan time), which is the same date in UTC. All four exit codes were 0. Run times were 0.3 s for PrusaSlicer 2.9.6, 1.5 s for 3.0.0-alpha12, 1.4 s for OrcaSlicer and 0.6 s for Bambu Studio.

The comparison matches the metadata in the output’s 3D/3dmodel.model against the input and sorts each name into one of four outcomes. “Kept” means the name and value are unchanged, “changed” means the name is the same but the value differs, and “removed” means the name is gone. The fourth, “ns_lost”, means the name and value strings survived but the declaration of the swb namespace (xmlns:swb) is missing from the output; the text also calls this “declaration lost”. The script that builds the 3MF and the script that compares the outputs were written by this site. Two fixes were made to the comparison after the first pass, but the slicers were not rerun.

The reference for matching was an expected-results table (R1 to R20) that lists, row by row, what the specification requires and how each version should write, based on the 3MF Core 1.4.0 text and a reading of each slicer’s source at pinned commits. The table was built for an input that also put preserve="1" on the Core entries, so matching was done on the rows that correspond to the actual input. R numbers below refer to rows of this table.

The four slicers used here are free, but if you want to print the re-saved 3MF and check the part itself, a printer that pairs with Bambu Studio makes that quick.

Bambu Lab P1S Combo (with AMS)

USD 499.99 on Amazon.com (as of 2026/09/21)

Amazon

ポチップ

Results at a glance: what happened to the 10 entries in four versions

Here is what happened to each of the 10 entries in the output of each version.

The CreationDate row needs care. The input date was 2026-11-02, the same day as the run, so “same value” cannot tell whether the original value was kept or replaced with the save date (row R7 of the expected-results table).

Entries that appeared only in the output:

• PrusaSlicer 2.9.6: slic3rpe:Version3mf (value 1), an empty Rating, ModificationDate (2026-11-02)
• PrusaSlicer 3.0.0-alpha12: ModificationDate (2026-11-02)
• Bambu Studio 2.8.4.57: BambuStudio:3mfVersion (value 1), ModificationDate (2026-11-02), and empty DesignerCover, DesignerUserId, License, Origin, ProfileCover, ProfileDescription and ProfileTitle
• OrcaSlicer 2.5.0-rc: OrcaSlicer (value 2.5.0-rc), BambuStudio:3mfVersion (value 1), and empty DesignerCover, DesignerUserId, License, ModificationDate and Origin

The namespaces declared on the output’s model element were Core and slic3rpe for PrusaSlicer 2.9.6, Core only for 3.0.0-alpha12, and Core, BambuStudio and p (the Production extension) for Bambu Studio and OrcaSlicer. No output declared swb. From here on, each version’s results are checked against a reading of its source.

To repeat the 20 mm test cube on your own machine, any reliable PLA works; this is a common choice for small test prints.

ELEGOO PLA Plus Filament 1.75 mm, Black 2 kg

USD 26.98 on Amazon.com (as of 2026/09/21)

Amazon

ポチップ

PrusaSlicer 2.9.6 set Title and Description to the output file name

In the PrusaSlicer 2.9.6 output, both Title and Description became roundtrip, which is the exported file’s name without its extension. Designer, Copyright and LicenseTerms kept only their names, with empty values, and Application changed to PrusaSlicer-2.9.6. None of the three swb entries, neither the two with preserve="1" nor the control, was in the output, and the removed values had not been copied into any other file inside the 3MF either.

Reading the source at the pinned commit, this is the expected behavior. The 2.9.6 exporter writes a fixed set of nine predefined names with its own values every time. Title and Description get the output file name without the extension, the dates get the save date (the first 10 characters of a UTC timestamp string), and Designer and the others are left empty. On the import side, the only values it uses are the version number slic3rpe:Version3mf, Application and the version number of the multi-material painting data, and the word preserve does not appear anywhere in 3mf.cpp.

So in 2.9.6, whatever the input metadata, the re-saved output is replaced with its own nine names plus its version entries. The empty Rating that was added is also a result of writing the nine every time. This time the Core entries had no preserve, but since the source has no code that reads preserve, adding it would most likely give the same result (not measured).

Put in the reader’s terms: taking the source and the result of this run together, a 3MF distributed with “AI-generated” in its Description will have that text replaced by the output file name when the recipient exports it with the 2.9.6 CLI. The same goes for Title. Entries written in a custom namespace vanished from the output, names and all, in this run.

PrusaSlicer 3.0.0-alpha12 wrote only three entries

The only metadata in the 3.0.0-alpha12 output was CreationDate, Application and ModificationDate. Application was PrusaSlicer-3.0.0-alpha12, ModificationDate was 2026-11-02, and CreationDate was 2026-11-02, the same as the input. Title, Designer, Description, Copyright, LicenseTerms and the three swb entries were absent from the output, names included. None of the removed values of six characters or more had been copied into other files inside the 3MF, such as Metadata/PrusaSlicer3_project.json. The only declared namespace was Core.

In 3.0, 3MF reading and writing has been rebuilt as code separate from 2.x. In the source at the pinned commit, the importer reads three attributes, name, preserve and type, and treats preserve as true whenever the attribute is present, without looking at its value. In the exporter, however, the part that writes preserve is commented out under the comment Not supported by xs. So preserve is read on import but not written on export.

Why only three entries? The answer lies in the processing just before saving. In the source, the metadata passed to the save function has ModificationDate and Application removed and duplicates dropped, and then ModificationDate with the save date, CreationDate (if absent) and Application are added. As far as we read, both the CLI save and the GUI save call the save function without passing any metadata. The metadata that was read is used only to determine the file version. The expectation from the source was “only three entries”, and the CLI output in this run matched it.

There was one small difference from the source in the Application value. The default in the source appends +UNKNOWN, but the output from the GitHub zip was PrusaSlicer-3.0.0-alpha12, without +UNKNOWN. The source also has code that records unknown namespace declarations as an import issue. This run kept only the tail of the CLI output, so how that was displayed was not checked. The exit code was 0. Since this is an alpha version, the behavior may change before the final release.

Bambu Studio and OrcaSlicer kept the strings but dropped the declaration and preserve

In the Bambu Studio 2.8.4.57 and OrcaSlicer 2.5.0-rc outputs, five entries, Title, Designer, Description, Copyright and LicenseTerms, kept their input values. The names and value strings of the three swb entries also survived. However, the two entries that had the preserve attribute (swb:AIGenerated and swb:Generator) both lost it (the control swb:Note never had it). The xmlns:swb declaration was also gone from the model element. The output metadata elements carry only name, for example:

<metadata name="swb:AIGenerated">true</metadata>

This is where the control swb:Note matters. This entry, which had no preserve, also kept its string and also lost its declaration, exactly like the two with preserve="1". Since the outcome did not depend on preserve, the reading is that the two slicers did not keep the entries because of preserve; they wrote back what they had read, regardless of preserve.

The source at the pinned commits agrees with this reading. Bambu Studio is a slicer based on PrusaSlicer (according to its README), and OrcaSlicer uses a bbs_3mf.cpp from the same lineage as Bambu Studio. Both store all the metadata they read as name-value pairs and, on export, use those pairs as the base while always writing the names they use themselves (Title, Origin, Designer, License, the dates, Application and so on), even when the value is empty. The namespaces declared on the model element are only Core, BambuStudio and (when used) p, and the only attribute written on metadata elements is name. Bambu Studio’s bbs_3mf.cpp does not contain the word preserve, and in OrcaSlicer it appears only once, in a comment about keeping a seam setting disabled for older versions, which has nothing to do with metadata.

The lost declaration matters to anyone reading the file. If you try to bind the swb prefix in the name value to a namespace URI, you cannot, because there is no matching declaration in the output. Searching for the string swb:AIGenerated finds it; matching by namespace URI does not. Whether the label “survived” now depends on how you read the file.

Both outputs also changed beyond the metadata. Both moved the geometry into a separate model file under 3D/Objects/ and added p: (the Production extension) to requiredextensions. Metadata, however, is written in the main file 3D/3dmodel.model, so that is where to look for a label. In the Bambu Studio output, the build item position became (99.99999,100,10) (the input was (100,100,0); the z of 10 is half the cube’s height).

OrcaSlicer wrote BambuStudio-02.08.01.55 to Application and emptied the dates

Although they share a lineage, OrcaSlicer differed noticeably from Bambu Studio in two ways (a third difference, that ProfileTitle, ProfileCover and ProfileDescription are absent from the output, is covered in the R16 section below). The first is Application: its value became BambuStudio-02.08.01.55, and a separate entry named OrcaSlicer with the value 2.5.0-rc was added. A source comment explains this as a compatibility string for Bambu Studio (“Orca: Write the BambuStudio compatibility version string using SLIC3R_VERSION.”). In version.inc, SLIC3R_VERSION is 02.08.01.55, and OrcaSlicer’s own version is 2.5.0-rc.

The second is the dates: CreationDate and ModificationDate were both empty. The reason given in a source comment is privacy: “Orca: PRIVACY: do not store creation & modification date in 3mf”. In the source, the user ID field DesignerUserId is also emptied for the same reason (in this run, DesignerUserId was empty in the Bambu Studio output as well). The input CreationDate (2026-11-02) became empty as a result of this code.

Recall how Application is defined. The specification defines it as the name of the source application that originally created the document. In this run, the input value swiftwand-d5-maker 0.1 was replaced by each slicer’s own value in all four versions. The input Application had no preserve, so the specification places no retention request on it. Still, note that the Application of a re-saved 3MF cannot tell you which application originally created it. In the OrcaSlicer output, the version of the slicer that actually exported the file is in the OrcaSlicer entry instead.

Specification rules versus outputs: R13 to R16

Here are the specification’s requirements on how a re-saved output is written, next to the outputs of the four versions. Counts are of metadata elements in the output’s 3D/3dmodel.model.

Start with R14. The specification requires that names other than the nine predefined ones be prefixed with a namespace declared on the model element. In both the Bambu Studio and OrcaSlicer outputs, the three entries starting with swb: remained, with no xmlns:swb declaration. In the two PrusaSlicer versions the swb entries themselves did not survive, so this row is 0.

R16 is laid out the same way. The specification restricts metadata without a namespace to the names and values it defines. The outputs contained unprefixed names outside Core: seven in Bambu Studio (DesignerCover, DesignerUserId, License, Origin, ProfileCover, ProfileDescription, ProfileTitle) and five in OrcaSlicer (OrcaSlicer, DesignerCover, DesignerUserId, License, Origin). These are names the slicers added on their own, unrelated to the input. Among them, License is a different name from Core’s LicenseTerms: the input LicenseTerms remained, and an empty License was added alongside it.

R15, duplicates, was 0 in all four. PrusaSlicer 3.0 also removes duplicates before saving in its source. As for R13, the specification does not require these attributes to be written back, so the absence of preserve in the outputs should be read as a recorded fact rather than as a breach of a requirement. It does matter in practice, though: because preserve is not written back, the next person who re-saves the file never receives the request to keep the entry at all.

Source-based expectations versus the results of this run

Rows R1 to R16 of the expected-results table across four versions make 16 rows × 4 = 64 cells. Of these, three R7 cells (PrusaSlicer 2.9.6, 3.0.0-alpha12 and Bambu Studio) cannot be judged because the dates were the same, as noted earlier. The two R14 cells for PrusaSlicer are not applicable, because the swb entries did not survive. Of the remaining 64 − 3 − 2 = 59 cells, 58 matched the expectation and one did not.

The mismatch was OrcaSlicer’s R16. The expectation listed the same names as Bambu Studio plus OrcaSlicer. The output in this run, however, had no ProfileTitle, ProfileCover or ProfileDescription, which left five unprefixed non-Core names. The expectation that such names would exist was right, but their contents differed. Rereading the source at the pinned commit, ProfileTitle, ProfileCover and ProfileDescription are not among the names whose values OrcaSlicer’s exporter writes (Bambu Studio’s exporter does write them), so this was a miss made when building the expectation.

The points flagged at the expectation stage as “to be confirmed by measurement” were also confirmed in this run: that PrusaSlicer 3.0.0-alpha12 writes only three entries on a CLI save, that Bambu Studio and OrcaSlicer do not write the custom namespace declaration, and that none of the four versions writes preserve back. Each is the result of a single CLI export and is not extended to GUI saves or other versions.

The comparison script also has limits. Things it could miss include a change in the letter case of a name alone, and the difference between an empty value and a missing element. The latter was distinguished in this run, since PrusaSlicer 2.9.6’s Designer (value emptied) and 3.0.0-alpha12’s Designer (removed entirely) came out as different results. The former was not checked.

PrusaSlicer issue #13920 was closed by a bot

A report that PrusaSlicer does not honor preserve was filed as issue #13920 on 2025-01-06. Its title is “PrusaSlicer isn’t honoring 3MF metadata element ‘preserve’ attribute”, and the reported version is 2.9.0. According to the reporter, opening a 3MF on Windows works fine, but saving with Save As from the GUI File menu strips and replaces the metadata (“the metadata tags are wholesale removed and replaced”), and even elements with preserve set to 1 have their values updated.

Here is what followed. On 2026-09-02, a bot labeled it as a legacy issue, created before the PrusaSlicer 3.0 alpha was released, and announced that it would be closed in three weeks unless new comments arrived. A final warning came on 2026-09-18, and the bot closed it on 2026-09-29. GitHub shows “closed this as completed”, but the reason given in the bot’s comment is “Closing this issue due to inactivity.” The issue history has no reference to a fixing commit and no reply from a developer.

“Completed” is a GitHub close type, not a statement that the bug was fixed. Reading the source at the pinned commit, 2.9.6 still writes metadata the way the report describes, and the 2.9.6 CLI output in this run also rewrote the predefined names with its own values. The report concerns Save As in the GUI, while this run measured CLI export, so the paths differ. Even so, the result points the same way, in that the predefined names are rewritten. 3.0.0-alpha12 is different code; as shown above, it reads preserve but does not write it.

How to read this when you distribute an AI-generated label in 3MF metadata

From here, the results are read from the perspective of someone who adds a label to an AI-made model and distributes it as 3MF. As a premise, this article is not a legal judgment or legal advice, and it does not address who bears a disclosure obligation. How the European Commission’s (non-binding) guidelines on Article 50 of the EU AI Act treat 3D images and meshes is summarized in where AI-generated labels and provenance marks disappear in images and 3D data (published 2026-11-09).

First, where to write the label. None of the predefined 3MF Core names expresses AI or generation, so an entry has to go in a custom namespace. The specification recommends that producers seeking interoperability publish the namespace URI and the list of names. The swb namespace in this article is for testing only and is not a recommendation. Beyond the fact that no such name exists among those defined by 3MF Core, nothing else was investigated this time.

Second, what happens to the label when the recipient re-saves the file. In this run, the result depended on which slicer the recipient used. In the two PrusaSlicer versions, even entries with preserve="1" did not survive. In Bambu Studio and OrcaSlicer the strings survived, but without preserve and without the namespace declaration. Since no version’s output carries preserve, the entries will be treated as entries without preserve whenever the file is re-saved further down the line.

Third, a caution for those checking files. A 3MF without a label does not mean the model is not AI-generated. If someone re-saved it along the way, the original label may be gone. Conversely, even when a label survives, if it is left with an undeclared prefix, a reader that matches by namespace URI will not find it. Application was also rewritten in all four versions, so it is no clue to the application that originally created the file.

Fourth, what distributors can do. If you distribute a labeled 3MF, distributing the file as it was before any re-save in a slicer means the label is present at least at the moment of distribution. Whether it survives after that depends on the recipient’s slicer and what they do with it; that is as far as this run can support. Note also that, according to the official release notes, 3MFs saved in the Bambu Studio 2.8.4 Beta are temporarily not supported for upload to MakerWorld.

On the image side, when C2PA data on AI images uploaded to WordPress disappears (published 2026-11-12) measured what happens to the label along the publishing path. In the 3MF of this run as well, the label inside the file changed form through an ordinary re-save. Both those who add labels and those who check them need to share that premise.

What this measurement cannot tell you

Finally, here is what these results cannot support.

• Each slicer was run once, and the only operation was export with the CLI’s --export-3mf. Nothing is generalized beyond “this is what happened in this run”.
• GUI saves were not measured. The #13920 report concerns Save As in the GUI, which is a different path from the CLI. The Publish 3MF feature in the OrcaSlicer 2.5 GUI was not used either.
• Nothing was sliced, and G-code and sliced 3MFs (such as .gcode.3mf) were not measured. A search of the source of the three slicers (2.9.6 for PrusaSlicer) found no code that copies 3MF metadata into G-code, but that is not proof that none exists. There is code that writes a line at the top of the G-code identifying the slicer that generated it.
• For CreationDate (R7), it cannot be judged whether the value was kept or replaced, because the input date was the same as the run date.
• The seven Core entries had no preserve. Output for Core entries with preserve="1" was not measured.
• Per-object metadata (metadatagroup) and custom parts with a MustPreserve relationship were not included in the input.
• Other versions such as Bambu Studio 2.8.2.61 and OrcaSlicer 2.4.2, --min-save (which omits geometry) and workflows that re-save across slicers were not measured. For 2.8.2.61, all that can be said is that its source has the same processing as 2.8.4.
• Three of the versions used are pre-releases (alpha, beta and release candidate) and may change in the final releases.
• The comparison script may miss differences such as a change in the letter case of a name.

Summary

In this run, an “AI-generated” label written in 3MF metadata ended up in one of three ways, depending on the slicer it passed through. PrusaSlicer 2.9.6 rewrote the metadata into its own nine names, 3.0.0-alpha12 wrote only three entries, and Bambu Studio 2.8.4.57 and OrcaSlicer 2.5.0-rc kept the strings but dropped the declaration and preserve. None of the versions wrote preserve back.

From the specification side, Core has no standard name for recording AI generation, and writing one in a custom namespace is allowed. preserve is an attribute that asks for an entry to be kept, and retention is only recommended (SHOULD). The specification’s MUSTs govern how things are written, and the Bambu Studio and OrcaSlicer outputs contained entries with undeclared prefixes and unprefixed names outside Core.

If you add a label and distribute the file, assume that the label inside it may change when the recipient re-saves it. If you are checking files, do not read the absence of a label as evidence that a model is not AI-generated. Which entry point to pick among slicer CLIs and plugins is laid out in Extending Your Slicer: Plugins, Post-Processing Scripts or the CLI (published 2026-11-01).

Sources

• 3MF Core Specification 1.4.0 text (3MF Consortium, commit for tag 1.4.0)
• 3MF Core Specification 1.4.0 release
• PrusaSlicer issue #13920
• PrusaSlicer 2.9.6 release
• PrusaSlicer 3.0.0-alpha12 release
• PrusaSlicer 2.9.6 3mf.cpp
• PrusaSlicer 3.0.0-alpha12 Model3mf.cpp
• PrusaSlicer 3.0.0-alpha12 Metadata.cpp
• OrcaSlicer v2.5.0-rc release
• OrcaSlicer v2.4.2 release
• OrcaSlicer v2.5.0-rc bbs_3mf.cpp
• OrcaSlicer v2.5.0-rc version.inc
• Bambu Studio 2.8.4 Public Beta release
• Bambu Studio 2.8.2.61 Public Release
• Bambu Studio 2.8.4 bbs_3mf.cpp
• Bambu Studio 2.8.4 README

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.