Failure to read binary STL files on Windows 64bit (was: Disable repair of non-manifold objects)

[llluis]

Hi, I'm not able to open "supposed" non-manifold objects, which works perfectly in 0.9.10b, in the current dev version.

I noticed that the TriangleMesh classes were re-factored, but I was not able to disable the manifoldness verification.

Is there a way to disable the repair so it behaves as 0.9.10b?

Example of a STL which works in 0.9.10b and does not work on 0.9.11-dev: https://dl.dropboxusercontent.com/u/4637549/AJGW-GearsHering_BowdenBig.stl

0.9.10b:

0.9.11-dev

[c-born]

I get the same warning in Revision: d8e2cde9625d75d6f78774e0366b60eb88b49e4f when run on good objects with no manifold errors that work in previous releases, so I imagine it is just a temporary problem that will be fixed soon. The same revision doesn't build, with error:

t\support.t .......... 1/13 Argument "100%" isn't numeric in numeric lt (<) at D:/usr/CNC/Test/Slic3r/t/../lib/Slic3r/Print/Object.pm line 913.

Changing the "100%" to "0.4" gets the build to work, but it complains (as above) and doesn't produce usable output.

[alranel]

That STL is loaded just fine in current git HEAD. I guess what you saw was caused by a couple things. The warning was shown even when nothing was changed in the STL file. Also, thumbnail generation cut out some parts so the plater view did not match the actual mesh data used internally.

[c-born]

I just built from the current Git HEAD and tried again, still problems. It reports manifold errors with even a basic rectangular block, which have no errors according to Rhino, NetFABB, and Slic3r 0.9.10b. The resulting GCode is unusable or non-existent. So as you are getting good results, I figure the problem must be in the build.

Here is what I see when I build on Win7 X64 using CitrusPerl. There are two suspect areas, which I've highlighted in red. However at the end, it says PASS. If you get these and it still works, it must be something else, and i can provide more info.

