Multiple Plates - Part Positions Shifting When Opening Saved Projecs

[jbeardon]

OrcaSlicer Version

1.9.0

OS version

Windows 11

Additional system information

Not relevant - happening on multiple systems

Printer

Bambulab P1P

How to reproduce

Create project containing multiple plates (more than 2 so it creates 2 rows of plates) Arrange part positions on each plate. Save Project as a 3MF. Close Orca Open Orca Load previously saved project.

Actual results

Position of parts on the plates closest to you in the viewport (second and subsequent rows) will have shifted - with large parts, so their edges are off the plate.

This issue has been present for several versions.

Expected results

Parts should retain positions when re-opening a project.

I am unable to share the project as it is a commercial design. The issue is easy to reproduce.

Project file & Debug log uploads

debug_Fri_Jan_12_19_38_59_5788.log.0.zip

Checklist of files to include

• [ ] Log file
• [ ] Project file

[jbeardon]

Same project after re-arranging plate 3. Saving and re-opening:

[maziggy]

Same here with latest version under MacOS.

[RPINerd]

Mine doesn't even save plate information, every time I open a project it reverts to a single default build plate... is this related?

[jbeardon]

This issue is still present in V2.0.0 Beta

[emelbardis]

Still present in v2.0.0 official It seems to affect me most when I have a lot of plates. in my current 9 plate job, the first 3 plates are always fine but then 4-9 are all shifted forward and I have to right click arrange on that individual plate to get them to re-center

[jbeardon]

Yep, present on V2 for me as well.

[Hawk30100]

Still present in Windows Nightly Build 2.1 Dev from May 20, 2024.

Tried to record the behavior:

[jbeardon]

Still present in 2.1.0 release. Annoying as hell with larger projects. All plates on second and 3rd row are shifted when opening an existing project.

[sharky98]

Still present in v2.1.1.

However, I don't think that the object are moving. It seems that they are saved at a fixed World coordinates. However, the spacing between the plates, only the Y axis I've seen so far, changes between reload.

So, for now, my workaround is to change something to force a save of the project, close the project, and reopen it. If the plates doesn't move to their predicted location, I redo it a few times, maybe closing Orca and then it'll work.

For information, the spacing between the plates is ∆X = +280 and ∆Y = -298 for my Ender 3 S1 Pro, which has a 220x220 plate. It would be really helpful that each plate has its own local coordinates.

Looks like it also happens in MacOS: #3852.

[sharky98]

I went ahead and try figure out what is the offset between each plate. Here some code location that maybe relevant.

Adding a plate

https://github.com/SoftFever/OrcaSlicer/blob/9a260010fc7ee309fd6c3fbd1a57c602edcc4e3e/src/slic3r/GUI/PartPlate.cpp#L3583-L3655 Here we have `PartPlateList::compute_origin` which basically just add the `Z=0` to the shape position. https://github.com/SoftFever/OrcaSlicer/blob/9a260010fc7ee309fd6c3fbd1a57c602edcc4e3e/src/slic3r/GUI/PartPlate.cpp#L3595 But at the end, I guess this is where the update to the plates position is done. https://github.com/SoftFever/OrcaSlicer/blob/9a260010fc7ee309fd6c3fbd1a57c602edcc4e3e/src/slic3r/GUI/PartPlate.cpp#L3618

Plate Position

In any case, both path end up using `PartPlateList::compute_shape_position`, which uses `PartPlateList::plate_stride_x` and `PartPlateList::plate_stride_y`. https://github.com/SoftFever/OrcaSlicer/blob/9a260010fc7ee309fd6c3fbd1a57c602edcc4e3e/src/slic3r/GUI/PartPlate.cpp#L3247-L3259 According to this, the new world coordinates position is calculated with `newPos = index * plate_stride()` (removed the distinction between X and Y, as they are the same, except Y is negative).

Offset

The stride is calculated based on a ratio of the dimension (width in X and depth in Y). The col or row index multiply this value, so it seems that the gap would be bigger with bigger plates, which might not be ideal I think. The offset is calculated with `m_plate_dim * (1. + LOGICAL_PART_PLATE_GAP)`. https://github.com/SoftFever/OrcaSlicer/blob/9a260010fc7ee309fd6c3fbd1a57c602edcc4e3e/src/slic3r/GUI/PartPlate.cpp#L3951-L3965 https://github.com/SoftFever/OrcaSlicer/blob/9a260010fc7ee309fd6c3fbd1a57c602edcc4e3e/src/slic3r/GUI/PartPlate.cpp#L53C1-L53C54

Conclusion

Since the origin offset for each plate is based on the dimension, it should be easy to figure out where it should be.

Based on the above, the origin position for the plate that is on indexes col=1 and row=1 (meaning second column and second row) should be ∆X=+264 ∆Y=-264. However this is not my observation, by trial and error, my offset is almost ∆X=+280 and ∆Y=-298, although a zoomed view shows that this is not exact.

My guess is that when loading a project, sometimes the plate STL model isn't yet loaded, so they uses the bed size, but on a second load the plate STL model is loaded so it recalculate with that size. Or something along those line, seeing that it only affect Y and the offset calculated by the size of STL model isn't perfect either. 🤷‍♂️

GAP = 1 / 5 = 0.2

width = 220
colIdx = 1
stride_x = width * (1 * GAP) = 220 * (1 + 0.2) = 264
origin_x = colIdx * stride_x = 1 * 264 = 264

depth = 220
rowIdx = 1
stride_y = depth* (1 * GAP) = 220 * (1 + 0.2) = 264
origin_y = - rowIdx * stride_y = 1 * 264 = -264

I wonder if the width and depth used are not those of the STL model of the plate used to render it, which is width=235 and depth=250. Turns out this is closer to my trial and error with ∆X=+282 and ∆Y=-300, but still not right.

GAP = 1 / 5 = 0.2

width = 235
colIdx = 1
stride_x = width * (1 * GAP) = 235 * (1 + 0.2) = 282
origin_x = colIdx * stride_x = 1 * 282 = 282

depth = 250
rowIdx = 1
stride_y = depth* (1 * GAP) = 250 * (1 + 0.2) = 300
origin_y = - rowIdx * stride_y = 1 * 300= -300

[amckimm]

Still present in 2.1.1 3mf created in OrcaSlicer. Sometimes, loading or reloading the project has the objects shifted downwards along the Y dimension. Reloading sometimes helps.

[jbeardon]

Still present in V2.2.0 @SoftFever Any chance we can get this problem bumped?