generated 3mf file mesh objects aren't equivalent to input mesh objects

[w531t4]

Context:

• to_3mf version: 0.1.0
• python 3.11.11
• prusaslicer version: 2.9.1
• fileA and fileB (see archive.zip) were produced with gflabel (https://github.com/ndevenish/gflabel) 9a7278eb50c5e421788a798da3ea7fa9c8e7a342

Action:
stl_to_3mf([fileA, fileB], 'test_result.3mf')

Expected Outcome:
fileA, fileB would behave the same (in PrusaSlicer) [when performing Split -> To Parts].

Outcome:
When

1. test_result.3mf is opened in PrusaSlicer 2.9.1
2. and either of the attached files (see below) have Split -> To parts performed on them,

Then

1. PrusaSlicer UI shows some of parts as having open edges,
   • 
2. and visually there are components missing and or distorted
   • 

Whereas

1. When these same actions are performed with the raw STL files, no errors show up, and the files appear correctly.

Archive.zip
Archive.zip contains:

• test_result.3mf
• row3-m4x16r-m4x16-1x1-d2.stl
• row2-m4x12r-m4x12-1x1-d2.stl

I'll try to dig and see what's up, but these days my availability seems to change every 15m. I like the idea with your project - The behavior of taking many STL's and pushing them in a m3f accomplishes an objective related to a different goal of mine. I need this functionality AND

1. i'd like to press the "arrange" button in Prusaslicer,
2. press the "Split -> To parts" action for each object in Prusaslicer
3. Mark the an extruder for each part according to a pattern

Hopefully my overall objective helps to clarify my usecase - please note i'm not expecting or asking this project to perform the additional functionality.

[owebeeone]

There could very well be bug in the triangle conversion. The vertex mapping requires exact equivalence (no round off errors) otherwise this problem is what to expect.

I wonder if you can try recreating the STLs, maybe like in meshlab and rewrite it. It'll be a little wile before I can get to this.

Probably due to the vertex matching. Maybe I can add a dumb vertex matcher just one index per vertex, no compressing.

I'm real busy right now, may take a while before I can get to this.

[w531t4]

There could very well be bug in the triangle conversion. The vertex mapping requires exact equivalence (no round off errors) otherwise this problem is what to expect.

I wonder if you can try recreating the STLs, maybe like in meshlab and rewrite it. It'll be a little wile before I can get to this.

Probably due to the vertex matching. Maybe I can add a dumb vertex matcher just one index per vertex, no compressing.

I'm real busy right now, may take a while before I can get to this.

thanks for the quick reply. I can relate. No rush - I've just learned that if i don't document these things when they happen, they never get written ;) - take care!

[owebeeone]

I tried to repro at least, I don't get errors on either Prusa or Orca - I had to split the parts to see the geometry, looks like it's a weird file, it seems to have holes.

So I used PrusaSlicr 2.7.4 - a bit old. I use Orca more recently and it had no artifacts too.

So, it's either a bug/feature in your more recent PrusaSlicr.

I think we can leverage manifold3d in to_3mf to possibly clean things up.

So, it would be nice to have some tests on Orca too.

BTW, I ran to_3mf and it created exactly the same output model file (not the zip container).

I'm working on generating stl models directly from pythonopenscad, part1 is mostly working, includes a rudimentary python 3D viewer too should be out in the next few weeks. Maybe I can add a viewer to to_3mf...

[w531t4]

fwiw - i ended up building a workflow that got me direct from gflabel -> prusaslicer.

• Workflow enhancements for embedded labels ndevenish/gflabel#23
• Use existing extruder assign. when converting to multipart object, if possible prusa3d/PrusaSlicer#14525