All objects in 3MF file created by plater have the same X and Y position coordinates

[pajtaz]

What happened?

What happened If a 3MF file that was created by plater is opened by SuperSlicer, whether by "File -> Open Project" or "Add...", all objects in the 3MF file have the X and Y position coordinates. See screenshots for examples. It seems the X and Y coordinates of the first object are shown for all objects.

If any 3MF file is created by SuperSlicer then saved then opened, this does not happen. If 3MF file created by plater but modified by earlier versions of SuperSlicer is opened, this does not happen.

This may not be limited to plater program, I have not tested it with other programs.

Important to know that I tracked the issue to something that happened between versions 2.3.57.12 and 2.3.58.0. All versions before work correctly, all version after do not.

What I expected to happen All objects X and Y position coordinates should be from that object and not the first object of 3MF file.

Project file & How to reproduce

3MF bug.zip

1. Open 3MF.
2. Click on several objects and look at their X and Y position coordinates.

Version

2.5.59.8 (but applicable to all versions after 2.3.57.12)

Operating system

Windows 10

Printer model

Voron Trident

[legend069]

well this is an interesting one. replicated in versions 2.5.59.8 and 2.5.59.3

looks like the bug is apart of the open projects functions as it's missing a function call for this window using "control + i" then selecting the platter/project .3mffile selecting "no" on this screen results in the 'bug' selecting "yes" on this screen results in expected behavior

[legend069]

with the merge of 2.7 from prusa SS should have better a better part sorting algorithm so using the software plater shouldn't be required

can you please upload the file that's generated from platter

not entirely sure where to fix this bug, might need @supermerill to chip in for it. but i found where it's getting the 80.262,20.337,2.00 numbers from

breakpoint on line 2810 of plater.cpp

