karl-nilsson / sse Goto Github PK

Somehow, Slice is passing a loopset with two outer (ccw) loops to Shell
Happens on layer #6 of 49, layer height 0.4mm. Coincides with where the base ends and the bullseye starts.

Console logs:

[2021-12-01 11:18:21.336] [console] [debug] Logger initialized, level: 1
 Nb Total:0  for 0 items

[2021-12-01 11:18:21.381] [console] [debug] Object: Generating bounding box
[2021-12-01 11:18:21.381] [console] [info] Rearranging objects
[2021-12-01 11:18:21.381] [console] [debug] Rearrange: translating objects to new location, offset (92.500,92.500)
[2021-12-01 11:18:21.381] [console] [debug] Rearrange: moving object to (92.500,92.500)
[2021-12-01 11:18:21.381] [console] [debug] Object: Translating to (92.500,92.500,-0.000)
[2021-12-01 11:18:21.381] [console] [info] Layer Height: 0.4
[2021-12-01 11:18:21.381] [console] [info] Creating splitter tools
Loaded 'C:\Windows\System32\kernel.appcore.dll'. 
[2021-12-01 11:18:21.589] [console] [debug] number of slices: 49
[2021-12-01 11:18:21.591] [console] [debug] generating shells
[2021-12-01 11:18:21.596] [console] [debug] generating shells
[2021-12-01 11:18:21.601] [console] [debug] generating shells
[2021-12-01 11:18:21.605] [console] [debug] generating shells
[2021-12-01 11:18:21.610] [console] [debug] generating shells
[2021-12-01 11:18:21.614] [console] [debug] generating shells
[2021-12-01 11:18:21.615] [console] [error] Shell: Expected 1 outer polyline. received: 2

Currently unable to generate infill because CavC can't cut open polylines

Currently, sse generates infill patterns for every layer and slice. Given most infill patterns are periodic (wrt z position), it should be possible to cache the generated patterns, and reuse them as needed.

use wires of all objects, to prevent brims from colliding/overlapping

Until bezier offset/clipping works, flatten to arcs

https://dlacko.org/blog/2016/10/19/approximating-bezier-curves-by-biarcs/
https://observablehq.com/@awhitty/approximating-bezier-curves-for-cnc
https://pomax.github.io/bezierinfo/#arcapproximation
https://www.ryanjuckett.com/biarc-interpolation/
https://www.softwareresearch.net/fileadmin/src/docs/teaching/SS12/SaI/Presentation_Siahposhha.pdf

• identify faces/regions that exceed overhang angle
  • planar surface: calculate normal for (any) one point on surface
  • nonplanar surface: calculate distribution of normals on surface
• tower supports: vertical extrusion
• tree supports: graph traversal (octree or voxel) to bedplate
• add result as sub-item in assembly

https://github.com/karl-nilsson/sse/blob/master/libsse/CMakeLists.txt#L84

The basic idea is to apply CSS's conflict resolution rules to slicing parameters. Specifically: precedence (order), inheritance, and specificity.

• Precedence: the library will have a built-in settings profile with sane fallbacks, and a user can override with one (or many) profiles.
• Inheritance: for objects with multiple solids, settings for the parent object will apply to the children
• Specificity: class/id rules override inheritance, e.g. support structures will have the "support" class, so will override settings inherited from parent object.

This requires all entities (object, sub-object, slice) to have the equivalent of CSS's id and class fields. This allows for slicer settings based on groups of objects, slices, or types of objects (e.g. support structures will be created with a "support" class). This can fulfill the same role as layer modifiers (e.g. change print speed/temp at layer X), but I'm not sure if/how it can replace modifier meshes. (modifier meshes may be achieved by splitting the solid, have to think about this)

One difficulty with this approach is how to represent static vs generated/dynamic settings, e.g. "layer_height: 0.1" vs "layer_height: dynamic". Perhaps std::variant<double, enum> will suffice.

Can flatten into either arcs or beziers (latter is only useful if/when bezier offset/clip works)

Bezier: https://stackoverflow.com/a/20582153
BSpline: https://dev.opencascade.org/doc/occt-7.5.0/refman/html/class_convert___ellipse_to_b_spline_curve.html

https://devblogs.microsoft.com/cppblog/vcpkg-accelerate-your-team-development-environment-with-binary-caching-and-manifests/

The MacOS build has been broken for awhile, specifically the unit tests. The debug messages aren't helpful, and don't make much sense.

This is a tracking issue, to remind myself to do a deep dive eventually

Expose the progress indicator to library users (applications).
Intended for GUI apps, but maybe usable for CLI apps.

https://unlimited3d.wordpress.com/2020/10/17/progress-indication-changes-in-occt-7-5-0/
https://dev.opencascade.org/content/redesign-progress-indicator
https://dev.opencascade.org/doc/refman/html/class_message___progress_indicator.html

Hello,

I would like to test the continuous (vase) printing toolpath (for shell shapes).
I see a method called slicer::make_spiral_face, that could do this job, but it does seem to be used today.
Could you confirmt this could help, and if yes how I could plug it for testing ?

Thank you.

Meta-issue for tracking curve flattening features

• #26
• #27
• #28
• #29
• #30

https://www.youtube.com/watch?v=NMs7GtvsJ6g

Geom_Parabola
https://dev.opencascade.org/doc/occt-7.5.0/refman/html/class_convert___parabola_to_b_spline_curve.html

Small moves (specifically moves w/extrusion) should be merged in to neighbors, or removed entirely if no neighbors exist.
The parameters (filter/min length, max error/deviation) should be configurable, with a default value near the XY resolution of an average printer.

