search

prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.6k stars 1.91k forks source link

STL import: incorrect size #2926

Open BartdaMan opened 4 years ago

BartdaMan commented 4 years ago

Version

PrusaSlicer Version: 2.1.0-rc2+ Build: PrusaSlicer-2.1.0-rc2+-201909111218

Operating System: Macintosh System Architecture: 64 bit System Version: macOS Version 10.15 (Build 19A558d)

3D printer brand / version + firmware version (if known)

I3 MK3S / 3.8.0-2684

Behavior

Attached STL has the correct size when importing into Fusion 360 or a webservice such as from Materialise. But in Prusaslicer it is about 10 times too small.

If I export this STL from Fusion 360, then the new STL imports fine. But it doesn't slice properly; Prusaslicer reports this error: _Empty layers detected, the output would not be printable. Object name: Hex_DRAGONE27 (export from Fusion 360).stl Print z: 0.300000 This is usually caused by negligibly small extrusions or by a faulty model. Try to repair the model or change its orientation on the bed.

I have attached both STL files. Hex_dragon.zip

bubnikv commented 4 years ago

But in Prusaslicer is is about 10 times too small.

Is it exactly 10x smaller?

All your STLs are in a binary format. The binary STL format does not provide any information on scaling, but there are 80 free form bytes at the start of an STL, which an application may use for whatever purpose. For example, Materialise defines an extension for capturing colors, see for example https://www.wikizero.com/en/STL_(file_format) section "Color in binary STL". Maybe the file that imports too small in PrusaSlicer defines that it has been exported in centimeters?

For reference, your binary STL exported from Fusion 360 starts with STLB ATF 8.6.0.1094 COLOR= ˙ while the "wrong" STL starts with STLEXP Hex_cone hang 1_2 whatever it means.

With what program did you create the "wrong" STL?

po 16. 9. 2019 v 13:36 odesílatel BartdaMan notifications@github.com napsal:

Version

PrusaSlicer Version: 2.1.0-rc2+ Build: PrusaSlicer-2.1.0-rc2+-201909111218

Operating System: Macintosh System Architecture: 64 bit System Version: macOS Version 10.15 (Build 19A558d) 3D printer brand / version + firmware version (if known)

I3 MK3S / 3.8.0-2684 Behavior

Attached STL has the correct size when importing into Fusion 360 or a webservice such as from Materialise. But in Prusaslicer is is about 10 times too small.

If I export this STL from Fusion 360, then the new STL imports fine. But it doesn't slice properly; Prusaslicer reports this error:

Empty layers detected, the output would not be printable. Object name: Hex_DRAGON_E27 (export from Fusion 360).stl Print z: 0.300000 This is usually caused by negligibly small extrusions or by a faulty model. Try to repair the model or change its orientation on the bed.

I have attached both STL files. Hex_dragon.zip https://github.com/prusa3d/PrusaSlicer/files/3616041/Hex_dragon.zip

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ABMPSIZCWP4CNLJCCOI7LE3QJ5VULA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HLRY2HA, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMPSI43VLWOCHXBT7VYYBDQJ5VULANCNFSM4IXBBHEA .

BartdaMan commented 4 years ago

Hello,

Yes, exactly 10 times.

This is Hex_DRAGON_E27 (original file).STL:

And this is Hex_DRAGON_E27 (export from Fusion 360).stl:

