circular, convex, concave) and performs efficient collision detection agains these build
volumes. As of now, collision detection is performed against a convex
hull of a concave build volume for efficency.
GCodeProcessor::Result renamed out of GCodeProcessor to GCodeProcessorResult,
so it could be forward declared.
Plater newly exports BuildVolume, not Bed3D. Bed3D is a rendering class,
while BuildVolume is a purely geometric class.
Reduced usage of global wxGetApp, the Bed3D is passed as a parameter
to View3D/Preview/GLCanvas.
Convex hull code was extracted from Geometry.cpp/hpp to Geometry/ConvexHulll.cpp,hpp.
New test inside_convex_polygon().
New efficent point inside polygon test: Decompose convex hull
to bottom / top parts and use the decomposition to detect point inside
a convex polygon in O(log n). decompose_convex_polygon_top_bottom(),
inside_convex_polygon().
New Circle constructing functions: circle_ransac() and circle_taubin_newton().
New polygon_is_convex() test with unit tests.
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.
object layer over raft interface:
"first_layer_speed_over_raft", "first_layer_acceleration_over_raft".
Fixes I have a question about the speed of the first layer after the raft. #6623
Fixes Layer After Raft Is Not Considered First Layer! #6166
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.
Newly the PrintObjects own PrintRegions and Print contains references
to PrintRegions owned by PrintObjects, so that a PrintRegion of the same
content is referenced by Print only once.
The refactoring is a WIP to support multi-material painting.
from the background slicing thread, that supports cancellation.
The generic mechanism is used for generating thumbnails into G-code and
Fixes Fix deadlock when canceling the slicing while gcode is creating thumbnails #6476
Thanks @supermerill for pointing out the issue.
Thus the first_layer_height is no more object specific. That makes
a lot of sense due to the brim calculation being performed over
all layers at once and due to future merging of supports of
different objects at first layer.
2) Because now first_layer_height is print specific, the relative
first layer height derived from the object layer height was partially
disabled: First the relative first layer height is converted to
an absolute value when importing config, second the side text
was changed from "mm or %" to "mm". Still the UI allows entering %.
Both changes may be controversial, let's wait for user feedback.
just M600, reset the internal retract counter, so that a retract
will happen after the firmware returns from M600 to the initial position.
Fixes "Blobs on print after manual color change #6362"
- show extra travel acceleration settings in 'Machine limits' page in Printer Settings
when the new firmware flavor is selected
- updated tooltips on the config values (they were basically wrong even in the current version)
- 'Marlin (legacy)' firmware flavor behaviour should not change: it exports M204 Pa Rb Ta
(where a, b are the values from machine limits) at the beginning of gcode and it uses
M204 S... for feature type dependent acceleration settings (legacy variant of M204 P.. T..)
- new Marlin Firmware exports M204 Pa Rb Tc (where a,b,c are the values from machine limits).
Feature type dependent acceleration is set using M204 P..., not overriding the travel acceleration.
This always contains the actual print_z of the toolchange, while layer_z contains the print_z
of the print. The two differ in case that wipe tower without sparse layers is used.
Related to #3834.
