[OpenSCAD] Evaluating imported STL's

nop head nop.head at gmail.com
Sat Jun 18 07:11:36 EDT 2016


I think hull() and minkowski() (which can be made using hull) are special
cases because they only need to consider the vertices, not edges or faces.
That is why they will accept degenerate shapes and make valid 3D shapes
from them. Perhaps that could be a documented feature of openscad without
having to re-write it.

On 17 June 2016 at 23:43, doug moen <doug at moens.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20160618/f03ba4d1/attachment-0002.html>


More information about the Discuss mailing list