Implement support for CTBv3 (Elegoo Mars 2 Pro/Phrozen Sonic Mini 4K)

[uwwint]

Hi Guys,

I am on the mission to port the uv3p implementation of the CTB v3, and my specific patches into PrusaSlicer (https://github.com/uwwint/uv3dp) with the goal to support my hardware (Phrozen Sonic Mini 4K).

My crude plan is:

1. Port the go implementation to C++, implementing the interfaces for sla::RasterBase and sla::RasterEncoder
2. Move some of the raster operations from Format/SL1.cpp into the base class SLAPrinter
3. Implement a class CTBArchive public SLAPrinter in Format/CTB.h
4. implement a switch in https://github.com/uwwint/PrusaSlicer/blob/9bb0848d27d5a5fb714b7ad116001c304f9d4830/src/PrusaSlicer.cpp#L466 to allow use of the CTBArchive based on a configuration option.
5. Somehow get a config option in to allow specifying the output format for the exported SLA file.

My question is:

1. What am I not seeing? (I am sure there is many)
2. Would such a feature make it into a release?
3. Where can I find conventions you guys use in code. Otherwise I mimc by observation :D

[bubnikv]

Would such a feature make it into a release?

It depends on the extent of the feature and on the implementation. It is really all about our effort (short term and long term) and risk. If the integration is loose, meaning the feature is separated by well defined tight interfaces, then we may integrate it independent of the quality of the code behind the interfaces. If it crashes in your code, then it is your problem, not ours.

Where can I find conventions you guys use in code. Otherwise I mimc by observation :D\

That is likely the best.

What am I not seeing? (I am sure there is many)
@tamasmeszaros knows the details.

[h-2]

I would love to see support for the Phrozen Sonic Mini (without 4k), too! Prusa-Slicer is simply the best tool out there and it's a real nuisance to always export and go through CHITUBOX.

[nefen]

Is this project going on?

If yes, is there anything I can do to help?

[bubnikv]

We may accept pull requests, but accepting pull requests and maintaining 3rd party source code takes a lot of effort from our side, so ideally the 3rd party SLA printer support code would be neatly modular, so if it breaks, it does not affect our customers.

[uwwint]

Hi guys, my personal priorities got changed a bit around since I raised this, but I might actually throw some time at this no 14th of Oct till 29th when I am between jobs.

The issue I foresee is that there is two implementations of ctbv3, one from UVTools in C# and one from uv3dp in go. So if we want to pull it off we need to interface with either of the codes or redo it in C++. Neither of those options look appealing to me at this point. But with some guidance and support I might waste my time on this issue rather than being the worlds best Xbox gamer in covid lockdown ;).

Both Uv3dp and uvtools have Command-line interfaces. So that could also work. Maybe we ask sn4k3 (uvtools owner) if he wants to help integrating. I see how I can get his attention (I personally don't know him)

[sn4k3]

The file formats/interface are not the problem here, Slic3r/PS team and devs can implement CTBv3 in about 1 day or 2.
Those file structures are soo simple to write, and who's inside PS core will be able to write it in no time.

The real problem here is the UI, this file formats have some settings that PS dont have, so they had to add those too and not to say that a file format can have fields that other don't and this will require different visible UI settings per printer / format. Worse, same field can have different meanings and values between different formats!
This is where the pain starts, there are no standart on mSLA, almost each brand/printer have it own format creating a lot of fragmentation and problems to implement them. This is time consumption but doable. Due that PS team may have no interest on this for now...

They can go like i do: Use printer notes to set those values, but that is ugly and is not what people wants.
To do it right it will require a lot of effort to build and mantain those printers and brands.

As last line: Having the option to run a command per printer after file slice/export is a thing i dont understand why dont exists already...

[mtaumike]

There is a spot for FDM printing where you can run scripts. Perhaps this needs to be extended into the SLA workflow that is already there.

Print Settings -> Output Options

[Marinosbitter]

How about the new Chitubox SDK?
That wouldn't fix the issue of the UI but maybe make the implementation of the filetype a bit easier.

[sn4k3]

How about the new Chitubox SDK? That wouldn't fix the issue of the UI but maybe make the implementation of the filetype a bit easier.

Not gona happen, that's an agreement with the devil and anti open-source.
Read more here: sn4k3/UVtools#319 (comment)

[Marinosbitter]

Damn, hadn't read that far into the terms and conditions. What a way to kill a couple of perfectly good printers (I have an Elegoo Mars 3 and tough I like the machine itself, ChituBox is a b*tch). I wonder what Elegoos or Phrozens stance on this issue is.

Anyway. Thanks for the info!

[paxsonsa]

New to the community but happy to take a stab at this in my (limited) sparetime. Looking at the codebase is seems like the triangle mesh handles writing itself out as a STL? Are there any strong opinions on approach?

[lukasmatena]

@paxsonsa As @bubnikv has already stated twice, the strong opinion on approach is that whatever is coded is as separated from the rest of the codebase as in can reasonably be. We do not have time to maintain and fix things like this, so we need to minimize the risk that possible bugs in it affect people not using CTB.

What the internal representation of triangle meshes has to do with it is beyond me, but I did not look into what exactly is needed. Some contribution guidelines are here: https://github.com/prusa3d/PrusaSlicer/wiki/Contribution-guidelines

[bubnikv]

Potential contributors may look into #7917
and what happened with the files of #7917 on master.
Adding support for other SLA export formats is not that difficult, @tamasmeszaros tried hard to provide a flexible enough interface to fill in.

[NickSica]

In late February I picked this up and made some distance with it, but stopped due to changes in the codebase. It seems that was a good idea as the pwmx I was using as reference was changed quite a bit. @Mimoja is there any insight on any big changes(mostly to implementing the AnycubicSLAArchive as that was one of the new features added). Also I added support through the GUI instead of app notes in my changes, is there a reason this isn't done for the Anycubic printers? Should I go through app notes instead?

[Mimoja]

I only did a minimal cleanup to prepare for more printers. Therefore no massive changes like GUI. I did not spend the time how to do condition gui items

[NickSica]

Ok just double checking there wasn't a big reason to avoid it, thank you!

[h-2]

Great to see this is still being worked on!

[NickSica]

Great to see this is still being worked on!

I think I may be close to something that is working, chitu's file format makes no sense in some regards so it's a real headache. I did CTBv4 instead of v3, though.

[paxsonsa]

If you have fork I can try out I am happy to help test.

[NickSica]

If you have fork I can try out I am happy to help test.

Feel free, it's pushed to my fork. I have a lot of repeat functions that were a product of the anycubic code that I'm going to get rid of and condense eventually so it isn't pretty looking at the moment. I was having trouble building it yesterday due to linking errors in something I didn't really touch. Let me know if a clean build works. A clean build worked and after fixing some issues my new issue is font errors from Emboss.cpp when the app starts up.

[NickSica]

@paxsonsa if you have time, can you try my fork out? I'm trying to fix issues unrelated to this where PrusaSlicer crashes on startup on my system when loading a font with stbtt_InitFont. Once I resolve this I was going to slice a file as an SL1 and a ctb then run the SL1 through UVTools to convert it and compare the outputs of the two files.

[NickSica]

This is pretty much done, there are just some things that might need to be discussed about how PrusaSlicer implements certain features vs other slicers. The only bug left in my fork is the layers coming out a bit odd(everything comes out stretched the x axis is elongated while the y axis is squished) which I'm finding impossible to track down. If anyone wants to take a stab at it, I invite you to. Should I open up a pull request after this bug is squashed or now so we can start looking it over? I also added in GUI support for a lot of the options which I wanna clean up a bit in future changes(Making options grey out if you don't use them and TSMC always keep the same distance going up and down). I do want to transfer the GUI support over to the Photon as well.