Add point and line segment primitives

[sorki]

While trying to fix some issues with degenerate objects like cube with zero size, it occurred to me that the result of these shouldn't be an emptySpace we currently have but a 2D or 1D primitive.

That would allow us to have 1D in core which some backends could render properly (i.e. SVG, PNG, GCode can represent points and line segments) while STL could just ignore these (possibly with a warning).

Some examples

• circle 0 (or sphere 0) would collapse into a point
• square (V2 0 10) would collapse into lineSegment
• cube (V3 0 10 10) should already collapse into square, this one we can do without additional prims.

Ideally things would play nicely together when going between dimensions using extrude and slice

• slicing a cube we get a square, slicing square we get line segment, slicing line segment we get a point, extruding reverses the operation.

4D (.. or ND?) subsystem also seems to make sense :upside_down_face:

[sorki]

https://en.wikipedia.org/wiki/Hypercube#Construction

[sorki]

Further remarks:

• point is 0D primitive, we have V0 from linear for it
• transition between dimensions could be achieved using associated types for Object type class, for 2D (V2), we would need something like LowerDim = V1 and HigherDim = V3
• this is fine from V1 up to V3, V4 (and higher) would require V5, which means switching to Linear.V and type naturals. This seems natural lol for higher dimensions as Object (SymbolicObj n) (V n) a would use LowerDim = V (n-1), HigherDim = V (n+1). We should still keep using V2/3 concrete ones for 2D/3D to not complicate front end for end-users.
• we need to switch (generalize) extrude and slice to SharedObj working with LowerDim/HigherDim associated types.

Currently, extrude is a SymbolicObj3 constructor - Extrude SymbolicObj2 ℝ which results in SymbolicObj3, respectively, slice proposed in #448 is part of SymbolicObj2 turning 3D object into 2D. This currently is the only way to "transition" between dimensions, so we cannot represent things like degenerate cube turning into square.

Studying the types, it seems like SharedObj should be our top-level object (compared to our current SymbolicObj(2|3) that can embed SharedObj) so we can for example start with a 3D object but get 2D on the output (or both). This is already a case for OpenSCAD path, that returns both 2D and 3D objects present in SCAD input file - instead of treating these separately, they would simply get contained in a single union.

Another case to consider are current output functions, which already take abstract obj as input, but doesn't allow mixing dimensions as obj is unified with DiscreteApproxable obj to either DiscreteAproxable SymbolicObj2 format or DiscreteAproxable SymbolicObj3 format. Proposed alternative, would defer the handling of objects with varying dimensions to the export function, that could decide what to do with things it cannot handle (i.e. STL would discard points, extrude 2D to 3D (or ignore 2D), ignore higher dims).

[sorki]

Better names for LowerDim and HigherDim seems to be SubSpace and SuperSpace. We could also consider notion of ambient space which currently seems to be fixed to 3 dimensional euclidean space.

[sorki]

Related https://github.com/openscad/openscad/wiki/OEP7%3A-Mixed-Dimension-Geometry-Support