Add support for Elegoo SLA open-source .goo format. #12251
Conversation
|
I look forward to this getting merged! |
Create header and source files for GOO format and add them to the build system. Register GOOWriter and GOOReader classes in SLAArchiveFormatRegistry.
Add exposure, timing, lift and retract specific options to SLAMaterialConfig and the material tab. These parameters are needed for generating .goo output files and were not yet present in the slicer. The lift and retract options are prefixed with 'sla_' to avoid conflict with e.g. 'retract_speed' from FFF printing.
Adds GOORLERasterEncoder for encoding the 'Data size', 'Image data' and 'Delimiter' parts of the 'Layer content' segment in goo files.
Add implementations for the required SLAArchiveWriter virtual functions. This adds full support for generating goo files including thumbnails and inclusion of slicer, printer and profile names in the output file. Note that GOOReader is not yet implemented. Usage of GOOReader will result in an error message in the console.
MSVC compiler was ignoring [[gnu::packed]]. This commit adds macros to add the compiler specific attributes.
MSVC was complaining about designated struct initializers in c++17. This commit replaces designated initializers with member-wise initialization. This change should probably be reversed once PrusaSlicer moves on to c++20. The use of capturing structured bindings was also removed in 'libslic3r/SLA/RasterBase.cpp'.
Generation of multi-option lines for lift and retract parameters was moved into a lambda to reduce code duplication and make future optionalizing of the parameters easier.
Felix-Rm
force-pushed
the
goo-format-support-dev
branch
from
b94935c
to
e49030e
Compare
|
Note: I rebased the branch of this PR to a newer version of |
This allows for SLA printers without tilt mechanisms to be added. Time estimation code will also be able to switch between estimations based on tilt and estimations based on lift and retract by checking for the presence of tilt configuration.
This commit adds time estimate calculation based on lift and retract. Calculation with these parameters gets triggered if tilt parameters are set to null (N/A) in the SLA printer tab. It also adds a `Time estimate correction` field in the `Corrections` section of the SLA printer tab to account for processing delays of the selected printer.
|
I have now also added print time estimation for non tilt printers. Because of a lack of discussion in this PR, I now decided to make the There also is a new |
|
I don't know if this is the preferred place for feedback, but I've built this branch and when I run it for my Elegoo Mars 4 9K, I get an "Inconsistent slicing and projection resolution" error with the resulting .GOO file when I try to print it. For the printer settings, I started with the Prusa SL1 settings, then I copied most of the Mars 4 9K settings over from Voxeldance. |
|
I have configured a CI workflow to build PrusaSlicer with the changes of this PR on a branch in my PrusaSlicer fork. People wanting to test the new features on their Elegoo Mars 4 printers can use these builds or compile for themselves. |
I have also had issues with the display resolution. In my case the actual resolution was different from the one listed in the manual of the printer. Your numbers do at least look 'specific' enough to be correct. Maybe try to set the mode to expert in the top right corner and then try to adjust the |
Tried "Landscape" instead of "Portrait" but no difference. |
|
Interesting data point: when trying to open the newly-created GOO file with UVtools, I get this error: |
Is the 'Inconsistent slicing and projection resolution' error on the printer or inside PrusaSlicer? If it's from the printer I could have a look through a .goo file from Voxeldance (if you provide one) and see what printer parameters are actually encoded. (I tested your settings and didn't get an error inside PrusaSlicer, so I suspect it is on the printer.) The part with the checksum is a problem I am aware of. The .goo spec just peaks of an 8 bit checksum, but not how it is computed. I guessed at just plain xor, which was apparently wrong. I am happy to take troubleshooting to an email thread to not further clutter up this PR. If you are ok to do so, you can reach me at felix.rm.153@gmail.com . Edit regarding the checksum issue: |
|
After some emails with @Felix-Rm, I have reached success with the Mars 4 9K and PrusaSlicer! Turns out I was incorrect in assuming what Voxeldance calls "platform size" is what PrusaSlicer calls "bed shape". It's not. I should have put those numbers in for "Display size". The correct values for the Elegoo Mars 4 9K are:
|
|
To avoid further confusion in regards to printer configs I have created a gist with configuration files for the tested printers. Please comment on proposed changes and new printer configurations in this gist from now on. When creating a new configuration for an as of yet unsupported printer you may find the configs in the UVTools repo helpful. Please copy only the parameters related to print area and display size and use the values from one of the configs in the gist for everything else. This ensures that settings regarding the exported archive are correct. |
The algorithm used for checksum generation is not explicitly specified in the .goo format spec and was implemented wrong until now. The printer ignores the checksum so this wasn't a problem. This implementation is now equivalent to the one used in UVTools.
|
Successfully tested on ELEGOO Mars 4 DLP with the following setup: General settings: Bed shape: @cjbrunner I also got the "Inconsistent slicing and projection resolution" message first (on the printer when starting the job). Setting the orientation to landscape fixed it for me. |
Thank you for testing. This means that all Elegoo Mars 4 printers (except Mars 4 ULTRA 9k, which seems to be a clone of the normal 9K with better levelling and exposure mechanism) have been tested. I have added profiles for the Mars 4 DLP and Mars 4 ULTRA 9k to the gist, this makes the profile set complete. Some fine tuning regarding the As this PR will not include integration of these profiles into PrusaSlicer (I think there should be another PR for that) I will mark it ready for review. The implementation of loading .goo archives back into PrusaSlicer is still missing. If it has to be implemented to get this PR merged I will of course do so. As I see it now this would mean some significant extra effort. I hope the people at Prusa will review this PR and also discuss the few points I mentioned in my first comment. I of course understand that merging will have to wait until all discussions are settled and the currently ongoing release cycle has completed. |
|
Regardless how long it will take until this is included in a major release: thank you very much! In the meantime I will stick to your builds.
|
This pull request adds support for generating .goo files for Elegoo Mars 4 series printers to PrusaSlicer.
Currently, in order to use Elegoo Mars 4 printers with PrusaSlicer, users have to export their models (potentially with generated supports) and convert them to the .goo format with third-party software (e.g. ChituBox or UVTools). Issue / feature-request #11882 also describes the process and is fully implemented in this pull request.
By allowing PrusaSlicer to directly generate the required file, the workflow is significantly simplified and improved. Newly released (Elegoo) printers may also support the .goo format, therefore increasing the compatibility of PrusaSlicer with those printers.
What this pull request implements (as of yet):
New configuration options in the (SLA) material settings tab for setting lift and retract specific parameters.
These settings are needed for Mars 4 printers (and other SLA printers without tilt) and were not yet present in PrusaSlicer
Directly generating .goo files from PrusaSlicer.
This can be enabled by setting the
Format of the output SLA archivein the (SLA) printer settings tab toGOO. Note that the file extension in the print settings might need to be adjusted if it was statically set. Small and large thumbnails are embedded in the generated file to simplify file selection on the printer.What this pull request doesn't add (as of yet):
Importing a .goo file (via the
Import SLA Archiveoption) is not yet supported.Print time estimation.The printing time that is beeing displayed and written to the output file is not accurate as the calculation is done using the
Tiltsettings for Prusa SLA machines.Things that still need considering:
The added settings are probably mutually exclusive with the
Tiltsettings already in PrusaSlicer. A way of describing this to the user or displaying only the applicable option groups still needs to be added. Once this is done the print time estimation for printers with lift and retract can also be implemented.The new settings reside in the (SLA) material settings tab because they are mostly dependent on material properties like color and viscosity. The already present
Tiltoptions are in the (SLA) printer settings tab and follow a category approach to set a per material profile (fast,slowandhigh viscosity). Maybe a more uniform solution regarding location and approach of the settings might be better.The names of the added settings follow the introduced conventions of other slicers. But, especially the
retract_distanceandretract_speedsettings may be confusing or counter-intuitive for users with a FFF printing or machining background. The potential benefits of introducing a new name likereturn_distanceandreturn_speedshould be discussed.Some notes on testing:
The generated .goo files were only tested on my Elegoo Mars 4 MAX 6k because I don't have access to other models of the series. Although I expect everything to also work on other printers of the family, further testing might be in order. PrusaSlicer currently doesn't provide profiles for Elegoo SLA printers. Adding selfmade profiles for testing is quite simple as most settings can be directly copied from other slicing software. I am also happy to provide my profiles for the Elegoo 4 MAX and Elegoo water washable resin on request. (When creating your own profiles please note that the screen pixel count was rounded on the website and the manual for the Mars 4 MAX (5700x3600 instead of 5760x3600) and might also be for other models. The printer will show an error if the pixel count specified in the slicer does not match the actual display.)
Configuration files for tested printers:
I have created a gist with configuration files for the tested printers.