Fix small area infill flow compensation (graph version) causing some lines to not extrude (#4374) #4399
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- fix value of branch diameter angle of the organic support - fix overhang speed values
Turn off feature 'use_surface' for new text object
update snapmaker profiles
…reported in prusa3d#11721. The temporary variable used for reordering ExPolygons wasn't cleared, and it contained empty ExPolygons from previous reordering. This caused those empty ExPolygons replaced actual ExPolygons for infill. Another issue was that m_fill_expolygons was reordered, but m_fill_expolygons_bboxes were left untouched.
. arcs merged into a new structure (ArcPolyline)
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
…ence the warning. The warning was there because std::string_view::data() returns a pointer to a buffer that is not necessarily null-terminated. So, strncpy shouldn't be used on non-null-terminated buffers, but we always relied only on the buffer length, so it couldn't cause any issues.
Actually, all those deprecated functions were internally called those new functions. So there isn't any risk to use them directly.
…ed() in Arc Welder.
…re there just for debugging purposes.
This variable hasn't been used since the beginning.
…_progress() inside check_objects_after_cut().
…3r::GUI::GUI_App class.
…te_compatible_internal(). This variable hasn't been used since the beginning.
…nymous> may be used uninitialized in this function). This warning was shown because the previous code was triggering a bug in GCC. More about the bug can be found here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465.
* add gcode_command_buffer (int, firmware command queue size) * add gcode_min_resolution (now gcode_resolution from prusa is converted to that) (now float or percent of perimeter width) * rename min_length into gcode_min_length (now float or percent of perimeter width) * new algorithm: use gcode_command_buffer to allow some leeway around max_gcode_per_second, with gcode_min_resolution as upper threshold and gcode_min_length as lower one. * use resolution_internal instead of gcode_resolution for support, generate_sparse_infill_polylines_for_anchoring
- fix merge: now refresh is handled more efficiently, not recomputing what's not needed. - fix merge: layer duration is now taken from m_layers_times instead of the Path (is it really better?) - chronology: now use the block times, instead of the machine, because the machine is not enough granular and is late - allow chronology to have min/max from layer selection
add another step to post-process the import. add import of 'make_overhang_printable' into 'overhangs_max_slope' drag-drop 3mf also detect bbs project, spawning the pop-up.
force automake 1.16 for macos, as mpfr need at least the 1.16
* overhangs_bridge_threshold * overhangs_bridge_upper_layers * perimeters_hole * support_material_bottom_interface_layers
- Make the input range checks consistent with start_idx, end_idx of existing implementation - Make default extrusion factor 1.0f to prevent similar issues - Small readability improvements
supermerill
force-pushed
the
nightly_dev
branch
from
787415d
to
5dc2ae8
Compare
|
Thanks, merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello 3D printing crew
I found the issue that the user was presenting in #4374. The problem was that the actual graph points data structure and
begin_idx,end_idxusage were inconsistent in this function. As a result, all extrusion lengths above the max value we account for in the graph (~3.0mm in our case) were not interpolated and got a multiplication factor of 0 instead (the default in this function). I am not sure why the graph implementation works as it does but these changes make this function comply with how the graph and its data structures are currently implemented.Below is the user's scenario as an example, working as expected.
Additional fixes:
y_valueto 1.0f, so the default behaviour leaves the extrusion value as it was.(I): This can cause some discrepancies if we have 2 lines with very close but not equal lengths, as they will both get assigned the same extrusion factor. We could remove this check or make it compare from the left side only, but then again it is a small performance optimization. I leave this decision to the owner :)
(II): A question on the feature; should the feature's function not be monotonically non-decreasing? I personally cannot think of a case where a shorter line should extrude more than a longer one.