This is a regression wrt. PrusaSlicer 2.4.0-alpha1 due to the G-code
processing optimization and parallelization.
Related to GCode Viewer changes files modified date in windows #5079
TriangleMesh newly only holds indexed_triangle_set and
TriangleMeshStats. TriangleMeshStats contains an excerpt of stl_stats.
TriangleMeshStats are updated when initializing with indexed_triangle_set.
Admesh triangle mesh fixing is newly only used when loading an STL.
AMF / 3MF / OBJ file formats are already indexed triangle sets, thus
they are no more converted to admesh stl_file format, nor fixed
through admesh repair machinery. When importing AMF / 3MF / OBJ files,
volume is calculated and if negative, all faces are flipped. Also
a bounding box and number of open edges is calculated.
Implemented its_number_of_patches(), its_num_open_edges()
Optimized its_split(), its_is_splittable() using a visitor pattern.
Reworked QHull integration into TriangleMesh:
1) Face normals were not right.
2) Indexed triangle set is newly emitted instead of duplicating
vertices for each face.
Fixed cut_mesh(): Orient the triangulated faces correctly.
WIP to G-code export parallelization through pipelining:
Decoupled CoolingBuffer from GCode / GCodeWriter, ready to be
pipelined on a different thread.
WIP to G-code export parallelization through pipelining:
GCodeProcessor is called during the G-code export,
the G-code is no more reopened and re-read, but it is pipelined
from the G-code generator.
GCodeViewer no more parses G-code just to extract line end positions.
Removed start_mapping_gcode_window(), void stop_mapping_gcode_window(),
they are no more needed.
1) Starting with this commit, configuration block exported into G-code
is delimited by "; prusaslicer_config = begin" and "; prusaslicer_config = end".
These delimiters look like any other key / value configuration pairs
on purpose to be compatible with older PrusaSlicer config parsing from G-code.
2) Config parser from G-code newly searches for "; generated by ..."
comment over the complete G-code, thus it is compatible with various
post processing scripts extending the G-code at the start.
3) Config parser from G-code parses PrusaSlicer version from
the "; generated by PrusaSlicer ...." header and if the G-code was
generated by PrusaSlicer 2.4.0-alpha0 and newer, it expects that
the G-code already contains the "; prusaslicer_config = begin / end"
tags and it relies on these tags to extract configuration.
4) A new simple and robust parser was written for reading project configuration
from 3MF / AMF, while a heuristic parser to read config from G-code located
at the end of the G-code file was used before.
- The optional output_name file might contain the .pp suffix.
- In case the file contains just filename, prepend it with the
output dir. We don't want to save to current workdir.
1) New environment variable SLIC3R_PP_HOST contains one of
"File", "PrusaLink", "Repetier", "SL1Host", "OctoPrint", "FlashAir", "Duet", "AstroBox" ...
2) New environment variable SLIC3R_PP_OUTPUT_NAME contains the name
of the G-code file including path (for SLIC3R_PP_HOST == "File")
or a name of the file after upload to the host (PrusaLink, Octoprint ...)
3) The post-processing script may suggest a new output file name
(likely based on SLIC3R_PP_OUTPUT_NAME) by saving it as a single line
into a new "output name" temp file. The "output name" file name is
created by suffixing the input G-code file name with ".output_name".
Please note that the G-code viewer visualizes G-code before post-processing.
Fixes Broken PostProcessing when script changes out-filename #6042