moving if (model.looks_like_multipart_object()) { outside of if (!is_project_file) { in plater.cpp now gives the prompt for "multiple parts" selecting yes then follows though with the expected output. maybe it's that simple? i don't feel like that is the best fix though, since a project should be loaded as is and not get modified again by the person loading the project file.

[pajtaz]

I can upload the 3MF from plater but that attached file is plater's output plus me clicking that "No" when asked for multi-part object. I always click "No" since I specifically use plater to output 3MF with individual objects so I can manipulate them as needed with names of the objects.

To clarify, nothing has changed in plater. I have used the same plater for last 2 years. SuperSlicer changed. It worked correctly up to version 2.3.57.12 and every version after that this does not work. Additional clarification is that I use a version of plater that outputs 3MF instead of STL. Having one or multiple STLs is not beneficial when wanting to manipulate objects for slicing or when wanting to be able to exclude objects during printing for any reason. That is why I output to 3MF directly from Plater.

[pajtaz]

with the merge of 2.7 from prusa SS should have better a better part sorting algorithm so using the software plater shouldn't be required

I use Plater since it is more efficient and allows me to create multiple plates all nicely arranged from a text file. I have used it for 2 years, there is no reason to stop using it.

can you please upload the file that's generated from platter

I uploaded fresh output from Plater. plate_001.zip

[pajtaz]

If you select "Yes" on that prompt for multi-part object, it loads the objects with different heights.

[supermerill]

What is the intended behavior?

in your .3mf, in the 3Dmodel.model, there is the coordinates of each object:

  <item objectid="1" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 15.8999996" printable="1"/>
  <item objectid="2" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 2" printable="1"/>
  <item objectid="3" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 2" printable="1"/>
  <item objectid="4" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 10.5000076" printable="1"/>
  <item objectid="5" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 3.70000005" printable="1"/>
  <item objectid="6" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 3.70000005" printable="1"/>
  <item objectid="7" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 7" printable="1"/>
  <item objectid="8" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 9.00009155" printable="1"/>
  <item objectid="9" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 9.00008583" printable="1"/>
  <item objectid="10" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 5.20051193" printable="1"/>
  <item objectid="11" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 8.09999847" printable="1"/>
  <item objectid="12" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 5.30000019" printable="1"/>
  <item objectid="13" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 5.4000001" printable="1"/>
  <item objectid="14" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 20" printable="1"/>
  <item objectid="15" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 16.75" printable="1"/>
  <item objectid="16" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 1.89999998" printable="1"/>
  <item objectid="17" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 5.20000076" printable="1"/>
  <item objectid="18" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 3.50632191" printable="1"/>
  <item objectid="19" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 2.4000001" printable="1"/>
  <item objectid="20" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 2.9000001" printable="1"/>
  <item objectid="21" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 3.70000005" printable="1"/>
  <item objectid="22" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 3.70000005" printable="1"/>
  <item objectid="23" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 2.9000001" printable="1"/>
  <item objectid="24" transform="1 0 0 0 1 0 0 0 1 82.262497 20.3375015 2.9000001" printable="1"/>

[pajtaz]

What is the intended behavior?

in your .3mf, in the 3Dmodel.model, there is the coordinates of each object:

This is not from the Plater output 3MF. This is from Superslicer saved 3MF. The same information in same file but from original Plater 3MF file (I cannot paste it with nice formatting, I don't know how) is different. Check this post: https://github.com/supermerill/SuperSlicer/issues/4221#issuecomment-2072310139

I attached original Plater 3MF there and you will see that it is different.

[pajtaz]

    <item objectid="1" p:UUID="779b540a-c611-49d5-a0e4-dbd83a928c80" transform="1 0 0 -0 1 0 0 0 1 34 64.5 0"/>
    <item objectid="3" p:UUID="64b61458-946e-4f5f-b530-0c725f773d9f" transform="-4.37114e-08 1 0 -1 -4.37114e-08 0 0 0 1 25.5 160 0"/>
    <item objectid="5" p:UUID="b0635305-c17a-48cb-8665-dc75cb41ea09" transform="1.19249e-08 -1 0 1 1.19249e-08 0 0 0 1 26 219.5 0"/>
    <item objectid="7" p:UUID="26bf2d2e-1611-42ad-8223-325a2e2a27cf" transform="-4.37114e-08 1 0 -1 -4.37114e-08 0 0 0 1 66 178 0"/>
    <item objectid="9" p:UUID="17e3f19b-88e4-4373-88d8-deafdb96aaf5" transform="-4.37114e-08 1 0 -1 -4.37114e-08 0 0 0 1 87 55 0"/>
    <item objectid="9" p:UUID="fa34843c-630b-46d0-b5a2-1f71576cef36" transform="1.19249e-08 -1 0 1 1.19249e-08 0 0 0 1 67 120 0"/>
    <item objectid="11" p:UUID="22d7d7cb-6dde-4a61-ae85-7d22d2a75fd4" transform="1 0 0 -0 1 0 0 0 1 59 236 0"/>
    <item objectid="11" p:UUID="6121a47e-f0d5-435e-88fc-3b843bbecf51" transform="-1 -8.74228e-08 0 8.74228e-08 -1 0 0 0 1 74 222 0"/>
    <item objectid="13" p:UUID="3d9623c9-51c1-4d5d-a433-af39a384f3c6" transform="1.19249e-08 -1 0 1 1.19249e-08 0 0 0 1 99.5 16.5 0"/>
    <item objectid="15" p:UUID="b2833ec1-0658-4879-84eb-4389a624c86d" transform="-4.37114e-08 1 0 -1 -4.37114e-08 0 0 0 1 87 74 0"/>
    <item objectid="17" p:UUID="735a9da5-8f3f-4fd0-b033-988ebadae97b" transform="1.19249e-08 -1 0 1 1.19249e-08 0 0 0 1 92 185 0"/>
    <item objectid="19" p:UUID="f5a00994-41ff-433c-8f1a-a8fdf0b44eeb" transform="1 0 0 -0 1 0 0 0 1 102.5 119.5 0"/>
    <item objectid="21" p:UUID="4490c8df-d9b8-4ec4-854d-7fb0b0705f7a" transform="-1 -8.74228e-08 0 8.74228e-08 -1 0 0 0 1 111.5 56.5 0"/>
    <item objectid="23" p:UUID="c7f3f90a-23f0-4cd3-949d-92e47954e1e8" transform="-1 -8.74228e-08 0 8.74228e-08 -1 0 0 0 1 92.5 232.5 0"/>
    <item objectid="25" p:UUID="1babf333-f7a6-4fe8-8569-971f743fe39d" transform="1.19249e-08 -1 0 1 1.19249e-08 0 0 0 1 105 145.5 0"/>
    <item objectid="27" p:UUID="ccbb7561-50ab-47d1-a286-e2740e6655dd" transform="1.19249e-08 -1 0 1 1.19249e-08 0 0 0 1 119 89.5 0"/>
    <item objectid="29" p:UUID="9ede4ab3-ec7f-449a-9d38-d1d64856d376" transform="-4.37114e-08 1 0 -1 -4.37114e-08 0 0 0 1 33 41 0"/>
    <item objectid="31" p:UUID="8a857e3a-fecd-4259-82aa-907d31a1d69e" transform="-4.37114e-08 1 0 -1 -4.37114e-08 0 0 0 1 63 121.5 0"/>
    <item objectid="33" p:UUID="b8246d40-48a9-451b-a111-0b80f4d3cfe4" transform="-1 -8.74228e-08 0 8.74228e-08 -1 0 0 0 1 91 190 0"/>
    <item objectid="35" p:UUID="0aa32952-cf61-4877-97f1-0e16517ab624" transform="-1 -8.74228e-08 0 8.74228e-08 -1 0 0 0 1 112.5 163 0"/>
    <item objectid="37" p:UUID="cb313706-a4fe-4a11-9608-23582d7ad8ad" transform="-4.37114e-08 1 0 -1 -4.37114e-08 0 0 0 1 31.5 101 0"/>
    <item objectid="39" p:UUID="70e4de75-772b-41a0-8d71-f750b1b3fe44" transform="-1 -8.74228e-08 0 8.74228e-08 -1 0 0 0 1 105 205.5 0"/>
    <item objectid="39" p:UUID="886fb589-f374-4a9f-a099-0c6fb376bc8d" transform="-4.37114e-08 1 0 -1 -4.37114e-08 0 0 0 1 121.5 72 0"/>
    <item objectid="39" p:UUID="673044d4-337c-4cbf-a996-9c3687523718" transform="1 0 0 -0 1 0 0 0 1 121 106.5 0"/>

[supermerill]

understood. If you import as multi-part object then split it into object, then the positions are okay. If you import it as separate objects, it will import the offset into the geometry instead of the slicer's object.

here is the comment from the code source:

                // if the 3mf was not produced by PrusaSlicer and there is only one instance,
                // bake the transformation into the geometry to allow the reload from disk command
                // to work properly

I wonder how to handle the case...

[pajtaz]

understood. If you import as multi-part object then split it into object, then the positions are okay. If you import it as separate objects, it will import the offset into the geometry instead of the slicer's object.

here is the comment from the code source:

                // if the 3mf was not produced by PrusaSlicer and there is only one instance,
                // bake the transformation into the geometry to allow the reload from disk command
                // to work properly

I wonder how to handle the case...

There are multiple problems with this approach and this is not the fix but a workaround that also does not work well.

First, opening 3MFs worked correctly before version 2.3.58.0. Therefore something happened to the code of Superslicer between 2.3.57.12 and 2.3.58.0. to make this problem. I tested it and this issue does not happen with all those earlier versions.

Second, importing 3MF as multi-part object then splitting it causes multiple issues, it simply does not work. It causes some individual STLs to be further split into objects. You end up with extra objects due to whatever reason. In the example above you end up with 7 additional objects named "plate_001_1" to "plate_001_7". Before splitting into objects the STLs have offset coordinates and are not all on the bed.

I understand it might be a big task to see what changed from 2.3.57.12 and 2.3.58.0. but this is when the issue got created. I even tried downloading different versions of 3MF libraries for Plater, tried a bunch of version going back 3-4 years and the issue was still there in every version after 2.3.57.12.

[supermerill]

I think i'll have to fix the reload in a proper way. But that may takes some time.