Open codehero opened 8 years ago
How is your feature of directly sending slices to the engine going? Did you get it to work?
Do you want to create a pull request, so that it will be included in the engine indefinitely?
I am able to generate gcode from my slice data, but the slice parameters (layer_0_height, layer_height, etc) are ignored. I have not been able to test on actual 3d printer yet but I am still working on it in bursts. My plan is to print in 2 colors, so I would want to test that before issuing a pull request. Does geometry data for dual printing require a nonzero distance between the volumes, or can the volumes share vertices?
Did you implement it as an extra feature, or as replacing normal STL slicing?
Of course those parameters have to be ignored.
I don't think there is any interaction between meshes in that sense. Also: Note the setting multi_extrusion_overlap! Op 11 mrt. 2016 23:59 schreef "David Bender" notifications@github.com:
I suppose down the road it could make sense to make STL slicing just a special case of a generic slice stack. For now I have the features side by side. I have been testing this code recently on a FlashForge dreamer and had a successful print in PETG.
I pulled to the latest master and have an issue on the perimeter layers of the print. The first image shows the good, the second the bad:
I am using the fdmprinter.ref.json as my settings. Any idea why the perimeter would turn into dashed lines?
I couldn't tell from this thread: did this feature get merged in, and is it currently available in Cura? I would like to print some mathematical surfaces, and it's much much much easier for me to generate slice data from them than a mesh. If this feature is available it would be super useful. Are there instructions for using it somewhere?
Nope. It's still open. Mathematicions don't have priority I guess. ':D
Note that generating the mesh doesn't need to be as difficult as you might think. You don't need to connect the layers together, you only need to give your slices a height, so that Cura will slice each layer exactly where you want.
Just generate the 2D polygons and then extrude each line segment into two perfectly vertical triangles with the same height as your intended layer height - and BAM! you got what you want.
(cleaned up discussion of unrelated stuff)
For the OCD people, can you quickly explain how making a non-water tight STL, with the possibility of internal cavities etc, would work with properly with Cura? Wouldn't support generation not work without horizontal faces?
BagelOrb, a question (related to codehero's comment): in order to do what you suggest, would I also need to triangulate the top and bottom surfaces of each slice and union them to make a manifold mesh? Or does Cura only look at the triangles that actually intersect with the slices (so it wouldn't even notice if the top and bottom were missing)?
(I know that the triangulation and union operations can be done in OpenSCAD, but although its preview is quite fast for this task, rendering an STL file is too slow to be practical.)
The first thing CuraEngine does is slice the 3D model into polygons and the rest of the processing only uses these polygons. The 3D model is only used to calculate the areas of each layer and all other operations are operations on polygons.
Your mesh doesn't need to be manifold; only each slice needs to be a closed polygon.
The slicing stage within CuraEngine is a 2 step process:
Great! I was just testing it as you were posting that message - I made an STL file containing only the sides of a cube, with no top or bottom, and it sliced it just fine, creating a top and bottom layer and infill etc. So this will be easier than I thought. Thank you for the tip!
Your model can look like this:
Perfect, that's easy to do.
Second question: how can I know the exact heights at which Cura will slice the model? For example, if I have my bottom layer set to 0.25mm and all other layers set to 0.2mm, would I need to make sure my model has layers at 0mm, 0.25mm, 0.45mm, 0.65mm etc., or in the midpoints of the layers, at 0.125mm, 0.35mm, 0.55 etc., or something else?
They are sliced in the middle, unless you have the setting Slicing Tolerance set to Exclusive or Inclusive (in which case the layers are sliced at the top and at the bottom and a union or intersection is performed on those slices).
I'm not sure whether this is still the case but it could be that all layers are sliced 0.5 * layer height below their top, meaning that the initial layer is sliced slightly above the middle - assuming the initial layer height is higher than the normal one.
I'm not sure whether this is still the case but it could be that all layers are sliced 0.5 * layer height below their top, meaning that the initial layer is sliced slightly above the middle - assuming the initial layer height is higher than the normal one.
No, the initial layer's slicing Z coordinate is set to initial_layer_height / 2
when using tolerance Middle.
@codehero where did your fork go? I'm trying to do the exact same thing.
@LipuFei I was able to achieve what I wanted by building horizontal triangle strips as they have shown.
@codehero (I think you pinged the wrong person :slightly_smiling_face: ) - did your original fork work though for slices? If not, all good. I'm working on this because it would drastically reduce the amount of faces while improving edge quality.
In my application, I am easily able to generate cross sections of my data. Converting to STL to be sliced again is inefficient and potentially lossy. I have hacked in initial support of reading the slicer data directly.
https://github.com/analog10/CuraEngine/tree/direct_slice_read