[BTW I just have to say that I am REALLY impressed with the software now (or at least, with 0.9.10b!). The "don't cross borders" has made a huge difference, so that I hardly need to do any post-build cleanups any more. I've just finished a run of over 100 objects (connectors, pivot hinges, etc for low-volume industrial instruments) with build times of between 1 and 3 hours per part. Being able to batch up to 12 at once, on smaller parts, and let the machine run overnight, has been a great time-saver.]

D:\usr\CNC\Slic3r>perl build.pl App::cpanminus is up to date. (1.6940) Boost::Geometry::Utils is up to date. (0.15) Class::XSAccessor is up to date. (1.18) Encode::Locale is up to date. (1.03) skipping R/RJ/RJBS/perl-5.18.0.tar.bz2 File::Spec is up to date. (3.40) Getopt::Long is up to date. (2.41) Growl::GNTP is up to date. (0.20) IO::Scalar is up to date. (2.110) Math::Clipper is up to date. (1.22) Math::ConvexHull::MonotoneChain is up to date. (0.01) Math::Geometry::Voronoi is up to date. (1.3) Math::PlanePath is up to date. (108) Moo is up to date. (1.003000) Scalar::Util is up to date. (1.30) Storable is up to date. (2.45) Test::More is up to date. (0.98) Time::HiRes is up to date. (1.9725) --> Working on XML::SAX::ExpatXS Fetching http://www.cpan.org/authors/id/P/PC/PCIMPRICH/XML-SAX-ExpatXS-1.33.tar.gz... OK Configuring XML-SAX-ExpatXS-1.33 ... N/A ! Configure failed for XML-SAX-ExpatXS-1.33. See C:\Users\cborn.cpanm\build.log for details. --> Working on SMUELLER/ExtUtils-ParseXS-3.18_04.tar.gz Fetching http://www.cpan.org/authors/id/S/SM/SMUELLER/ExtUtils-ParseXS-3.18_04.tar.gz... OK Configuring ExtUtils-ParseXS-3.18_04 ... OK Building and testing ExtUtils-ParseXS-3.18_04 ... OK Successfully installed ExtUtils-ParseXS-3.1804 1 distribution installed '.' is not recognized as an internal or external command,_ operable program or batch file. --> Working on ./xs Configuring D:/usr/CNC/Slic3r/xs ... OK Building and testing Slic3r-XS-0.01 ... OK Successfully installed Slic3r-XS-0.01 1 distribution installed t\angles.t ........... ok t\arcs.t ............. ok t\clean_polylines.t .. ok t\clipper.t .......... ok t\collinear.t ........ ok t\combineinfill.t .... ok t\cooling.t .......... ok t\custom_gcode.t ..... ok t\dynamic.t .......... skipped: variable-width paths are currently disabled t\fill.t ............. ok t\gcode.t ............ ok t\geometry.t ......... ok t\layers.t ........... ok t\loops.t ............ ok t\perimeters.t ....... ok t\polyclip.t ......... ok t\print.t ............ ok t\retraction.t ....... ok t\serialize.t ........ ok t\shells.t ........... ok t\skirt_brim.t ....... ok t\slice.t ............ ok t\support.t .......... ok t\svg.t .............. ok t\vibrationlimit.t ... ok All tests successful. Files=25, Tests=239, 56 wallclock secs ( 0.13 usr + 0.01 sys = 0.14 CPU) Result: PASS

On Sun, Aug 11, 2013 at 5:59 AM, Alessandro Ranellucci < notifications@github.com> wrote:

That STL is loaded just fine in current git HEAD. I guess what you saw was caused by a couple things. The warning was shown even when nothing was changed in the STL file. Also, thumbnail generation cut out some parts so the plater view did not match the actual mesh data used internally.

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1370#issuecomment-22446269 .

[alranel]

Uhm, your build looks fine. So you're still getting the manifoldness warning with the original test case of this issue? If you have one more test case, can you upload it for me?

[c-born]

Simple rectangular bar rod. Current Git-HEAD build complains of manifold errors on input. Console prints "Warning: File size doesn't match number of facets in the header" On exporting G-code, "No layers were detected..."

https://dl.dropboxusercontent.com/u/7955521/Bar.stl https://dl.dropboxusercontent.com/u/7955521/config.ini

[c-born]

I downloaded an ASCII <=> Binary STL converter from http://www.thingiverse.com/thing:39655 and converted the binary STL file Bar.stl to ASCII, and Slic3r loaded and sliced it without complaint.

I then used the same program to convert it back to binary format, now slic3r exits immediately with the message "The file R:\Bar-ascii-binary.stl has the wrong size."

Sounds like a problem with Binary-STL input?

[llluis]

Tried today with the head version and I am still getting the same error, even with the original STL provided in my first message. I get the manifoldness message along with an incorrect visualization. If I try to slice it, the output is just the skirt, as the visualization.

[alranel]

Well, so far it looks like this issue is misnamed: the issue you're reporting is that you're not able to open binary STL files on Windows. And this has to be investigated, as the new code for STL reading might not be correctly multiplatform due to some endianness problem. It doesn't look like this has anything to do with repair of non-manifold files, nor that an option for disabling that feature would help in this case. I'll check the above in a few days.

[llluis]

To the end user, the problem seems to be related to manifoldness, as this is the message that is displayed, but I agree that the problem might be related to binary files. My setup is a Windows 7 x64, using CitrusPerl 5.14.2.1 x64.

I will try to get an ASCII <> Binary STL converter and validate with my files.

[llluis]

Netfabb free is able to export in binary or ASCII STL. :-)

Confirmed that the problem is related to binary files only. Same files in ASCII format opens normally.

However, I identified something weird during testing. The file https://dl.dropboxusercontent.com/u/4637549/AJGW-ExtruderASCII.zip slices incorrectly. All holes on the motor support came out solid. Maybe something related to manifoldness?

[alranel]

Hello, I can't reproduce this issue on Win7 64-bit and current master. Can you check and confirm that it was fixed in the mean time?

(git pull and perl Build.pl)

[llluis]

I had a problem building from current master. Hit a bug with Test:Harness: https://rt.cpan.org/Public/Bug/Display.html?id=75375 (although different platform, same test error)

Forced install and Slic3r built successfully.

However, when trying to open the file (https://dl.dropboxusercontent.com/u/4637549/AJGW-GearsHering_BowdenBig.stl), I've got the following error on command window (Slic3r suddenly closed with no message):

C:\Program Files\Slic3r-master>perl slic3r.pl Use of uninitialized value in subtraction (-) at C:/Program Files/Slic3r-master/lib/Slic3r/Geometry/BoundingBox.pm line 113.

[alranel]

Hello! I managed to reproduce and fix this bug. Can you please confirm?

[llluis]

Confirmed, everything working perfectly now!