Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full re-write of spiral vase #3091

Merged
merged 6 commits into from
Dec 17, 2023

Conversation

andrewboktor
Copy link
Contributor

@andrewboktor andrewboktor commented Dec 12, 2023

Fixes:
prusa3d/PrusaSlicer#2841
bambulab/BambuStudio#2744
slic3r/Slic3r#5160
slic3r/Slic3r#4360

  • Adds transition_out layer at the top to prevent sharp edge at the top of spiral vase. (cannot be turned on/off)
  • Adds XY interpolation, configurable param for max distance for interpolation (absolute or % of nozzle_diameter, default 200%)
  • Adds option to turn XY interpolation on/off

image
image
image
image
image
image

- Adds transition out to prevent sharp edge at the top of spiral vase.
- Adds XY interpolation
- Adds option to turn XY interpolation on/off
@andrewboktor
Copy link
Contributor Author

IMPORTANT: I really need help getting line_width in SpiralVase.cpp. As is right now, this will only work properly for line widths < 0.8mm or so.

@andrewboktor
Copy link
Contributor Author

IMPORTANT: I really need help getting line_width in SpiralVase.cpp. As is right now, this will only work properly for line widths < 0.8mm or so.

Should we just add a new config "spiral_vase_max_xy_smoothing" that defaults to outer wall line width? What do y'all think about that idea?

@SoftFever
Copy link
Owner

IMPORTANT: I really need help getting line_width in SpiralVase.cpp. As is right now, this will only work properly for line widths < 0.8mm or so.

Hi @andrewboktor
In vase mode, we use outer_wall_line_width to define the shell thickness, which is set in the PrintRegionConfig. Currently, the SpiralVase class takes a PrintConfig parameter in its constructor. We could modify the class to accept an additional PrintRegionConfig parameter.

Then, the configuration can be passed as shown bellow(in GCode.cpp:1907)

    if (print.config().spiral_mode.value)
        m_spiral_vase = make_unique<SpiralVase>(print.config(),print.default_region_config());

@SoftFever
Copy link
Owner

IMPORTANT: I really need help getting line_width in SpiralVase.cpp. As is right now, this will only work properly for line widths < 0.8mm or so.

Should we just add a new config "spiral_vase_max_xy_smoothing" that defaults to outer wall line width? What do y'all think about that idea?

Adding this new parameter makes sense to me

@SoftFever SoftFever linked an issue Dec 12, 2023 that may be closed by this pull request
@Noisyfox
Copy link
Collaborator

IMPORTANT: I really need help getting line_width in SpiralVase.cpp. As is right now, this will only work properly for line widths < 0.8mm or so.

Hi @andrewboktor In vase mode, we use outer_wall_line_width to define the shell thickness, which is set in the PrintRegionConfig. Currently, the SpiralVase class takes a PrintConfig parameter in its constructor. We could modify the class to accept an additional PrintRegionConfig parameter.

Then, the configuration can be passed as shown bellow(in GCode.cpp:1907)

    if (print.config().spiral_mode.value)
        m_spiral_vase = make_unique<SpiralVase>(print.config(),print.default_region_config());

Ah this could be much simpler if no variable extrusion width is used then. And what if there are multiple objects that uses different line width?

@andrewboktor
Copy link
Contributor Author

andrewboktor commented Dec 12, 2023

Ah this could be much simpler if no variable extrusion width is used then. And what if there are multiple objects that uses different line width?

Can't we grab that setting "per object"? I don't know how to do that, but in theory it seems possible that we just grab the setting per object and that way each object will behave correction.

@Noisyfox
Copy link
Collaborator

Ah this could be much simpler if no variable extrusion width is used then. And what if there are multiple objects that uses different line width?

Can't we grab that setting "per object"? I don't know how to do that, but in theory it seems possible that we just grab the setting per object and that way each object will behave correction.

