# [OpenSCAD] Evaluating imported STL's

doug moen doug at moens.org
Fri Jun 17 18:43:28 EDT 2016

```Lucas said:
Interesting concept that of degenerate solids, very interesting
implications:
Say goodbye to differentiating 2D from 3D shapes. All objects could be
represented as a set of vertices, and faces. An object with:
- No vertexes is a void().
- One vertex, no faces is a point().
- Two vertexes in a face is a line().
- Several coplanar vertexes and faces is a single 2d face().
- Several watertight faces is a solid().
Best of all is that this would allow us to mix them up in any configuration.

"However, I assume this would be a massive amount of work..."

I'm not sure this would make practical sense, even if you are implementing
a new geometry engine from scratch. Although this idea would work in the
realm of pure mathematics, I don't think it would survive contact with
floating point numbers and STL files. In addition, it might create a lot of
unexpected behaviour.

Our current geometry system considers 2D objects and 3D objects to be
different types, and I think that is necessary for practical reasons. One
issue is that we use different libraries for 2D and 3D objects: CGAL for 3D
CSG operations, Clipper for 2D. Another issue is that this plan implies
that a 2D object could be created as the output of an operation on 3D
objects, and then operations with 2D arguments like rotate_extrude would be
expected to recognize these objects as 2D and accept them as legal input.
In that case, floating point imprecision could be the deciding factor in
whether an object is considered 2D or 3D. It's cleaner and more robust to
distinguish 2D and 3D objects using different types.

The second issue is this: in what situations do operations on 3D objects
produce degenerate results which are then treated as valid input to other
operations?

Suppose you do this:
intersection() {
cube([10,10,10]);
translate([10,10,10]) cube([10,10,10]);
}
Mathematically, these two cubes intersect at exactly one geometric point,
[10,10,10]. Should the intersection operation produce a degenerate 3D
object, which can be used as valid input to minkowski() and other
operators? Currently, the CSG operations discard these kinds of degenerate
results (eg, intersecting at a point, line or plane). Do we really want to
change this behaviour?

If we really wanted to support degenerate objects (eg, because they allow
minkowski() to work in an intuitively correct way in Parkinbot's example),
then I think that degenerate objects would need to have a distinct type,
and objects of this type should only be generated under well defined
circumstances. For example, we could define cube(0), sphere(0) and scale(0)
X to return geometric point objects, and we could explicitly define what
happens when geometric points are passed as arguments to various geometric
operations. For sure, CGAL won't tolerate degenerate input, so we need to
do something different than just feed degenerate input to CGAL like we do
now.

I'm not sure it's worthwhile to formalize geometric points like this. I
think that a higher priority is to make OpenSCAD stop crashing when
degenerate objects are constructed. The simplest fix might be to
discard degenerate objects, or map them onto void whenever they are
constructed. This would break certain uses of minkowski(), but would also
make OpenSCAD have more predictable and robust behaviour. The question then
becomes, how important are these minkowski edge cases?

On 16 June 2016 at 21:33, Lucas Vinicius Hartmann <lucas.hartmann at gmail.com>
wrote:

> Interesting concept that of degenerate solids, very interesting
> implications:
>
> Say goobye to differentiating 2D from 3D shapes. All objects could be
> represented as a set of vertices, and faces. An object with:
> - No vertexes is a void().
> - One vertex, no faces is a point().
> - Two vertexes in a face is a line().
> - Several coplanar vertexes and faces is a single 2d face().
> - Several watertight faces is a solid().
>
> Best of all is that this would allow us to mix them up in any
> configuration.
>
> - scale([0,0,0]) degenerates any non-void thing to a point at (0,0,0).
> Void stays void.
> - scale([1,1,0]) would do pretty much the same as project(), by killing
> off the Z coordinate, but could be used to project to ZX and ZY planes too.
> - scale([0,0,1]) could be used to get a line along the Z axis exactly the
> same height as out solids.
> - minkowski() { point(); thing(); } would act exactly as translate thing.
> - minkowski() { line(); face(); } would act like linear_extrude, except
> the line could be any angle. If the line is coplanar to the original face,
> then the result ends up being another face().
> - minkowski() { line(); solid(); } would extrude a solid! Pretty much like
> a hull(), but would work for concave shapes too.
> - minkowski() { face1(); face2(); } might end up building a larger face(),
> or a solid if faces are not coplanar.
> - hull() would work on non-coplanar faces() and result in a solid().
>
> However, I assume this would be a massive amount of work, and should not
> be expected anytime soon...
>
> --
> Lucas Vinicius Hartmann
>
> Dizem que se você rodar o CD do Windows ao contrário ele mostra uma
> mensagem demoníaca... Mas isso nem é o pior, se você rodar ele normal ele
> instala o Windows!
>
> 2016-06-16 13:16 GMT-03:00 Ronaldo <rcmpersiano at gmail.com>:
>
>> Rudolf,
>>
>> You raised good points but I will keep mine about Minkowski. The example
>> you
>> have shown of a vanishing cube is idiosyncratic but for other reasons. I
>> would expect that
>>
>>            scale(0) sphere;
>>
>> to be a point, the origin, and not a void set.
>>
>> In Mathematics, you have a non-void set by doing a Minkowski sum of a
>> point
>> and a non-void set. I thought we have no way in OpenSCAD to do a Minkowski
>> sum of a set with only a point or a line segment or a 2D shape due to the
>> simple fact that we can't express such sets or mix 2D shapes with 3D
>> shapes
>> in OpenSCAD operations. However, we can at least in Minkowski operations.
>>
>> > minkowski() {
>> >      cube(1);
>> >      intersection() {
>> >         cube(1);
>> >         translate([\$t-1,\$t-1,\$t-1]) cube(1);
>> >      }
>> > }
>>
>> And that is not idiosyncratic. It does exactly what I would expect. The
>> intersection is not void, it is a square that shrinks to the origin when
>> \$t=0. The scaled sphere should do the same.
>>
>> BTW, the above "technique" may be very usefull for rounding only some
>> edges
>> of a solid.
>>
>> There is much more complexities behind the scene... :)
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17717.html
>> Sent from the OpenSCAD mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss at lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20160617/871191ef/attachment-0002.html>
```

More information about the Discuss mailing list