AM
Adrian Mariano
Wed, Sep 6, 2023 11:23 PM
Maybe sorting and matching based on distance to the original polygon
sometimes (often? usually?) works, but this is going to be a slow
quadratic time algorithm in userspace, so you lose most of the advantage of
fast native offset. In particular, for the offset sweep that launched this
conversation, it's crucial to know how to align points in the offset curves
to make the polyhedron.
On Wed, Sep 6, 2023 at 4:37 AM Sanjeev Prabhakar sprabhakar2006@gmail.com
wrote:
Sorting and matching offset points based on the distance from the original
polygon points is a fairly good way and in most of the cases it works.
On Wed, 6 Sept, 2023, 3:19 am Adrian Mariano, avm4@cornell.edu wrote:
One issue I see is that many of the uses of an offset() require that you
associate points on the offset curve with points on the initial curve. It
seems like this information isn't likely to be available, so there will be
quick native offset and then some slow, not-entirely-robust algorithm to do
association. (Note: my vertex association algorithm is O(N^3), so it's
pretty darn slow.)
On Tue, Sep 5, 2023 at 5:43 PM Revar Desmera revarbat@gmail.com wrote:
As I recall, it was overcomplicating what is supposed to be a simple
language. Of course, I’m currently hoping to get this functionality via
the far more complicated object/module literals PR.
-Revar
On Sep 5, 2023, at 7:59 AM, Jordan Brown <
On 9/5/2023 3:35 AM, nop head wrote:
Would be great if OpenSCAD exposed the Clipper offset module as a
function. It seems very fast and robust. I think it has been requested
before and all the 2D geometry modules are fast enough to be functions and
I can't see any downsides. Even if somebody has a function with the same
name it would just override the built in.
PR#4478 will, among other things, let you render a 2D object into a
list of lists of points, which achieves that goal.
Maybe sorting and matching based on distance to the original polygon
sometimes (often? usually?) works, but this is going to be a slow
quadratic time algorithm in userspace, so you lose most of the advantage of
fast native offset. In particular, for the offset sweep that launched this
conversation, it's crucial to know how to align points in the offset curves
to make the polyhedron.
On Wed, Sep 6, 2023 at 4:37 AM Sanjeev Prabhakar <sprabhakar2006@gmail.com>
wrote:
> Sorting and matching offset points based on the distance from the original
> polygon points is a fairly good way and in most of the cases it works.
>
> On Wed, 6 Sept, 2023, 3:19 am Adrian Mariano, <avm4@cornell.edu> wrote:
>
>> One issue I see is that many of the uses of an offset() require that you
>> associate points on the offset curve with points on the initial curve. It
>> seems like this information isn't likely to be available, so there will be
>> quick native offset and then some slow, not-entirely-robust algorithm to do
>> association. (Note: my vertex association algorithm is O(N^3), so it's
>> pretty darn slow.)
>>
>> On Tue, Sep 5, 2023 at 5:43 PM Revar Desmera <revarbat@gmail.com> wrote:
>>
>>> As I recall, it was overcomplicating what is supposed to be a simple
>>> language. Of course, I’m currently hoping to get this functionality via
>>> the far more complicated object/module literals PR.
>>>
>>> -Revar
>>>
>>>
>>> > On Sep 5, 2023, at 7:59 AM, Jordan Brown <
>>> openscad@jordan.maileater.net> wrote:
>>> >
>>> >
>>> >> On 9/5/2023 3:35 AM, nop head wrote:
>>> >> Would be great if OpenSCAD exposed the Clipper offset module as a
>>> function. It seems very fast and robust. I think it has been requested
>>> before and all the 2D geometry modules are fast enough to be functions and
>>> I can't see any downsides. Even if somebody has a function with the same
>>> name it would just override the built in.
>>> > PR#4478 will, among other things, let you render a 2D object into a
>>> list of lists of points, which achieves that goal.
>>> >
>>> > _______________________________________________
>>> > OpenSCAD mailing list
>>> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
NH
nop head
Thu, Sep 7, 2023 7:40 AM
How is there any correspondence when the offset it positive and each point
in the original polygon becomes an arc?
On Thu, 7 Sept 2023 at 00:23, Adrian Mariano avm4@cornell.edu wrote:
Maybe sorting and matching based on distance to the original polygon
sometimes (often? usually?) works, but this is going to be a slow
quadratic time algorithm in userspace, so you lose most of the advantage of
fast native offset. In particular, for the offset sweep that launched this
conversation, it's crucial to know how to align points in the offset curves
to make the polyhedron.
On Wed, Sep 6, 2023 at 4:37 AM Sanjeev Prabhakar sprabhakar2006@gmail.com
wrote:
Sorting and matching offset points based on the distance from the
original polygon points is a fairly good way and in most of the cases it
works.
On Wed, 6 Sept, 2023, 3:19 am Adrian Mariano, avm4@cornell.edu wrote:
One issue I see is that many of the uses of an offset() require that you
associate points on the offset curve with points on the initial curve. It
seems like this information isn't likely to be available, so there will be
quick native offset and then some slow, not-entirely-robust algorithm to do
association. (Note: my vertex association algorithm is O(N^3), so it's
pretty darn slow.)
On Tue, Sep 5, 2023 at 5:43 PM Revar Desmera revarbat@gmail.com wrote:
As I recall, it was overcomplicating what is supposed to be a simple
language. Of course, I’m currently hoping to get this functionality via
the far more complicated object/module literals PR.
-Revar
On Sep 5, 2023, at 7:59 AM, Jordan Brown <
On 9/5/2023 3:35 AM, nop head wrote:
Would be great if OpenSCAD exposed the Clipper offset module as a
function. It seems very fast and robust. I think it has been requested
before and all the 2D geometry modules are fast enough to be functions and
I can't see any downsides. Even if somebody has a function with the same
name it would just override the built in.
PR#4478 will, among other things, let you render a 2D object into a
list of lists of points, which achieves that goal.
How is there any correspondence when the offset it positive and each point
in the original polygon becomes an arc?
On Thu, 7 Sept 2023 at 00:23, Adrian Mariano <avm4@cornell.edu> wrote:
> Maybe sorting and matching based on distance to the original polygon
> sometimes (often? usually?) works, but this is going to be a slow
> quadratic time algorithm in userspace, so you lose most of the advantage of
> fast native offset. In particular, for the offset sweep that launched this
> conversation, it's crucial to know how to align points in the offset curves
> to make the polyhedron.
>
> On Wed, Sep 6, 2023 at 4:37 AM Sanjeev Prabhakar <sprabhakar2006@gmail.com>
> wrote:
>
>> Sorting and matching offset points based on the distance from the
>> original polygon points is a fairly good way and in most of the cases it
>> works.
>>
>> On Wed, 6 Sept, 2023, 3:19 am Adrian Mariano, <avm4@cornell.edu> wrote:
>>
>>> One issue I see is that many of the uses of an offset() require that you
>>> associate points on the offset curve with points on the initial curve. It
>>> seems like this information isn't likely to be available, so there will be
>>> quick native offset and then some slow, not-entirely-robust algorithm to do
>>> association. (Note: my vertex association algorithm is O(N^3), so it's
>>> pretty darn slow.)
>>>
>>> On Tue, Sep 5, 2023 at 5:43 PM Revar Desmera <revarbat@gmail.com> wrote:
>>>
>>>> As I recall, it was overcomplicating what is supposed to be a simple
>>>> language. Of course, I’m currently hoping to get this functionality via
>>>> the far more complicated object/module literals PR.
>>>>
>>>> -Revar
>>>>
>>>>
>>>> > On Sep 5, 2023, at 7:59 AM, Jordan Brown <
>>>> openscad@jordan.maileater.net> wrote:
>>>> >
>>>> >
>>>> >> On 9/5/2023 3:35 AM, nop head wrote:
>>>> >> Would be great if OpenSCAD exposed the Clipper offset module as a
>>>> function. It seems very fast and robust. I think it has been requested
>>>> before and all the 2D geometry modules are fast enough to be functions and
>>>> I can't see any downsides. Even if somebody has a function with the same
>>>> name it would just override the built in.
>>>> > PR#4478 will, among other things, let you render a 2D object into a
>>>> list of lists of points, which achieves that goal.
>>>> >
>>>> > _______________________________________________
>>>> > OpenSCAD mailing list
>>>> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
AM
Adrian Mariano
Thu, Sep 7, 2023 10:32 AM
The correspondence is not one to one. Points can be added when you add
arcs. Then you have one point on the parent curve with multiple matching
points on the child. If you're making a polyhedron you'll create
triangular faces. The other case that can happen when offsetting "inward"
is that points vanish. In that case multiple points in the parent curve
correspond to a single point on the child curve, and you again make
triangular faces, but the opposite way. My offset() code can produce the
face list for connecting the parent and child curves where both deletion
and insertion of points may occur.
On Thu, Sep 7, 2023 at 3:43 AM nop head nop.head@gmail.com wrote:
How is there any correspondence when the offset it positive and each point
in the original polygon becomes an arc?
On Thu, 7 Sept 2023 at 00:23, Adrian Mariano avm4@cornell.edu wrote:
Maybe sorting and matching based on distance to the original polygon
sometimes (often? usually?) works, but this is going to be a slow
quadratic time algorithm in userspace, so you lose most of the advantage of
fast native offset. In particular, for the offset sweep that launched this
conversation, it's crucial to know how to align points in the offset curves
to make the polyhedron.
On Wed, Sep 6, 2023 at 4:37 AM Sanjeev Prabhakar <
sprabhakar2006@gmail.com> wrote:
Sorting and matching offset points based on the distance from the
original polygon points is a fairly good way and in most of the cases it
works.
On Wed, 6 Sept, 2023, 3:19 am Adrian Mariano, avm4@cornell.edu wrote:
One issue I see is that many of the uses of an offset() require that
you associate points on the offset curve with points on the initial curve.
It seems like this information isn't likely to be available, so there will
be quick native offset and then some slow, not-entirely-robust algorithm to
do association. (Note: my vertex association algorithm is O(N^3), so it's
pretty darn slow.)
On Tue, Sep 5, 2023 at 5:43 PM Revar Desmera revarbat@gmail.com
wrote:
As I recall, it was overcomplicating what is supposed to be a simple
language. Of course, I’m currently hoping to get this functionality via
the far more complicated object/module literals PR.
-Revar
On Sep 5, 2023, at 7:59 AM, Jordan Brown <
On 9/5/2023 3:35 AM, nop head wrote:
Would be great if OpenSCAD exposed the Clipper offset module as a
function. It seems very fast and robust. I think it has been requested
before and all the 2D geometry modules are fast enough to be functions and
I can't see any downsides. Even if somebody has a function with the same
name it would just override the built in.
PR#4478 will, among other things, let you render a 2D object into a
list of lists of points, which achieves that goal.
The correspondence is not one to one. Points can be added when you add
arcs. Then you have one point on the parent curve with multiple matching
points on the child. If you're making a polyhedron you'll create
triangular faces. The other case that can happen when offsetting "inward"
is that points vanish. In that case multiple points in the parent curve
correspond to a single point on the child curve, and you again make
triangular faces, but the opposite way. My offset() code can produce the
face list for connecting the parent and child curves where both deletion
and insertion of points may occur.
On Thu, Sep 7, 2023 at 3:43 AM nop head <nop.head@gmail.com> wrote:
> How is there any correspondence when the offset it positive and each point
> in the original polygon becomes an arc?
>
> On Thu, 7 Sept 2023 at 00:23, Adrian Mariano <avm4@cornell.edu> wrote:
>
>> Maybe sorting and matching based on distance to the original polygon
>> sometimes (often? usually?) works, but this is going to be a slow
>> quadratic time algorithm in userspace, so you lose most of the advantage of
>> fast native offset. In particular, for the offset sweep that launched this
>> conversation, it's crucial to know how to align points in the offset curves
>> to make the polyhedron.
>>
>> On Wed, Sep 6, 2023 at 4:37 AM Sanjeev Prabhakar <
>> sprabhakar2006@gmail.com> wrote:
>>
>>> Sorting and matching offset points based on the distance from the
>>> original polygon points is a fairly good way and in most of the cases it
>>> works.
>>>
>>> On Wed, 6 Sept, 2023, 3:19 am Adrian Mariano, <avm4@cornell.edu> wrote:
>>>
>>>> One issue I see is that many of the uses of an offset() require that
>>>> you associate points on the offset curve with points on the initial curve.
>>>> It seems like this information isn't likely to be available, so there will
>>>> be quick native offset and then some slow, not-entirely-robust algorithm to
>>>> do association. (Note: my vertex association algorithm is O(N^3), so it's
>>>> pretty darn slow.)
>>>>
>>>> On Tue, Sep 5, 2023 at 5:43 PM Revar Desmera <revarbat@gmail.com>
>>>> wrote:
>>>>
>>>>> As I recall, it was overcomplicating what is supposed to be a simple
>>>>> language. Of course, I’m currently hoping to get this functionality via
>>>>> the far more complicated object/module literals PR.
>>>>>
>>>>> -Revar
>>>>>
>>>>>
>>>>> > On Sep 5, 2023, at 7:59 AM, Jordan Brown <
>>>>> openscad@jordan.maileater.net> wrote:
>>>>> >
>>>>> >
>>>>> >> On 9/5/2023 3:35 AM, nop head wrote:
>>>>> >> Would be great if OpenSCAD exposed the Clipper offset module as a
>>>>> function. It seems very fast and robust. I think it has been requested
>>>>> before and all the 2D geometry modules are fast enough to be functions and
>>>>> I can't see any downsides. Even if somebody has a function with the same
>>>>> name it would just override the built in.
>>>>> > PR#4478 will, among other things, let you render a 2D object into a
>>>>> list of lists of points, which achieves that goal.
>>>>> >
>>>>> > _______________________________________________
>>>>> > OpenSCAD mailing list
>>>>> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>> _______________________________________________
>>>>> OpenSCAD mailing list
>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
SP
Sanjeev Prabhakar
Thu, Sep 7, 2023 4:10 PM
There is a class in python library scipy.spatial -> cKDTree which is quite
optimised for finding nearest points.
I don't know what "class" means but I just know how to use it.
for matching 2 lists of 1 million points each, it takes around 4 sec
which i feel is quite fast
On Thu, 7 Sept 2023 at 16:02, Adrian Mariano avm4@cornell.edu wrote:
The correspondence is not one to one. Points can be added when you add
arcs. Then you have one point on the parent curve with multiple matching
points on the child. If you're making a polyhedron you'll create
triangular faces. The other case that can happen when offsetting "inward"
is that points vanish. In that case multiple points in the parent curve
correspond to a single point on the child curve, and you again make
triangular faces, but the opposite way. My offset() code can produce the
face list for connecting the parent and child curves where both deletion
and insertion of points may occur.
On Thu, Sep 7, 2023 at 3:43 AM nop head nop.head@gmail.com wrote:
How is there any correspondence when the offset it positive and each
point in the original polygon becomes an arc?
On Thu, 7 Sept 2023 at 00:23, Adrian Mariano avm4@cornell.edu wrote:
Maybe sorting and matching based on distance to the original polygon
sometimes (often? usually?) works, but this is going to be a slow
quadratic time algorithm in userspace, so you lose most of the advantage of
fast native offset. In particular, for the offset sweep that launched this
conversation, it's crucial to know how to align points in the offset curves
to make the polyhedron.
On Wed, Sep 6, 2023 at 4:37 AM Sanjeev Prabhakar <
sprabhakar2006@gmail.com> wrote:
Sorting and matching offset points based on the distance from the
original polygon points is a fairly good way and in most of the cases it
works.
On Wed, 6 Sept, 2023, 3:19 am Adrian Mariano, avm4@cornell.edu wrote:
One issue I see is that many of the uses of an offset() require that
you associate points on the offset curve with points on the initial curve.
It seems like this information isn't likely to be available, so there will
be quick native offset and then some slow, not-entirely-robust algorithm to
do association. (Note: my vertex association algorithm is O(N^3), so it's
pretty darn slow.)
On Tue, Sep 5, 2023 at 5:43 PM Revar Desmera revarbat@gmail.com
wrote:
As I recall, it was overcomplicating what is supposed to be a simple
language. Of course, I’m currently hoping to get this functionality via
the far more complicated object/module literals PR.
-Revar
On Sep 5, 2023, at 7:59 AM, Jordan Brown <
On 9/5/2023 3:35 AM, nop head wrote:
Would be great if OpenSCAD exposed the Clipper offset module as a
function. It seems very fast and robust. I think it has been requested
before and all the 2D geometry modules are fast enough to be functions and
I can't see any downsides. Even if somebody has a function with the same
name it would just override the built in.
PR#4478 will, among other things, let you render a 2D object into a
list of lists of points, which achieves that goal.
There is a class in python library scipy.spatial -> cKDTree which is quite
optimised for finding nearest points.
I don't know what "class" means but I just know how to use it.
for matching 2 lists of 1 million points each, it takes around 4 sec
which i feel is quite fast
On Thu, 7 Sept 2023 at 16:02, Adrian Mariano <avm4@cornell.edu> wrote:
> The correspondence is not one to one. Points can be added when you add
> arcs. Then you have one point on the parent curve with multiple matching
> points on the child. If you're making a polyhedron you'll create
> triangular faces. The other case that can happen when offsetting "inward"
> is that points vanish. In that case multiple points in the parent curve
> correspond to a single point on the child curve, and you again make
> triangular faces, but the opposite way. My offset() code can produce the
> face list for connecting the parent and child curves where both deletion
> and insertion of points may occur.
>
> On Thu, Sep 7, 2023 at 3:43 AM nop head <nop.head@gmail.com> wrote:
>
>> How is there any correspondence when the offset it positive and each
>> point in the original polygon becomes an arc?
>>
>> On Thu, 7 Sept 2023 at 00:23, Adrian Mariano <avm4@cornell.edu> wrote:
>>
>>> Maybe sorting and matching based on distance to the original polygon
>>> sometimes (often? usually?) works, but this is going to be a slow
>>> quadratic time algorithm in userspace, so you lose most of the advantage of
>>> fast native offset. In particular, for the offset sweep that launched this
>>> conversation, it's crucial to know how to align points in the offset curves
>>> to make the polyhedron.
>>>
>>> On Wed, Sep 6, 2023 at 4:37 AM Sanjeev Prabhakar <
>>> sprabhakar2006@gmail.com> wrote:
>>>
>>>> Sorting and matching offset points based on the distance from the
>>>> original polygon points is a fairly good way and in most of the cases it
>>>> works.
>>>>
>>>> On Wed, 6 Sept, 2023, 3:19 am Adrian Mariano, <avm4@cornell.edu> wrote:
>>>>
>>>>> One issue I see is that many of the uses of an offset() require that
>>>>> you associate points on the offset curve with points on the initial curve.
>>>>> It seems like this information isn't likely to be available, so there will
>>>>> be quick native offset and then some slow, not-entirely-robust algorithm to
>>>>> do association. (Note: my vertex association algorithm is O(N^3), so it's
>>>>> pretty darn slow.)
>>>>>
>>>>> On Tue, Sep 5, 2023 at 5:43 PM Revar Desmera <revarbat@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> As I recall, it was overcomplicating what is supposed to be a simple
>>>>>> language. Of course, I’m currently hoping to get this functionality via
>>>>>> the far more complicated object/module literals PR.
>>>>>>
>>>>>> -Revar
>>>>>>
>>>>>>
>>>>>> > On Sep 5, 2023, at 7:59 AM, Jordan Brown <
>>>>>> openscad@jordan.maileater.net> wrote:
>>>>>> >
>>>>>> >
>>>>>> >> On 9/5/2023 3:35 AM, nop head wrote:
>>>>>> >> Would be great if OpenSCAD exposed the Clipper offset module as a
>>>>>> function. It seems very fast and robust. I think it has been requested
>>>>>> before and all the 2D geometry modules are fast enough to be functions and
>>>>>> I can't see any downsides. Even if somebody has a function with the same
>>>>>> name it would just override the built in.
>>>>>> > PR#4478 will, among other things, let you render a 2D object into a
>>>>>> list of lists of points, which achieves that goal.
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > OpenSCAD mailing list
>>>>>> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>> _______________________________________________
>>>>>> OpenSCAD mailing list
>>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>>
>>>>> _______________________________________________
>>>>> OpenSCAD mailing list
>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