The problem is this filter works per-layer, so you need a way to pass the corresponding object settings to it at each call. Fortunately vase mode does not support multiple objects with per-layer mode, so at least we don't need to deal with the problem that the gcode of a given layer comes from multiple objects which could have different line width.

if (in.nop_layer_result)
return in;

spiral_mode.enable(in.spiral_vase_enable);
return { spiral_mode.process_layer(std::move(in.gcode)), in.layer_id, in.spiral_vase_enable, in.cooling_buffer_flush };
bool last_layer = in.layer_id==layers_to_print.size()-1;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pass the current printobject's region config here

@SoftFever
Copy link
Owner

To pass per-object wall width to the filter, we need to access the region config of the current PrintObject (as noted in the code review comments). In spiral mode, since there's typically only one region, taking the first region should suffice.

However, after giving it some thought, I'm inclined towards your second proposal to introduce a new parameter, spiral_vase_max_xy_smoothing. Just don't forget to make it accept either an absolute value or a percentage of the nozzle diameter, and we will be good.

@Noisyfox
Copy link
Collaborator

nozzle diameter

nozzle diameter or line width?

…than that)

- Excluding all travel moves (I saw a bug where somehow we ended up with travel moves within the print so excluding all travel moves)
@andrewboktor
Copy link
Contributor Author

nozzle diameter

nozzle diameter or line width?

This should really be proportional to the object's outer_wall_line_width. So I guess there is not escaping getting and passing that setting properly. The new parameter doesn't solve any problems other than making things configurable so that if someone doesn't like what they see, then they can change it.

@SoftFever
Copy link
Owner

SoftFever commented Dec 13, 2023

I meant nozzle diameter(to save the hassle) ;)
Since it serves as a deviation cap, it doesn't matter much whether it's a percentage of the line width or the nozzle diameter.
But if you're keen on using the line width, by all means, go ahead. That would be ideal too

@andrewboktor
Copy link
Contributor Author

I meant nozzle diameter(to save the hassle) ;) Since it serves as a deviation cap, it doesn't matter much whether it's a percentage of the line width or the nozzle diameter. But if you're keen on using the line width, by all means, go ahead. That would be ideal too

I thought about this long and hard. And I think we should make this configurable as a separate param, proportional to nozzle_diameter, get this PR in and get eyes on it and iterate from there. Otherwise we're probably gonna go down a (mostly unnecessary) rabbit hole.

@SoftFever
Copy link
Owner

I meant nozzle diameter(to save the hassle) ;) Since it serves as a deviation cap, it doesn't matter much whether it's a percentage of the line width or the nozzle diameter. But if you're keen on using the line width, by all means, go ahead. That would be ideal too

I thought about this long and hard. And I think we should make this configurable as a separate param, proportional to nozzle_diameter, get this PR in and get eyes on it and iterate from there. Otherwise we're probably gonna go down a (mostly unnecessary) rabbit hole.

Exactly my thought as well

@andrewboktor
Copy link
Contributor Author

Exactly my thought as well

Now the question is how do I get the right nozzle diameter. It seems that nozzle diameter is a floats, i.e. I have to find the right tool. Or should I just use nozzle_diameter[0]?

@SoftFever
Copy link
Owner

Exactly my thought as well

Now the question is how do I get the right nozzle diameter. It seems that nozzle diameter is a floats, i.e. I have to find the right tool. Or should I just use nozzle_diameter[0]?

you can use EXTRUDER_CONFIG(nozzle_diameter); to get the corresponding nozzle diameter in process_layers function.

SoftFever and others added 2 commits December 15, 2023 09:01
…meter

- fixed no-op travel moves in the middle of spiral that now show up as defects when Smooth Spiral is enabled!
@andrewboktor
Copy link
Contributor Author

you can use EXTRUDER_CONFIG(nozzle_diameter); to get the corresponding nozzle diameter in process_layers function.

That worked fantastic! PR is now ready to go.

@Noisyfox
Copy link
Collaborator

