Open ole00 opened 2 years ago
I have a Photon Mono 4k. The specs are
Screenshot of settings from Anycubic's slicer
The test pwma file available on their site https://drive.google.com/file/d/1HX9YYRI6KGxk4ySAX1ZUHL4SQaXS-9EZ/view
Zipped version in case they take it down TEST(1).zip
Thanks for the files and the information - it will be handy.
I have added support for both printers. The source code changes are in the following branch: sla_anyphoton_export
I have also made a Ubuntu 18.04 release if you do not want to build the whole slicer application from scratch. Check the github Releases section (https://github.com/ole00/PrusaSlicer/releases).
I could not verify the exported files myself as I do not have the printers, so test the files with caution.
Once that is OK, try to print the model with resin. Measure the sizes of the 3d printed object whether it matches the digital model.
Let me know your results.
I've been trying to build this for a bit, but haven't been able to(on Ubuntu 22.04 and Fedora 36. Mainly with the error that split is not a member of boost
.
The release build also doesn't work on newer systems. I'll probably set up a VM to test this,but maybe you can package that release in an appimage for people to test.
Could you add this line:
#include <boost/algorithm/string.hpp>
above this line: #include <boost/algorithm/string/replace.hpp> in /root/PrusaSlicer/src/libslic3r/Format/pwmx.cpp and rebuild? Thanks.
Could you add this line:
#include <boost/algorithm/string.hpp>
above this line: #include <boost/algorithm/string/replace.hpp> in /root/PrusaSlicer/src/libslic3r/Format/pwmx.cpp and rebuild? Thanks.
Yes, that fixes build process.
But I have a question about SPEED parameters in material settings. Those are in mm/s as opposed to mm/min which is used by chitu and lichee, right?
I think it should be mentioned somewhere.
Yes, that fixes build process.
Thanks for the confirmation.
Those are in mm/s as opposed to mm/min which is used by chitu and lichee, right
That's correct, they are in mm/s.
I think it should be mentioned somewhere.
Good point, I'll add them to the material notes as a comment.
Let me know whether you were able to export and print.
I've tried building this on Fedora 36, CentOS, Ubuntu 22.04, and Ubuntu 20.04 until now. The build fails with this for some reason
[ 96%] Building CXX object src/slic3r/CMakeFiles/libslic3r_gui.dir/Utils/TCPConsole.cpp.o
In file included from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/smart_ptr/detail/sp_thread_sleep.hpp:22,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/smart_ptr/detail/yield_k.hpp:23,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/smart_ptr/detail/spinlock_gcc_atomic.hpp:14,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/smart_ptr/detail/spinlock.hpp:42,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/smart_ptr/detail/spinlock_pool.hpp:25,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/smart_ptr/shared_ptr.hpp:29,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/shared_ptr.hpp:17,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/date_time/time_clock.hpp:17,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/date_time/posix_time/posix_time_types.hpp:10,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/asio/time_traits.hpp:23,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/asio/detail/timer_queue_ptime.hpp:22,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/asio/detail/deadline_timer_service.hpp:31,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/asio/basic_waitable_timer.hpp:22,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/asio/steady_timer.hpp:22,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/asio/basic_socket_streambuf.hpp:36,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/asio/basic_socket_iostream.hpp:24,
from /home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/asio/ip/tcp.hpp:20,
from /home/k/PrusaSlicer/src/slic3r/Utils/TCPConsole.cpp:3:
/home/k/PrusaSlicer/deps/build/destdir/usr/local/include/boost/bind.hpp:36:1: note: #pragma message: The practice of declaring the Bind placeholders (_1, _2, ...) in the global namespace is deprecated. Please use <boost/bind/bind.hpp> + using namespace boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.
36 | BOOST_PRAGMA_MESSAGE(
| ^~~~~~~~~~~~~~~~~~~~
[ 96%] Building CXX object src/slic3r/CMakeFiles/libslic3r_gui.dir/Utils/MKS.cpp.o
[ 96%] Building CXX object src/slic3r/CMakeFiles/libslic3r_gui.dir/Utils/WinRegistry.cpp.o
[ 96%] Linking CXX static library liblibslic3r_gui.a
[ 96%] Built target libslic3r_gui
make: *** [Makefile:141: all] Error 2
Adding #define BOOST_BIND_GLOBAL_PLACEHOLDERS
to src/slic3r/Utils/TCPConsole.cpp
shows other errors about qhull not being found.
I'm building using the steps here https://github.com/prusa3d/PrusaSlicer/blob/master/doc/How%20to%20build%20-%20Linux%20et%20al.md
@ole00 Can you share what kind of build environment/OS do you have, so I can use the exact same to try and build this?
EDIT: I tried building with Ninja instead, and that gave me this
[124/184] Building CXX object src/slic3r/CMakeFiles/libslic3r_gui.dir/Utils/TCPConsole.cpp.o
In file included from ../deps/build/destdir/usr/local/include/boost/smart_ptr/detail/sp_thread_sleep.hpp:22,
from ../deps/build/destdir/usr/local/include/boost/smart_ptr/detail/yield_k.hpp:23,
from ../deps/build/destdir/usr/local/include/boost/smart_ptr/detail/spinlock_gcc_atomic.hpp:14,
from ../deps/build/destdir/usr/local/include/boost/smart_ptr/detail/spinlock.hpp:42,
from ../deps/build/destdir/usr/local/include/boost/smart_ptr/detail/spinlock_pool.hpp:25,
from ../deps/build/destdir/usr/local/include/boost/smart_ptr/shared_ptr.hpp:29,
from ../deps/build/destdir/usr/local/include/boost/shared_ptr.hpp:17,
from ../deps/build/destdir/usr/local/include/boost/date_time/time_clock.hpp:17,
from ../deps/build/destdir/usr/local/include/boost/date_time/posix_time/posix_time_types.hpp:10,
from ../deps/build/destdir/usr/local/include/boost/asio/time_traits.hpp:23,
from ../deps/build/destdir/usr/local/include/boost/asio/detail/timer_queue_ptime.hpp:22,
from ../deps/build/destdir/usr/local/include/boost/asio/detail/deadline_timer_service.hpp:31,
from ../deps/build/destdir/usr/local/include/boost/asio/basic_waitable_timer.hpp:22,
from ../deps/build/destdir/usr/local/include/boost/asio/steady_timer.hpp:22,
from ../deps/build/destdir/usr/local/include/boost/asio/basic_socket_streambuf.hpp:36,
from ../deps/build/destdir/usr/local/include/boost/asio/basic_socket_iostream.hpp:24,
from ../deps/build/destdir/usr/local/include/boost/asio/ip/tcp.hpp:20,
from ../src/slic3r/Utils/TCPConsole.cpp:3:
../deps/build/destdir/usr/local/include/boost/bind.hpp:36:1: note: #pragma message: The practice of declaring the Bind placeholders (_1, _2, ...) in the global namespace is deprecated. Please use <boost/bind/bind.hpp> + using namespace boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.
36 | BOOST_PRAGMA_MESSAGE(
| ^~~~~~~~~~~~~~~~~~~~
[126/184] Linking CXX executable tests/libnest2d/libnest2d_tests
FAILED: tests/libnest2d/libnest2d_tests
: && /usr/bin/c++ -fext-numeric-literals -Wall -Wno-reorder -O3 -DNDEBUG tests/libnest2d/CMakeFiles/libnest2d_tests.dir/libnest2d_tests_main.cpp.o tests/libnest2d/CMakeFiles/libnest2d_tests.dir/printer_parts.cpp.o -o tests/libnest2d/libnest2d_tests ../deps/build/destdir/usr/local/lib/libtbb.a src/libnest2d/liblibnest2d.a src/libslic3r/liblibslic3r.a src/libnest2d/liblibnest2d.a src/libslic3r/liblibslic3r.a ../deps/build/destdir/usr/local/lib/libnlopt.a src/admesh/libadmesh.a src/miniz/libminiz_static.a ../deps/build/destdir/usr/local/lib/libboost_log.a ../deps/build/destdir/usr/local/lib/libboost_filesystem.a ../deps/build/destdir/usr/local/lib/libboost_thread.a -lrt ../deps/build/destdir/usr/local/lib/libboost_locale.a ../deps/build/destdir/usr/local/lib/libboost_regex.a ../deps/build/destdir/usr/local/lib/libboost_chrono.a ../deps/build/destdir/usr/local/lib/libboost_atomic.a ../deps/build/destdir/usr/local/lib/libboost_date_time.a src/clipper/libclipper.a src/boost/libnowide.a ../deps/build/destdir/usr/local/lib/libexpat.a src/glu-libtess/libglu-libtess.a -lm -lqhullcpp -lqhullstatic_r src/semver/libsemver.a src/libslic3r/liblibslic3r_cgal.a ../deps/build/destdir/usr/local/lib/libgmpxx.a ../deps/build/destdir/usr/local/lib/libmpfr.a ../deps/build/destdir/usr/local/lib/libgmp.a ../deps/build/destdir/usr/local/lib/libpng.a ../deps/build/destdir/usr/local/lib/libjpeg.a src/qoi/libqoi.a ../deps/build/destdir/usr/local/lib/libopenvdb.a ../deps/build/destdir/usr/local/lib/libtbb.a -ldl ../deps/build/destdir/usr/local/lib/libboost_system.a ../deps/build/destdir/usr/local/lib/libboost_iostreams.a -lz ../deps/build/destdir/usr/local/lib/libHalf-2_5.a ../deps/build/destdir/usr/local/lib/libblosc.a -pthread /usr/lib/x86_64-linux-gnu/libz.so && :
/usr/bin/ld: cannot find -lqhullcpp
/usr/bin/ld: cannot find -lqhullstatic_r
collect2: error: ld returned 1 exit status
[129/184] Building CXX object src/slic3r/CMakeFiles/libslic3r_gui.dir/Utils/UndoRedo.cpp.o
ninja: build stopped: subcommand failed.
It seems the solution is suggested in the pragma message:
...or define BOOST_BIND_GLOBAL_PLACEHOLDERS ...
The simplest thing how to achieve that is to open the "src/slic3r/Utils/TCPConsole.cpp" file and add:
#define BOOST_BIND_GLOBAL_PLACEHOLDERS
at the very top of the file (before the #include <boost/....>
Other solutions are suggested here: https://stackoverflow.com/questions/53203970/why-boostbind-insists-pulling-boostplaceholders-into-global-namespace
My build environment is Ubuntu 18.04, but is is not a trivial build either, because Ubuntu 18.04 is relatively old and PrusaSlicer requires more recent versions of many libraries which I had to build from sources. I use cmake build like this: 1) clone the repo 2) cd PrusaSlicer 3) mkdir build && cd build 4) cmake .. If all required iibraries are found then cmake generator finishes OK and produces a makefile 5) make -j8 The above runs the makefile and produces PrusaSlicer executable in the src directory. I think you got nearly to the very end of the compilation by using cmake (96%) so the fix I described above might help you to finish the build.
I have tried that, but that leads to lqhullcpp not being found, unfortunately.
I'm going to try and do a non-static build later today, even though I don't want to pollute my /usr with randomly placed untracked files. I've only tried the static option that Prusa directly supports. I wish the Appimage build was documented, so I could set up a CI or something to build this automatically.
@properlypurple you can build binary inside docker or systemd container and copy output
I don't want to pollute my /usr with randomly placed untracked files
Simple: do not build as a superuser and as long as /usr permissions do not let ordinary users/processes to write to its subdirectories (normally it is like that) it will not happen. Looking at your previous build log you posted it seems you did exactly that - build was run from inside /root directory - that indicates you were root. Also, there is no need to run "make install". You can run the newly built PrusaSlicer from the build directory without installation. I do that as well.
but that leads to lqhullcpp not being found, unfortunately.
can you send the error listing ? That might be a linking phase, not compilation, in such case you'd need another fix. You can possibly try to undo my commit related to qhull cmake: c11b224
Simple: do not build as a superuser and as long as /usr permissions do not let ordinary users/processes to write to its subdirectories (normally it is like that) it will not happen. Looking at your previous build log you posted it seems you did exactly that - build was run from inside /root directory - that indicates you were root. Also, there is no need to run "make install". You can run the newly built PrusaSlicer from the build directory without installation. I do that as well.
I'm actually trying to build with statically linked dependencies, so I can keep it all in one place. That particular build log was from a VM, where I didn't care about this.
You can possibly try to undo my commit related to qhull cmake: c11b224
Thank you for this. Reverting this commit fixes the issue, and I was able to build successfully.
The pwma files generated by the slicer open properly in Photon workshop, and I can see that the layers are okay. I'll try the files on the actual printer today, after that bottle of IPA is delivered.
@ole00 you do this in your pwm writer:
h.antialiasing = 1;
Can you please add override so it is possible to disable or enable AA from slicer settings?
I could do that, but I have no idea of side effects. If I turn this off - can the sliced images have antialised pixels or not? If turned off does the printer expect completely different image format? If the exporter would have to convert antialiased layer picture to non-aliased image, how it should trim the aliasing ? Also, what would be the benefit of turning it off? So far it seems to me if turned off the resolution of the layer image (and the print-out) drops 16x.
To compare difference from slicer perspective I think best bet is to compare output from other slicers like chitubox or photon workshop with AA turned on and off.
From practical standpoint disabled AA is important for running calibration prints so you know that you get results without any post processing.
AA is important for running calibration prints
can you point to some information what are the calibration prints and how the antialiased images affect (positively / negatively) the calibration? Can you not use the calibration files specifically designed for your printer and supplied by the manufacturer (the R_E_R_F file)?
... get results without any post processing
I might be wrong, but there does not seem to be an option in PusaSlicer to produce non-antialiased layer images - therefore in order to convert an aliased image to non-aliased image I would introduce a some processing error which may possibly affect the calibrated print.
I might be wrong, but there does not seem to be an option in PusaSlicer to produce non-antialiased layer images
There is gamma_correction
option.
#: src/libslic3r/PrintConfig.cpp:3234
msgid ""
"This will apply a gamma correction to the rasterized 2D polygons. A gamma "
"value of zero means thresholding with the threshold in the middle. This "
"behaviour eliminates antialiasing without losing holes in polygons."
msgstr ""
So possibly I could use the "gamma_correction" value and if it is set to 0 I'd export the "h.antialiasing = 0".
OK. I think I now understand your point. You probably think that Antialaiasing export flag causes the printer's firmware to smudge (post-process) the layer images even more they might already be (depending on the gamma_correction). If that's the case (and if the printer really does that) it would make sense to control that antialising export parameter independently of gamma_correction. I thought the antialiasing export parameter merely indicates the presence of semitransparent pixels in the exported file.
I probably found explanation about how their implementation works on reddit.
Apparently they apply different exposure settings using grayscale levels in a presence of this flag. I think it is possible to test pretty easily with single layer print using gradient stairs and just modify AA flag in output file without touching anything. Chances are, without AA you'll get solid exposure and different pattern in case of enabled AA.
link: good find. They are giving the PWM exporter name a justice by doing antialiasing via PWM (pulse with modulation) :) I did not know the screen is really a binary monochrome. I thought it is at least grey-scale capable.
Stipple pattern: yes that should work, To inspect the results one would need a microscope. Preferably a USB one, not the direct optical one (eye damage via UV). Or maybe using a UV transfer/sensitive foil to expose the pattern first, then inspect the results from the foil.
It is not really needed if goal is to just see what is happening. I think it is possible to check just by using decent exposure value (so you can see difference) and put regular paper to block a big portion of UV. Regular glass blocks 80% of UV and most plastics non-transparent for UV too.
In any case it is possible to set a phone, start recording and just look away from a printer.
Well, feel free to try it. I've made the source code changes. They are in the following branch: sla_anyphoton_export2
The ANTIALIASING parameter is now in the material notes. You may need to delete/update your ~/.config/PrusaSlicer-alpha/sla_material/
So gamma_correction indeed removes grayscale data from image.
Images for non-antialiased version look exactly the same but of course header contains Antialiasing 1
.
Regarding relation between gamma and AA, I think it should be other way around. When you set ANTIALIASING=0 generated images should produce monochrome images with applied gamma_correction
, e.g. you make pixels with value less than 0.5 black and otherwise white.
For example, compare images for gamma=0.5 (top) and gamma=1.0 (bottom). Some areas become darker and some become whiter.
Those are different settings because essentially gamma_correction
is a property of slicer (despite of it being in printer settings) because it changes produced images but antialiasing is a setting of machine itself.
However, one thing that I'd add is ability to set ANTIALIASING
through printer notes with overriding them from material properties.
That way you can avoid material clutter and create 2 printer profiles instead.
It would be better to have proper configuration UI of course but what you did so far is great to get things going and I don't think that prusa guys will approve UI change for SLA without solid ground anyway.
I would expect that 90% of user will not even know what antialiasing is and if they know they will leave it on the default values (both PS gamma and Exporter's Antialiasing values). For the rest - the expert users - both options are now available and can be independently set. So I think I'll leave it as it is now. I thought about putting ANTIALIASING parameter to the Printer notes instead, but decided against it because Printer notes are more critical for the correct export on the specific printer and if the user screws-up some of the values the exporter could produce incorrect type of the PWM* format. The Material notes are a safer place, even though not an ideal place.
I agree the best solution would be a dynamic menu system where either the printer or material setting are extended (using GUI widgets) based on the printer configuration. Such system would require more programming work and - as you mentioned - might not be accepted to PS mainline code anyway.
Okay. It makes it somewhat less convenient but I don't consider that a deal breaker.
What do you think about using gamma_correction
to make binary images with ANTIALIASING=0
instead of grayscale ones though?
I have no strong opinion on antialiasing and gamma. I have only used it once, the print-out was OK, did not see any degradation in print quality when AA was OFF and gamma was 0 (but I did not do identical print with AA on, so can't directly compare). I think AA can be useful on low resolution (low DPI) screens, but may have diminishing returns on high DPI printers. My opinion on the benefit of using such feature depends on what kind of pos-processing the printer does when the AA flag is on. If it keeps the layer image intact (no image post-processing) and just treats the AA pixels with "variable light intensity" (ie PWM), then that's OK by me. OTOH if it would try to 'smudge' or blur the image (which either has or has no AA pixels) to improve soft edges then I'd personally turn it off on my export files. But the actual behaviour depends on the printer maker, printer model and possibly also on firmware version. At the end of the day it is a similar question of which color you like more : red or blue - it's subjective and both options may have some benefits in certain cases.
But the actual behaviour depends on the printer maker, printer model and possibly also on firmware version.
True, but since we do anycubics here so I think we should only consider how our printers do this since there's nothing we can do about it. Also important thing here is that prusa has their own SLA and up until your PR it was the only printer supported so it is safe to assume that most things there tailored to their way of interpreting sliced images.
I don't think that having grayscale images in layer data with AA off seems like correct thing to do. It can be solved by using some custom gamma function but considering that resin is liquid and doesn't block all of the light, it will bleed through neighbor pixels anyway to some degree so this kind of fine tuning seems meaningless on a scale of 50 micrometers.
In that case why even bother doing stuff like this? Maybe it is better to ditch new parameter whatsoever as you suggested before because essentially you can do same thing with gamma_correction=0
and set antialiasing=0
in header for the sake of correctness.
I don't know what the AA parameter currently does in the firmware - and even if I'd known, the future firmware releases might change the behaviour. Therefore this current solution (both parameters independent and settable) gives the most flexibility and control to the user (even though some combinations might not make sense on current firmware or printer model, but may make sense on other printer model or firmware version). I'll leave it as it is - the defaults are set to enable gamma and export with AA On. For regular user this should be good enough. For others: they are now free to experiment and tweak the values.
Okay, that's fine by me too. My printer is out of commission right now but I'll test some cases when I get it to work later and post it either here or in another issue maybe. We'll see how it goes.
In any case, thank you for this work.
@properlypurple, @gudvinr: just wondering whether you were able to print things exported from the modified PrusaSlicer on your printer. If so, are you happy with the exported files / results or would you suggest some modifications? If you did not have time to test it properly, that's fine.
I wasn't able to run print with resin, however printer seems to recognize files and screen showing what it is supposed to show on initial layers.
I didn't test edge cases with AA that I described earlier though.
If it is possible to build windows version, I can ask some people to test.
With release of 2.5 do you think you can manage to send PR to include in 2.6 release, @ole00?
Maybe even split in 2: AA support and new format/printers support.
I'd need to rebase the changes on top of the latest upstream commits. Hopefully if there would be no code conflicts I can submit the PR quite quickly. I was waiting on you (both of you) to give some feedback from real printing before I attempt to do a PR.
Support for Anycubic Photon SLA export formats similar to .pwmx. It looks like the format for Anycubic SLA printers is quite similar, differences seem to be mainly the resolution of the LCD and size of the printing base.