slicer integration and parameters

[petaflot]

I find myself editing the slicing parameters for basically every model (rather, part of model) that I print. This is cumbersome and a cause of stupid errors (forgetting to set this or that parameter in the slicer).

AFAIK, the best slicer now is the arachne slicer ; some UIs allow for more than one slicer, so anyhow this should not be a tough barrier to overcome.

I would really like to be able to

• set slicer options in .scad files comments
• use openscad to call the slicer while passing the desired options (and possibly send to printer, ie. with octoprint)

[pca006132]

I think this is much easier to implement in a slicer rather than openscad. If you implement this in a slicer, this is just letting the slicer read the .scad file comment for options, call openscad (via subprocess) to generate the model, and import the model into the slicer. And I still have no idea how to implement this in openscad without modifying the slicer code.

[petaflot]

a "slicer" (actually GUIs for slicers) reads an stl file, displays it, and calls the slicer (possibly offering some configuration widgets). finally, it displays an new object that is the sum all all toolpaths.

Openscad generates the object, exports it as an stl file.

I fail to see how it would be difficult get Openscad to call a command-line tool for slicing, such as the Cura engine. However, I fail to see why a particular, "random" slicer frontend would implement reading numerous arbitrary and more or less obscure filetypes from a very large variety of 3D editors.

OpenSCAD already had this feature to send the STL to a print service (commercial or a local octoprint instance) : either case, for a result pf any use the slicing parameters must be provided : specifying the slicing parameters inside the source file would only fill a gap that exists since the F8 was added. Printing with "default" (or "random") parameters makes for absolutely useless parts unless one is printing silly figures, companion cubes, you-name-it that has no actual mechanical purpose.

I understand that for this to be cross-compatible between many slicers, it would involve a joint effort for the community, and better definition of some concepts : IMHO this would only help improve the global understanding and quality of parts produced.

[petaflot]

an idea that just came to my mind is the possibilty to "link" slicer configuration files in openscad: this way this settings file could be separate, would make maintaining easier and would be less slicer-dependant (because this would impact slicer development)

any thoughts?

[gsohler]

Seems that 3MF can embed Slicer information

https://lib3mf.readthedocs.io/en/master/source/Cpp/lib3mf_SliceStackIterator.html

Remaining tasks are just

• how to use this function and what it can do
• openscad to export this information
• slicer to understand this information

[tcurtin]

A +1 for using the 3mf. I export directly to 3mf and then pull into Bambu Slicer, and for this particular project have many parts (from multiple 3mf files) I need to separate to objects but also keep aligned. Being able to indicate position, filament, etc would be an amazing improvement both in accuracy and efficiency!

[gsohler]

right now i am adding the possibility to store several "designs" together in the same 3mf file(right now 3mf v2 ).
Can you give few examples of useful slicer settings you want to attach to the part ?
(are the properties siting on the part, the file, a certain z range or very different ? )

[gsohler]

This is how it could look like

file is at http://www.guenther-sohler.net/export.3mf

[t-paul]

As discussed multiple times, this is not happening for security reasons. At this point OpenSCAD can easily run as UI thumbnailer exactly because it will not start bitcoin mining when loading some random file from the internet.

To be clear, the feature requested, does NOT need procedural save in the language.

Saving will be possible via the python integration once that gets official, and this is guarded by explicit user action.

[gsohler]

You are right .. no File write action triggered by script.
But I feel that the script should still define the set of parts to be exported.
The file-write-action itself can of course be started by GUI

[petaflot]

Parameters I would like to see, for the entire part:

• top layer count
• bottom layer count
• shells
• infill type and percentage
• top fill pattern
• bottom fill pattern
• layer height
• vase mode or not vase mode
• export file name (absolute or relative) because I very often have a file with a number of parts (modules) and at least one "display" module that shows the assembled part (often animated) and these parts must be rendered and exported separately in the correct position for printing. Commenting out sections of the code usually works well, but I guess I could use a combination of different scad files and use the include or use feature (or whatever equivalent this will by with python)

Being able to override these parameters locally for any portion of a part would be absolutely amazing (and one of the reasons I started writing superslice (not be be confused with Superslicer which didn't exist at the time I started my project)

Also, ideally

• where to generate support (I guess solids that, when they intersect with a face, mark that face as needing support)
• where NOT to generate supports (similar as above) ; could include volumes supports should avoid (if slicer supports it)
• seam position
• color hint

I don't see the use of a procedural save, in fact I see it as a nuisance that is likely to overwrite correct versions of files or write way more than required. bad. I personally have little concern over anyone mining bitcoin on my machine because anyone should read a code before executing it, or they gotta learn to. I suppose a ring of trust could be established, with people in the community signing files and making these signatures available on a repository.

[gsohler]

so you plan to use this function to retrieve object layer properties ?

LIB3MF_DECLSPEC Lib3MFResult lib3mf_meshobject_getobjectlevelproperty(Lib3MF_MeshObject pMeshObject, Lib3MF_uint32 * pUniqueResourceID, Lib3MF_uint32 * pPropertyID, bool * pHasObjectLevelProperty);

do you already have example code ?

rather than specifying top layer counts and bottom layer count , and perimeter shells i would rather have per-face shells.