search

SoftFever / OrcaSlicer

G-code generator for 3D printers (Bambu, Prusa, Voron, VzBot, RatRig, Creality, etc.)
https://discord.gg/P4VE9UY9gJ
GNU Affero General Public License v3.0
7.3k stars 865 forks source link

Add support for "Non-Planar Top Layer Fuzzyskin" #7152

Open misterjmw opened 4 weeks ago

misterjmw commented 4 weeks ago

Is there an existing issue for this feature request?

Is your feature request related to a problem?

It would be nice to have a toggle-able feature to support fuzzy skin on non-planar, top surfaces.

Which printers will be beneficial to this feature?

All

Describe the solution you'd like

A dev has created and tested this feature with several slicers and is open source. It would be nice to see an integration of the functionality from https://github.com/TengerTechnologies/Fuzzyficator as an Orcaslicer feature. Discussion on the project can be found here.. The feature should work with Marlin and Klipper.

Describe alternatives you've considered

The only alternative I'm aware of is GCode post-processing, which is a nuisance.

Additional context

No response

kdegeek commented 4 weeks ago

You beat me to this by 13 mins haha

Rickthebig commented 4 weeks ago

"The feature should work with Marlin and Klipper" What about RRF? Something against implementing it also to work with RRF? Or just completely agnostic of the gcode flavor used?

misterjmw commented 4 weeks ago

"The feature should work with Marlin and Klipper" What about RRF? Something against implementing it also to work with RRF? Or just completely agnostic of the gcode flavor used?

The form only asks about Marlin and Klipper. Anything outside of that, I have no/too little experience to provide an answer. Generally I feel that a casual omission should not be taken as a statement of explicit exclusion, e.g. "It will not work with ____".

vgdh commented 4 weeks ago

Have you tested it? How is the quality? I would love to see some photos.

misterjmw commented 3 weeks ago

Have you tested it? How is the quality? I would love to see some photos.

There are photos and videos in the discussion topic, and a youtube video here: https://www.youtube.com/watch?v=EhKnqHey6l8

I have not tested it with Orca itself.

DVSVIDEO commented 3 weeks ago

Very good idea, it would be nice to have such a feature. Something similar already existed: a sawtooth pattern in the Superslicer. It didn't work like that, but instead of a smooth surface it made this ridge https://youtu.be/8iwV5OW9rEQ?si=r7oarACikfdgY10x&t=203

PhilBaz commented 3 weeks ago

youtube.com/watch?v=EhKnqHey6l8

Fuzzy top skin. Obviously this is amazing.

PhilBaz commented 3 weeks ago

@DVSVIDEO Ohh, that's super cool too!

TengerTechnologies commented 3 weeks ago

I will make some more testprints. I don't think it's ready for an implementation yet. I've planned to implement it into orca and then make a PR when ready, but first it should work flawless as a postprocessing script.

TengerTechnologies commented 3 weeks ago

"The feature should work with Marlin and Klipper" What about RRF? Something against implementing it also to work with RRF? Or just completely agnostic of the gcode flavor used?

It currently is only tested with Marlinflavour

vgdh commented 2 weeks ago

"The feature should work with Marlin and Klipper" What about RRF? Something against implementing it also to work with RRF? Or just completely agnostic of the gcode flavor used?

It currently is only tested with Marlinflavour

It doesn't work with orca gcode, because orca issues z coordinate in every command on top layer https://github.com/SoftFever/OrcaSlicer/issues/7207 and also script uses prusa stile of layer type tips (don't remember exactly but it something like ;Type top layer) so little modification to the script can fix it.

TengerTechnologies commented 2 weeks ago

"The feature should work with Marlin and Klipper" What about RRF? Something against implementing it also to work with RRF? Or just completely agnostic of the gcode flavor used?

It currently is only tested with Marlinflavour

It doesn't work with orca gcode, because orca issues z coordinate in every command on top layer https://github.com/SoftFever/OrcaSlicer/issues/7207 and also script uses prusa stile of layer type tips (don't remember exactly but it something like ;Type top layer) so little modification to the script can fix it.

To implement it in orca slicer I would do it in the gcode generation, not as postprocessing. So the script is not usable anyways.