One edge case is how to handle tiny arcs. CavC only supports round/fillet joins, which result in tiny arcs at small offsets. Ideally, cavc could produce square joins for negative (internal) offsets on concave angles (i.e. shells), and round joins on positive offsets (i.e. brim/skirt)

Additionally, arcs with huge radii can be simplified into line segments.

This should be done after the following steps:

• Wire -> pline conversion (this also includes curve flattening algos)
• pline offsetting (potentially already part of cavc)
• pline clipping (potentially already part of cavc)

Currently, the occt cache workflow uses the occt version & revision for the cache key. If any dependencies change/update, the cache isn't invalidated, causing the build workflow to rebuild the updated dependency and occt.

manually checking all dependencies is a bad idea, as it would require recursively traversing the dependency tree, too complicated.

I can simply hash vcpkg/versions/baseline.json, which would invalidate the cache whenever any version changes. Perhaps a bit overkill.

n.b. Github uses the most recently created cache when multiple have the same priority.

The goal is to expose library functionality to a higher-level language, in order to enable dynamic user-specified code in the fronted.

This would change the project design to an idempotent/stateless math library. A frontend would use scripts to glue functions together.

Frontend features

• Hooks
• Triggers, e.g. layer change
• Dynamic function parameters
• Settings is a frontend script, rather than a config file loaded by the library
• Code editor UI (QScintilla)
• Node editor UI
• Exportable project files
  • Simply zip up the current list of models and the slicer script
  • This requires some level of determinism (e.g. occt hashes the same value, regardless of platform)

Unknowns:

• How much (if any) of occt will need bindings
  • Will library wrappers suffice?
• Exception handling across the language border
• Performance cost
• Interpreter size (on disk & in memory)
• Ease of embedding/distributing in/with library
• Interop with Qt frontend
  • e.g. if a user translates a model in the Qt UI, is that change propagated to the object in the script interpreter?
• Interop with other features, e.g. modifier meshes

Options:

• Lua

  • SWIG
  • Sol3

• Python

  • Swig
  • pybind11

• JavaScript

  • QJSEngine (Qt)
  • Emscripten/Embind
  • node-ffi
  • Duktape
  • JerryScript

• Chaiscript

• Wren & wrenbind17

• C++

  • Cling

• TCL

  • Already part of occt

  https://www.instructables.com/How-to-Build-Your-Own-3D-Printing-Slicer-From-Scra/

Hello,

You mentioned in your starting doc page that your tool includes non-planar slicing : I can't see it in the source code ; Is it operational (or in the future) ?
When you say Non-planar slicing, does it mean slice the input shape (solid) using offsets of a base surface ? (and fill the "curved" slices with appropriate path)

Thank you.

1. Calculate 2d convex hull of all objects on print bed
   • use object's AABB
   • use objects OBB
   • use mesh (project points onto buildplate)
2. Offset result by some amount (configurable)
3. Extrude result (in +z direction)

Error occurs at layer 3, layer height 0.4, = 1.2mm z, which coincides with the first layer past the base.

Console logs:

[2021-12-01 11:40:39.847] [console] [debug] Logger initialized, level: 1
 Nb Total:0  for 0 items

[2021-12-01 11:40:39.890] [console] [debug] Object: Generating bounding box
[2021-12-01 11:40:39.890] [console] [info] Rearranging objects
[2021-12-01 11:40:39.890] [console] [debug] Rearrange: translating objects to new location, offset (107.500,112.500)
[2021-12-01 11:40:39.890] [console] [debug] Rearrange: moving object to (107.500,112.500)
[2021-12-01 11:40:39.890] [console] [debug] Object: Translating to (107.500,112.500,-0.000)
[2021-12-01 11:40:39.890] [console] [info] Layer Height: 0.4
[2021-12-01 11:40:39.890] [console] [info] Creating splitter tools
Loaded 'C:\Windows\System32\kernel.appcore.dll'. 
[2021-12-01 11:40:40.079] [console] [debug] number of slices: 20
[2021-12-01 11:40:40.080] [console] [debug] generating shells
[2021-12-01 11:40:40.083] [console] [debug] generating shells
[2021-12-01 11:40:40.086] [console] [debug] generating shells
Debug Assertion Failed!

Program: C:\Users\Nilsson\devel\sse\build\libsse\Debug\sse.dll
File: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\vector
Line: 1612

Expression: front() called on empty vector

Model:

Identify top/bottom surfaces, and apply 100% infill for X number of layers.

Must be configurable

https://www.ryanjuckett.com/biarc-interpolation/
https://dlacko.org/blog/2016/10/19/approximating-bezier-curves-by-biarcs/
https://github.com/domoszlai/bezier2biarc
https://math.stackexchange.com/questions/1972079/algorithm-for-splitting-splines-into-arc-and-line
https://math.stackexchange.com/questions/1679920/curve-fitting-using-circles/1681399#1681399

By hashing slices, I can recognize duplicates, thereby reducing work. No need to calculate shells/infill if the inputs (wires, slicer settings) are the same.
This can be implemented with std::unordered_map<sse::Slice, std::pair<size_t, size_t>>, with the value being pointers to the start and end of gcode within the aggregate gcode string.

This also allows for more advanced gcode, specifically M97 subprogram.

Geom_Hyperbola
Low priority
https://dev.opencascade.org/doc/occt-7.5.0/refman/html/class_convert___hyperbola_to_b_spline_curve.html

• #10
• #11
• #14
• #13
• #12
• #16