Noisyfox commented Dec 16, 2023

image
Invalid gcode are generated and the gcode preview shows only the bottom half of the cone (because of the NaN).
Cone.3mf.txt

@Noisyfox
Copy link
Collaborator

The issue was caused by the fact that the dist_XY is 0, as shown in the gcode that both lines have the exact same position
image

@Noisyfox
Copy link
Collaborator

Noisyfox commented Dec 16, 2023

image
This is the original gcode, which has a very small amount of the extrusion.

I suggest that if dist_XY < EPSILON (or <=0) then we do not modify the extrusion.

src/libslic3r/GCode/SpiralVase.hpp Outdated Show resolved Hide resolved
@@ -68,30 +135,69 @@ std::string SpiralVase::process_layer(const std::string &gcode)
return;
} else {
float dist_XY = line.dist_XY(reader);
if (dist_XY > 0) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my other comments, this check needs to be kept, otherwise we could produce NaN.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On it, easy fix. We can't revert this bit to what it was before because of the zero length segments that appear in the gcode but we can definitely avoid doing the computation that explodes and just omit that segment altogether.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be fixed now! I can't repro so @Noisyfox if you can give this another try or send me repro steps that would be great.

vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 17, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 19, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 20, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 20, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 23, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 24, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 25, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 25, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 25, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 25, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 26, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 26, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Jan 31, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 7, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 10, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 11, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 14, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 21, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 22, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 26, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 26, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 27, 2024
vovodroid added a commit to vovodroid/PrusaSlicer that referenced this pull request Feb 28, 2024
@m50434
Copy link

m50434 commented Feb 29, 2024

Hi @andrewboktor
I have still some issues with the spriral vase mode.
If I only turn on the spiral vase without "Smoothing", my layers look like this:

grafik

grafik

Like you can see, there are some little things that doesnt look nice.
Interestingly, these are the only places on the entire object that look like this.

But if I now turn on smooth, its looks like this:

grafik
grafik

Not much better, on the contrary the edges have become much worse or uglier. This is what it looks like after printing.

Any ideas?

@andrewboktor
Copy link
Contributor Author

@m50434 Can you share the 3mf and exact version (please retry on latest released version) used to expose those problems?

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request May 19, 2024
PrusaSlicer 2.7.4

Summary

This is stable release of PrusaSlicer 2.7.4. This release improves loading of
3MFs generated by BambuStudio and fixes a single bug found in 2.7.3.

Improvements with respect to 2.7.3

- Objects from 3MFs generated by BambuStudio now retain multimaterial painting
  when loaded. BambuStudio saves the data under a changed name, but because both
  the location and meaning are the same, PrusaSlicer now tries to load the data
  under the new name when it fails to find the attribute that PrusaSlicer has
  always used. #12502

Bugs fixed with respect to 2.7.3

- macOS and Linux specific: Downloading files from Printables did not work
  correctly (#12521).

PrusaSlicer 2.7.3

Summary

This is stable release of PrusaSlicer 2.7.3. This release is functionally
equivalent to 2.7.3-rc1. Please, read the change logs of 2.7.3-alpha1,
2.7.3-beta1 and 2.7.3-rc1 for the complete list of bugfixes and improvements
over 2.7.2.

If any of the PrusaSlicer 2.7.3 alphas or betas was used before on the same
machine, PrusaSlicer 2.7.3 will offer to import such alpha or beta
configuration when it is first executed.

PrusaSlicer 2.7.3-rc1

Summary

This is the first release candidate of PrusaSlicer 2.7.3, which fixes a single
bug found in the previous beta. Please, read the change logs of 2.7.3-alpha1
and 2.7.3-beta1 for the complete list of bugfixes and improvements over 2.7.2.

The release candidate saves its profiles into regular PrusaSlicer configuration
directory. When you first run it, it will search for all configurations
produced by alpha or beta versions and offer to create a copy of the latest one.

Bug fixes with respect to 2.7.3-beta1

- Removed negligible deretractions sometimes emitted into the G-code after the
  recently introduced spiral vase mode improvements. While they did not present
  actual issues with the print, they were confusingly shown in the G-code
  preview.

PrusaSlicer 2.7.3-beta1

Summary

This is the first beta release of PrusaSlicer 2.7.3, which fixes bugs found in
the previous alpha. Please, read the change log of 2.7.3-alpha1 for the
complete list of bugfixes and improvements over 2.7.2.

To let you enjoy the beta without worries, the beta builds save their profiles
into PrusaSlicer-beta directory, so you may use the beta side by side with the
current release without ruining your production configuration. The beta will
ask whether it should import a configuration from previously run PrusaSlicer
versions on the first start.

Bug fixes with respect to 2.7.3-alpha1

- The z offset configuration option was not correctly accounted for when doing
  the last filament unload above the wipe tower.
- Fixed crash when importing a specific config bundle while in SLA mode.
- Linux specific: When changing active profile using the dropdown in the right
  panel, the dropdown would stay open when Unsaved Changes dialog was shown.
- The improvemroduced in the previous alpha did not work correctly with
  absolute extruder addressing (#2841 (comment)). They are now only applied
  with relative extruder addressing, otherwise it falls back to the old
  behaviour.
- After performing a toolchange on the wipe tower, a G-code to set layer z is
  now always emitted. This is to make sure that the layer z is correct and that
  it was not changed in custom toolchange G-code. While the user is expected to
  pass such information in the custom G-code, the "z-ensuring" G-code was
  present in previous versions and removing it in 2.7.2 was therefore a
  needless breaking change (#12361).
- Fixed blobs on the first layer when using ramping travels with absolute
  extruder addressing enabled.
- Fixed issues with 'avoid crossing perimeters' function (#12432). This problem
  was actually fixed in 2.7.3-alpha1 already.

Infrastructure

- Linux specific: The desktop integration code inside PrusaSlicer can now be
  disabled at compile time. This is useful when deploying the application using
  Flakpak, because it can take care of the desktop integration itself. Thanks
  to @eliadevito for providing a PR (#12252) and maintaining the Flatpak build.

Translations

- Updated CS, DE, ES, FR, IT, PL, JA dictionaries.

PrusaSlicer 2.7.3-alpha1

Summary

This is the first public alpha release of PrusaSlicer 2.7.3. This release
introduces improvements of multi-material printing, improvements of spiral vase
mode and several important bugfixes.

To let you enjoy the alpha without worries, the alpha builds save their
profiles into PrusaSlicer-alpha directory, so you may use the alpha side by
side with the current release without ruining your production configuration.
The alpha will ask whether it should import a configuration from previously run
PrusaSlicer versions on the first start.

Improvements of multi-material printing

For a long time, a community-developed feature exists which claims to improve
filament tips during toolchange sequences, which would in turn increase
reliability of devices depending on reasonable tip shape (such as Prusa MMU1
and MMU2). This feature is referred to as "skinnydip", and the basic principle
is to push the filament back into the melt zone after it was unloaded to melt
off the thin string that the filament often has. We at Prusa Research have
tested the feature several times, but the results were not very convincing and
we never integrated the feature into PrusaSlicer. After doing more experiments
recently, we found out that the technique is more convincing when preceded by
very rapid ramming.

Based on that knowledge, we decided to implement very similar approach for
reshaping the filament tip. Because the goal is to reshape the filament tip
using the mostly empty nozzle, instead of melting off the thin filament tip, we
call our approach "stamping". There are two new parameters in Filament Settings
(filament_stamping_distance and filament_stamping_loading_speed) which control
how far and how fast should the filament be pushed after the initial unload.
The stamping moves are coupled with cooling - the stamping moves are performed
between the individual cooling moves.

We would like to highlight community projects that helped us develop our
Stamping step and saved our developers and testers a significant amount of time
- Skinny Dip post processing script by Erik Bjorgan and Dribbling by Antimix.
While we ended up with a different approach, we would like to thank both
authors for all the effort invested into the project and for making it
open-source! (Related to #2385, #2452, #2729, mentioning @domesticatedviking
and @antimix.)

Purging volumes

PrusaSlicer allows to set purging volumes for single-extruder multi-material
printers, so that each filament is purged exactly as it needs to. However,
these settings were only saved in the 3MF project, not in configuration. This
made setting them quite cumbersome and the user would always need to think
about adjusting the default values. On the other hand, setting the values only
in configuration without the option to override it in the project is also
inadequate, because one may care about purging more in one project and less in
another. In addition, the configuration option would make sense both in
Filament and Printer Settings. #1273, #1282, #2990, #3756

In this release, two additional configuration options were added. The volume to
purge is set using multimaterial_purging in Printer Settings->Single extruder
MM setup. This value can be further modified on filament level using
filament_purge_multiplier in Filament Settings->Advanced.

As for the project-specific override, the "Purging volumes" dialog now contains
a switch. You can either use the values from Filament and Printer profiles (as
described above) or define your own matrix of purging volumes (like in previous
PrusaSlicer versions). When you decide to do that, the values from the
configuration are not used.

Spiral vase mode improvements

When using spiral vase mode, the toolpaths are generated as usual and the
resulting extrusions are then extruded while gradually increasing z. This
approach led to seam-like artifacts on the print in places where the layer
transitions would normally be (#4116, #2841). In addition, the last layer would
end abruptly, creating a sharp "edge" where the extrusion ends.

Both these issues were addressed by @andrewboktor by interpolating between
adjacent layers and by gradually reducing extrusion flow at the very end of the
print. The improvement was recently merged into OrcaSlicer
(SoftFever/OrcaSlicer#3091), and we got a pull request with a port to
PrusaSlicer. After we evaluated the feature, we decided to merge it because it
is well written, well working and very useful.

Thanks to @andrewboktor for the time and effort invested into the issue, and to
both @vovodroid and @tg73 for providing a pull request with a port from
OrcaSlicer (#12079, #12142).

Other improvements with respect to 2.7.2

- PrusaSlicer is now able to open 3MF files generated by BambuStudio and load
  geometry from them. (#10718, PR #10808, thanks to @cmguo). Please note that
  BambuStudio allows to save a 3MF containing G-code only, which is not
  supported by PrusaSlicer and loading of such 3MFs will fail.
- Metadata of binary G-code have a new item named objects_info, which lists all
  the objects in the print and their boundary polygons. The same info was added
  into the comments at the end of ASCII G-codes.

Bugfixes with respect to 2.7.2

- Pressure equalizer limits were not respected when Dynamic speed on overhangs
  was used (#9485). This is now fixed. Pressure equalizer is also not applied
  after long travels. Many thanks to @MGunlogson for providing a fix in his
  pull request #9622.
- Fixed a bug resulting in inadequate anchoring of bridging extrusions. This
  bug was introduced in PrusaSlicer 2.6.0. #10231, #11500, #11633, #11173,
  #11117, #9999, #10313, #11150, #10493
- When using Cancel object feature, the marks denoting where one object ends
  and another starts were placed incorrectly. As a result, there was a missing
  deretraction after all travels to objects which would normally be printed
  following the cancelled object. The issue was even worse with sequential
  printing, where the uncompensated retractions on the cancelled object summed
  up and could result in filament being unloaded past the driving gears.
- When arcs (G2 and G3 G-codes) were enabled, PrusaSlicer generated toolpaths
  outside the print area in certain cases (#12381).

Translations

- Updated POT
- Added Slovenian translation (#12422, thanks to @jernejp21)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Z-seam is present in Spiral Vase mode in OrcaSlicer
5 participants