A postprocessing script for orca is nearly ready for release. I just have to further test it.(Probably done and commited by the end of the weekend)

igiannakas commented 6 days ago

"The feature should work with Marlin and Klipper" What about RRF? Something against implementing it also to work with RRF? Or just completely agnostic of the gcode flavor used?

It currently is only tested with Marlinflavour

It doesn't work with orca gcode, because orca issues z coordinate in every command on top layer #7207 and also script uses prusa stile of layer type tips (don't remember exactly but it something like ;Type top layer) so little modification to the script can fix it.

To implement it in orca slicer I would do it in the gcode generation, not as postprocessing. So the script is not usable anyways.

A postprocessing script for orca is nearly ready for release. I just have to further test it.(Probably done and commited by the end of the weekend)

I’ve been intrigued by this and am keen to start implementing this in orca.

im wondering though why you mention doing this in the gcode generation step and not as a post processor?

I think the gcode generation step assumes planar printing vs the post processing step when slicing, where we can do whatever we like - plus the script is pretty straightforward to implement as an integrated post processor (like the fan speed mover, pressure equalizer and adaptive PA which all are post processors).

TengerTechnologies commented 6 days ago

"The feature should work with Marlin and Klipper" What about RRF? Something against implementing it also to work with RRF? Or just completely agnostic of the gcode flavor used?

It currently is only tested with Marlinflavour

It doesn't work with orca gcode, because orca issues z coordinate in every command on top layer #7207 and also script uses prusa stile of layer type tips (don't remember exactly but it something like ;Type top layer) so little modification to the script can fix it.

To implement it in orca slicer I would do it in the gcode generation, not as postprocessing. So the script is not usable anyways.

A postprocessing script for orca is nearly ready for release. I just have to further test it.(Probably done and commited by the end of the weekend)

I’ve been intrigued by this and am keen to start implementing this in orca.

im wondering though why you mention doing this in the gcode generation step and not as a post processor?

I think the gcode generation step assumes planar printing vs the post processing step when slicing, where we can do whatever we like - plus the script is pretty straightforward to implement as an integrated post processor (like the fan speed mover, pressure equalizer and adaptive PA which all are post processors).

I was thinking that it may be easier to work with support blockers and paint on. But I may be wrong though.

And there are still some other unsolved problems with the script. And I don't know how safe it is to use on different kind of printers f.e CoreXY

However I'm already working on a pull request and I would kind of love to implement it myself as I put so much work into the idea. Or at least work together on it. If you understand this and if you are interested in working together you could write me on reddit u/TenTech_YT

igiannakas commented 6 days ago

Awesome! Wasn’t sure if you were working on it, but since you are please do continue :)

Happy to review the code and help out with testing when it’s done :)

igiannakas commented 6 days ago

Safety wise it should be fine as the moves you’re doing are a layer tall. My suggestion would be to not decrement Z but rather mostly aim to increment it. This way you’ll be safe from any potential collisions.

TengerTechnologies commented 6 days ago

Safety wise it should be fine as the moves you’re doing are a layer tall. My suggestion would be to not decrement Z but rather mostly aim to increment it. This way you’ll be safe from any potential collisions.

Yeah I think it shouldn't be much of a problem because z-hop isn't a problem either. I just haven't seen someone running the script on a corexy and I don't know how much wear it will create on the Z axis if you move the whole builtplate.

I was thinking to remove the Z-min parameter completely and always leave it on 0, but then again I thought why not give the ability to play around with it.

Another problem will be the ironing. It kind of has to be done non-planar too, because otherwise there will be collisions.

TengerTechnologies commented 6 days ago

Awesome! Wasn’t sure if you were working on it, but since you are please do continue :)

Happy to review the code and help out with testing when it’s done :)

Thank you! I will surely reach out to you when I'm stuck or need someone to review the code :)

igiannakas commented 6 days ago

I wouldn’t enable it when ironing is set- it kind of defeats the point of fuzzy skin on top layers. You can simply disable the post processor in the code and set the parameter to toggle off when ironing is set in the config manipulation code.

take a look at my pressure equalizer Pr for example on how to toggle configs: https://github.com/SoftFever/OrcaSlicer/pull/2161