The original STL I have downloaded (purchased) from Cults3d (it is this one: https://cults3d.com/en/3d-model/home/dragon-shell-table-pendant-wall-floor-light https://cults3d.com/en/3d-model/home/dragon-shell-table-pendant-wall-floor-light)

If I use this original file and scale it 1000% (ten time), then still it does not slice properly: Empty layers detected, the output would not be printable. Object name: Hex_DRAGON_E27 (original file).STL Print z: 0.300000

I only used Fusion 360 to try to reproduce an STL file that would slice properly.

Best regards,

Bart Mol

Op 16 sep. 2019, om 15:15 heeft Vojtěch Bubník notifications@github.com het volgende geschreven:

But in Prusaslicer is is about 10 times too small.

Is it exactly 10x smaller?

All your STLs are in a binary format. The binary STL format does not provide any information on scaling, but there are 80 free form bytes at the start of an STL, which an application may use for whatever purpose. For example, Materialise defines an extension for capturing colors, see for example https://www.wikizero.com/en/STL_(file_format) section "Color in binary STL". Maybe the file that imports too small in PrusaSlicer defines that it has been exported in centimeters?

For reference, your binary STL exported from Fusion 360 starts with STLB ATF 8.6.0.1094 COLOR= ˙ while the "wrong" STL starts with STLEXP Hex_cone hang 1_2 whatever it means.

With what program did you create the "wrong" STL?

po 16. 9. 2019 v 13:36 odesílatel BartdaMan notifications@github.com napsal:

Version

PrusaSlicer Version: 2.1.0-rc2+ Build: PrusaSlicer-2.1.0-rc2+-201909111218

Operating System: Macintosh System Architecture: 64 bit System Version: macOS Version 10.15 (Build 19A558d) 3D printer brand / version + firmware version (if known)

I3 MK3S / 3.8.0-2684 Behavior

Attached STL has the correct size when importing into Fusion 360 or a webservice such as from Materialise. But in Prusaslicer is is about 10 times too small.

If I export this STL from Fusion 360, then the new STL imports fine. But it doesn't slice properly; Prusaslicer reports this error:

Empty layers detected, the output would not be printable. Object name: Hex_DRAGON_E27 (export from Fusion 360).stl Print z: 0.300000 This is usually caused by negligibly small extrusions or by a faulty model. Try to repair the model or change its orientation on the bed.

I have attached both STL files. Hex_dragon.zip https://github.com/prusa3d/PrusaSlicer/files/3616041/Hex_dragon.zip

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ABMPSIZCWP4CNLJCCOI7LE3QJ5VULA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HLRY2HA, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMPSI43VLWOCHXBT7VYYBDQJ5VULANCNFSM4IXBBHEA .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ALYN3OWK3BH3LXF7Q5J3QD3QJ6BGNA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6ZC7TI#issuecomment-531771341, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYN3OXPBVUEIC3XKAIA54LQJ6BGNANCNFSM4IXBBHEA.

bubnikv commented 4 years ago

The original STL I have downloaded (purchased) from Cults3d

Would you be able to find out the application name from the author at Cluts3d? I would like to get the STL header definition format description that that particular software seem to generate.

po 16. 9. 2019 v 15:34 odesílatel BartdaMan notifications@github.com napsal:

Hello,

Yes, exactly 10 times.

This is Hex_DRAGON_E27 (original file).STL:

And this is Hex_DRAGON_E27 (export from Fusion 360).stl:

The original STL I have downloaded (purchased) from Cults3d (it is this one: https://cults3d.com/en/3d-model/home/dragon-shell-table-pendant-wall-floor-light < https://cults3d.com/en/3d-model/home/dragon-shell-table-pendant-wall-floor-light

)

If I use this original file and scale it 1000% (ten time), then still it does not slice properly: Empty layers detected, the output would not be printable. Object name: Hex_DRAGON_E27 (original file).STL Print z: 0.300000

I only used Fusion 360 to try to reproduce an STL file that would slice properly.

Best regards,

Bart Mol

Op 16 sep. 2019, om 15:15 heeft Vojtěch Bubník notifications@github.com het volgende geschreven:

But in Prusaslicer is is about 10 times too small.

Is it exactly 10x smaller?

All your STLs are in a binary format. The binary STL format does not provide any information on scaling, but there are 80 free form bytes at the start of an STL, which an application may use for whatever purpose. For example, Materialise defines an extension for capturing colors, see for example https://www.wikizero.com/en/STL_(file_format) section "Color in binary STL". Maybe the file that imports too small in PrusaSlicer defines that it has been exported in centimeters?

For reference, your binary STL exported from Fusion 360 starts with STLB ATF 8.6.0.1094 COLOR= ˙ while the "wrong" STL starts with STLEXP Hex_cone hang 1_2 whatever it means.

With what program did you create the "wrong" STL?

po 16. 9. 2019 v 13:36 odesílatel BartdaMan notifications@github.com napsal:

Version

PrusaSlicer Version: 2.1.0-rc2+ Build: PrusaSlicer-2.1.0-rc2+-201909111218

Operating System: Macintosh System Architecture: 64 bit System Version: macOS Version 10.15 (Build 19A558d) 3D printer brand / version + firmware version (if known)

I3 MK3S / 3.8.0-2684 Behavior

Attached STL has the correct size when importing into Fusion 360 or a webservice such as from Materialise. But in Prusaslicer is is about 10 times too small.

If I export this STL from Fusion 360, then the new STL imports fine. But it doesn't slice properly; Prusaslicer reports this error:

Empty layers detected, the output would not be printable. Object name: Hex_DRAGON_E27 (export from Fusion 360).stl Print z: 0.300000 This is usually caused by negligibly small extrusions or by a faulty model. Try to repair the model or change its orientation on the bed.

I have attached both STL files. Hex_dragon.zip https://github.com/prusa3d/PrusaSlicer/files/3616041/Hex_dragon.zip

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ABMPSIZCWP4CNLJCCOI7LE3QJ5VULA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HLRY2HA , or mute the thread < https://github.com/notifications/unsubscribe-auth/ABMPSI43VLWOCHXBT7VYYBDQJ5VULANCNFSM4IXBBHEA

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ALYN3OWK3BH3LXF7Q5J3QD3QJ6BGNA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6ZC7TI#issuecomment-531771341>, or mute the thread < https://github.com/notifications/unsubscribe-auth/ALYN3OXPBVUEIC3XKAIA54LQJ6BGNANCNFSM4IXBBHEA .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ABMPSI7ZCNSRJ5XUCD65ISLQJ6DPVA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6ZE2OY#issuecomment-531778875, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMPSI73PRCLFWWSTKADDW3QJ6DPVANCNFSM4IXBBHEA .

Jebtrix commented 4 years ago

@bubnikv Looking at that authors webpage of model designs I thought of Rhino3D. I'm 99% sure that is it:

https://discourse.mcneel.com/t/stl-file-import-export-scale-problems/22710

bubnikv commented 4 years ago

@jebrix cool, thanks. We shall collect some Rhino generated STLs, try to guesstimate the STL header format and possibly implement the automatic scaling. I just wonder that I hear about this Rhino issue for the first time, working on the slicer over three years now.

po 16. 9. 2019 v 17:51 odesílatel Jebtrix notifications@github.com napsal:

@bubnikv https://github.com/bubnikv Looking at that authors webpage of model designs I thought of Rhino3D. I'm 99% sure that is it:

https://discourse.mcneel.com/t/stl-file-import-export-scale-problems/22710

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ABMPSI2E2IPU4FSE2LPRRL3QJ6TOPA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6ZTNIY#issuecomment-531838627, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMPSIY5PDTCO6G7OGBGAZLQJ6TOPANCNFSM4IXBBHEA .

BartdaMan commented 4 years ago

I just wonder that I hear about this Rhino issue for the first time, working on the slicer over three years now. Ha, I guess you’re never too old to learn... 😃

With kind regards, Bart Mol

Op 16 sep. 2019 om 18:37 heeft Vojtěch Bubník notifications@github.com het volgende geschreven:

@jebrix cool, thanks. We shall collect some Rhino generated STLs, try to guesstimate the STL header format and possibly implement the automatic scaling.

po 16. 9. 2019 v 17:51 odesílatel Jebtrix notifications@github.com napsal:

@bubnikv https://github.com/bubnikv Looking at that authors webpage of model designs I thought of Rhino3D. I'm 99% sure that is it:

https://discourse.mcneel.com/t/stl-file-import-export-scale-problems/22710

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ABMPSI2E2IPU4FSE2LPRRL3QJ6TOPA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6ZTNIY#issuecomment-531838627, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMPSIY5PDTCO6G7OGBGAZLQJ6TOPANCNFSM4IXBBHEA .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

Jebtrix commented 4 years ago

@bubnikv Yeah I kind of thought the same thing since Rhino3D is an industrial design standard for NURBS based work. I found some Rhino .stl files I had from a PC version and header begins with Rhinoceros Binary STL ( May 6 2017 ). I doubt Mac version would differ. I would still put money on Rhino made those models. It is possible they were "post processed" by that website or went thru a Product Data Management software that some design firms use to manage assets.

STLEXP Hex_cone hang 1_2 to me means:

Jebtrix commented 4 years ago

@bubnikv Last tidbit. Looking at the included samples from the official PrusaSlicer installer you have some STL files with that header style:

Jebtrix commented 4 years ago

Files are from 3DSMax. Glad I didn't bet actual money ;)

Jebtrix commented 4 years ago

The bottom faces of the mesh were not completely flat. Quick fix with scale Z 0 on the bottom faces in Blender. Slices fine.

Hex_DRAGON_E27 (original file)_flattened.zip

-Edit: For the record, Blender imports this model @ 100x scale.

bubnikv commented 4 years ago

Yeah I kind of thought the same thing since Rhino3D is an industrial design standard for NURBS based work. I found some Rhino .stl files I had from a PC version and header begins with Rhinoceros Binary STL ( May 6 2017 ). I doubt Mac version would differ. I would still put money on Rhino made those models. It is possible they were "post processed" by that website or went thru a Product Data Management software that some design firms use to manage assets.

The "buggy" STL that triggered this issue did not contain the "Rhinoceros Binary STL" header. Now tell me, how did Fusion 360 detect that the model is in cm, not in mm? What should we do?

út 17. 9. 2019 v 8:03 odesílatel Jebtrix notifications@github.com napsal:

The bottom faces of the mesh were not completely flat. Quick fix with scale Z 0 on the bottom faces in Blender. Slices fine.

Hex_DRAGON_E27 (original file)_flattened.zip https://github.com/prusa3d/PrusaSlicer/files/3619473/Hex_DRAGON_E27.original.file._flattened.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ABMPSI2DPJOZSUWR7XR5T4TQKBXLHA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD63MU2A#issuecomment-532073064, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMPSIYXP3GE2PGRWISKN53QKBXLHANCNFSM4IXBBHEA .

BartdaMan commented 4 years ago

Guys,

Currently I am traveling for work, so I can not print the flattened/repaired STL. I will do so next weekend. But I would already like to thank you for your time and efforts finding a solution to my problem!

Best regards, Bart

Op 17 sep. 2019 om 14:03 heeft Jebtrix notifications@github.com het volgende geschreven:

The bottom faces of the mesh were not completely flat. Quick fix with scale Z 0 on the bottom faces in Blender. Slices fine.

Hex_DRAGON_E27 (original file)_flattened.zip

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

Jebtrix commented 4 years ago

Now tell me, how did Fusion 360 detect that the model is in cm, not in mm? What should we do?

@bubnikv I imported that STL in a bunch of software just to see if any would guess cm. None of them guessed the right unit size. I think his Fusion360 settings may be set for cm as default unit and didn't guess at all. @BartdaMan When you open a new Fusion360 project what is the default unit size?

BartdaMan commented 4 years ago

Many thanks, this file slices fine.

Best regards,

Bart

Op 17 sep. 2019, om 08:03 heeft Jebtrix notifications@github.com het volgende geschreven:

The bottom faces of the mesh were not completely flat. Quick fix with scale Z 0 on the bottom faces in Blender. Slices fine.

Hex_DRAGON_E27 (original file)_flattened.zip https://github.com/prusa3d/PrusaSlicer/files/3619473/Hex_DRAGON_E27.original.file._flattened.zip — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ALYN3OWNPO6PYADSKUBILH3QKBXLVA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD63MU2A#issuecomment-532073064, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYN3OX3QRAJNT5ZPFB6AE3QKBXLVANCNFSM4IXBBHEA.

BartdaMan commented 4 years ago

If I start a new project and create a solid, all is in mm. Definitely mm.

This is the settings page:

Strange isn’t it?

Best regards,

Bart

Op 18 sep. 2019, om 18:14 heeft Jebtrix notifications@github.com het volgende geschreven:

Now tell me, how did Fusion 360 detect that the model is in cm, not in mm? What should we do?

I imported that STL in a bunch of software just to see if any would guess cm. None of them guessed the right unit size. I think his Fusion360 settings may be set for cm as default unit and didn't guess at all. @BartdaMan https://github.com/BartdaMan When you open a new Fusion360 project what is the default unit size?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ALYN3OXZDX7744PL26SFXEDQKJHXNA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ATWEY#issuecomment-532757267, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYN3OWMUFYZDAZVO4KUE3DQKJHXNANCNFSM4IXBBHEA.

slavedas commented 4 years ago

Just FYI - Adding XY Expansion often fixes these kinds of problems. But I do know that PrusaSlicer is not paying attention to bytes 80-83 of the file which define the number of triangles. If the file is longer than the specified number of triangles, it will just keep parsing. MeshLab does not.

Jebtrix commented 4 years ago

If I start a new project and create a solid, all is in mm. Definitely mm.

Strange indeed. What I find stranger is a STL binary format spec doesn't include a hint for scale unit. Whose bright idea was that :confused:

slavedas commented 4 years ago

Scale is irrelevant for an STL. You could be working in normalized coordinates or real world coordinates for a model. The reader assigns units (such as mm) based on assumptions.

It depends on what the model is for. If the model is a part to fit into an assembly, it had better be properly scaled. If the part is a figurine, then desired size is up to the person doing the printing.

Jebtrix commented 4 years ago

It's called a hint. So a hint of unit size used in export isn't any better than pure assumption? I don't agree with that. A program can just choose to ignore it. Just like a jpeg file can have a dpi setting, its nothing more than a hint. DPI is irrelevant since it depends on output device, but some programs take the hint in scale/rendering if they choose or workflow dictates.

-Edit: Just realized i said scale unit instead of unit size in previous post. It's what i meant.

Jebtrix commented 4 years ago

Adding XY Expansion often fixes these kinds of problems.

@slavedas can you elaborate on that? You mean if a program exports ie a mesh of μm size but in meter units?

slavedas commented 4 years ago

Adding XY Expansion often fixes these kinds of problems.

@slavedas can you elaborate on that? You mean if a program exports ie a mesh of μm size but in meter units?

I mean it fixes the OPs error. Add one nozzle width or so of XY expansion and that error will go away allowing you to print. Basically it will expand those thin layers to be thick enough to print.

Jebtrix commented 4 years ago

Oh with the bottom of his model not being flat? Never tried that as workaround before. @slavedas You are correct though that works.. how in the heck lol. I never have wiggle room on stuff I print it to do that; always has to be exact dimensions. Cool :+1:

slavedas commented 4 years ago

I only know because I am messing with some old code which generates models and exporting them to STL to print. I literally wrote the export code last night and ran into this issue because the models weren't ever made to do more than look cool in a render window.

Jebtrix commented 4 years ago

Ah I see. Going down the clean mesh rabbit hole is definitely a deep one. Good luck with your program.

bubnikv commented 4 years ago

@slavedas

But I do know that PrusaSlicer is not paying attention to bytes 80-83 of the file which define the number of triangles. If the file is longer than the specified number of triangles, it will just keep parsing. MeshLab does not.

PrusaSlicer (the bundled admesh library) reads both the header and the file size. It compares them and if the two do not match, the following warning is emitted to the console for loglevel "info" "stl_open_count_facets: Warning: File size doesn't match number of facets in the header: " and the size of the file is used.

bubnikv commented 4 years ago

XY expansion helps because it fills cracks in the model. By default, PrusaSlicer introduced the parameter "slice_closing_radius" to the configuration layer, it is set to 0.049mm by default for FDM process.

slavedas commented 4 years ago

@slavedas

But I do know that PrusaSlicer is not paying attention to bytes 80-83 of the file which define the number of triangles. If the file is longer than the specified number of triangles, it will just keep parsing. MeshLab does not.

PrusaSlicer (the bundled admesh library) reads both the header and the file size. It compares them and if the two do not match, the following warning is emitted to the console for loglevel "info" "stl_open_count_facets: Warning: File size doesn't match number of facets in the header: " and the size of the file is used.

That's good to know, thanks. It just provides unexpected results if you look at a mesh in another product and then in the slicer and results vary. I PERSONALLY would like a dialog that pops up and says "This STL contains data beyond the indicated length, do you want to load that data?" and maybe a check box to always load it or never load it. But it's low priority. In my case it was definitely because my STL was malformed.

Do the unexpected thing silently doesn't seem optimal to me, but I respect that it's a balance of annoying pop-up error dialogs and what the "correct" behavior is.

bubnikv commented 4 years ago

Do the unexpected thing silently doesn't seem optimal to me, but I respect that it's a balance of annoying pop-up error dialogs and what the "correct" behavior is.

First of all, this behavior came with the admesh library.

st 25. 9. 2019 v 15:54 odesílatel slavedas notifications@github.com napsal:

@slavedas https://github.com/slavedas

But I do know that PrusaSlicer is not paying attention to bytes 80-83 of the file which define the number of triangles. If the file is longer than the specified number of triangles, it will just keep parsing. MeshLab does not.

PrusaSlicer (the bundled admesh library) reads both the header and the file size. It compares them and if the two do not match, the following warning is emitted to the console for loglevel "info" "stl_open_count_facets: Warning: File size doesn't match number of facets in the header: " and the size of the file is used.

That's good to know, thanks. It just provides unexpected results if you look at a mesh in another product and then in the slicer and results vary. I PERSONALLY would like a dialog that pops up and says "This STL contains data beyond the indicated length, do you want to load that data?" and maybe a check box to always load it or never load it. But it's low priority. In my case it was definitely because my STL was malformed.

Do the unexpected thing silently doesn't seem optimal to me, but I respect that it's a balance of annoying pop-up error dialogs and what the "correct" behavior is.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2926?email_source=notifications&email_token=ABMPSI2AXA4GD4SLTKZJMQDQLNUTBA5CNFSM4IXBBHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7R7YDY#issuecomment-535034895, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMPSI3COGE3M5UQVXY4QFDQLNUTBANCNFSM4IXBBHEA .