AM
Adrian Mariano
Sun, Jan 16, 2022 3:47 AM
You are getting warnings because a range like [10:4] gives a warning.
To avoid these warnings, always use 3 values when giving a range, so
[10:1:4] or [10:-1:4] as appropriate. So you can fix by editing the
code so that it says [begin:1:end] or [begin:-1:end] as
appropriate---whichever one you meant. Or maybe you really want
[min(begin,end):max(begin,end)].
For the second warning about undef you need to modify the code to
check for undef instead of doing arithmetic on undefs. That is,
instead of foo-bar, if foo might be undef then write
is_undef(foo)?undef:foo-bar. But this advice only applies if the
undef is there for a good reason. I think in your case the problem
may be that the list has length 0, the loop is therefore going over
the range [0:-1] which is the same as [-1:0] and it gets undef due to
invalid indexing.
On Sat, Jan 15, 2022 at 9:52 PM Sanjeev Prabhakar
sprabhakar2006@gmail.com wrote:
please see the attached scad file "example of heart".
Not able to figure out why so many warnings, but it renders ok.
Is there a way to suppress these warnings
On Mon, 10 Jan 2022 at 05:04, Sanjeev Prabhakar sprabhakar2006@gmail.com wrote:
Thanks a lot for your help
On Mon, 10 Jan 2022, 05:00 Adrian Mariano, avm4@cornell.edu wrote:
Your code for computing the polygon relied on something inside
dependencies.scad that conflicted with BOSL2, so I just printed out
the contents of that path to use with BOSL2. To create a domed shape
based on an input pointlist:
include<BOSL2/std.scad>
include<BOSL2/rounding.scad>
offset_sweep(pointlist, height=10, top=os_circle(r=5));
You need height to be larger than the radius given for the top, or you
can omit height entirely and you'll just get the dome. The
offset_sweep() function is pretty complicated, with lots of options.
To learn how to use it, go here:
https://github.com/revarbat/BOSL2/wiki/rounding.scad#functionmodule-offset_sweep
On Sun, Jan 9, 2022 at 6:01 PM Sanjeev Prabhakar
sprabhakar2006@gmail.com wrote:
Thanks very much for your answer
I will the bosl library and use the same for such applications.
Can you share the modified scad file
On Mon, 10 Jan 2022, 01:15 Adrian Mariano, avm4@cornell.edu wrote:
I think you will find that most offset strategies remove
points---usually people are not interested in retaining extra points.
When I talk about robustness I mean getting the right answer at all,
not getting the right answer and tracking the point mapping between
the original and offset curves.
I do not know what the content of your dependencies.scad is, but I
tried your example in BOSL2. In order to get a correct result with an
offset of -5 I had to select quality=4. I think this is because you
have excessively fine sampling, with lots of points very close
together. The BOSL2 offset function removes points, but it also has
the option to provide the map between original points and removed
points so that you can link the points together. This is how
offset_sweep works. There are two reasons I haven't pursued the
winding number scheme from the paper for a more robust offset. One of
them is that it only works on polygons, not on paths with endpoints.
The other is that it won't give the mapping I need for offset_sweep,
and I use offset_sweep in almost every model.
The result of offset sweep on your shape with a radius 5 "dome"
appears below. Note also that even if points are removed, all is not
lost. You can link points "intelligently" and perhaps get a decent
result. The BOSL2 skin() function does NOT require that the layers
linked together have the same number of points and if you use the
"distance" method you can perhaps get a good result on an example like
this, though it may be slow with many points, since the algorithm for
linking points is O(N^3).
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
You are getting warnings because a range like [10:4] gives a warning.
To avoid these warnings, always use 3 values when giving a range, so
[10:1:4] or [10:-1:4] as appropriate. So you can fix by editing the
code so that it says [begin:1:end] or [begin:-1:end] as
appropriate---whichever one you meant. Or maybe you really want
[min(begin,end):max(begin,end)].
For the second warning about undef you need to modify the code to
check for undef instead of doing arithmetic on undefs. That is,
instead of foo-bar, if foo might be undef then write
is_undef(foo)?undef:foo-bar. But this advice only applies if the
undef is there for a good reason. I think in your case the problem
may be that the list has length 0, the loop is therefore going over
the range [0:-1] which is the same as [-1:0] and it gets undef due to
invalid indexing.
On Sat, Jan 15, 2022 at 9:52 PM Sanjeev Prabhakar
<sprabhakar2006@gmail.com> wrote:
>
> please see the attached scad file "example of heart".
> Not able to figure out why so many warnings, but it renders ok.
> Is there a way to suppress these warnings
>
> On Mon, 10 Jan 2022 at 05:04, Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote:
>>
>> Thanks a lot for your help
>>
>> On Mon, 10 Jan 2022, 05:00 Adrian Mariano, <avm4@cornell.edu> wrote:
>>>
>>> Your code for computing the polygon relied on something inside
>>> dependencies.scad that conflicted with BOSL2, so I just printed out
>>> the contents of that path to use with BOSL2. To create a domed shape
>>> based on an input pointlist:
>>>
>>> include<BOSL2/std.scad>
>>> include<BOSL2/rounding.scad>
>>>
>>> offset_sweep(pointlist, height=10, top=os_circle(r=5));
>>>
>>> You need height to be larger than the radius given for the top, or you
>>> can omit height entirely and you'll just get the dome. The
>>> offset_sweep() function is pretty complicated, with lots of options.
>>> To learn how to use it, go here:
>>>
>>> https://github.com/revarbat/BOSL2/wiki/rounding.scad#functionmodule-offset_sweep
>>>
>>> On Sun, Jan 9, 2022 at 6:01 PM Sanjeev Prabhakar
>>> <sprabhakar2006@gmail.com> wrote:
>>> >
>>> > Thanks very much for your answer
>>> > I will the bosl library and use the same for such applications.
>>> > Can you share the modified scad file
>>> >
>>> > On Mon, 10 Jan 2022, 01:15 Adrian Mariano, <avm4@cornell.edu> wrote:
>>> >>
>>> >> I think you will find that most offset strategies remove
>>> >> points---usually people are not interested in retaining extra points.
>>> >> When I talk about robustness I mean getting the right answer at all,
>>> >> not getting the right answer and tracking the point mapping between
>>> >> the original and offset curves.
>>> >>
>>> >> I do not know what the content of your dependencies.scad is, but I
>>> >> tried your example in BOSL2. In order to get a correct result with an
>>> >> offset of -5 I had to select quality=4. I think this is because you
>>> >> have excessively fine sampling, with lots of points very close
>>> >> together. The BOSL2 offset function removes points, but it also has
>>> >> the option to provide the map between original points and removed
>>> >> points so that you can link the points together. This is how
>>> >> offset_sweep works. There are two reasons I haven't pursued the
>>> >> winding number scheme from the paper for a more robust offset. One of
>>> >> them is that it only works on polygons, not on paths with endpoints.
>>> >> The other is that it won't give the mapping I need for offset_sweep,
>>> >> and I use offset_sweep in almost every model.
>>> >>
>>> >> The result of offset sweep on your shape with a radius 5 "dome"
>>> >> appears below. Note also that even if points are removed, all is not
>>> >> lost. You can link points "intelligently" and perhaps get a decent
>>> >> result. The BOSL2 skin() function does NOT require that the layers
>>> >> linked together have the same number of points and if you use the
>>> >> "distance" method you can perhaps get a good result on an example like
>>> >> this, though it may be slow with many points, since the algorithm for
>>> >> linking points is O(N^3).
>>> >>
>>> >>
>>> > _______________________________________________
>>> > 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
Sun, Jan 16, 2022 5:46 AM
Thanks done
have alook
On Sun, 16 Jan 2022 at 09:18, Adrian Mariano avm4@cornell.edu wrote:
You are getting warnings because a range like [10:4] gives a warning.
To avoid these warnings, always use 3 values when giving a range, so
[10:1:4] or [10:-1:4] as appropriate. So you can fix by editing the
code so that it says [begin:1:end] or [begin:-1:end] as
appropriate---whichever one you meant. Or maybe you really want
[min(begin,end):max(begin,end)].
For the second warning about undef you need to modify the code to
check for undef instead of doing arithmetic on undefs. That is,
instead of foo-bar, if foo might be undef then write
is_undef(foo)?undef:foo-bar. But this advice only applies if the
undef is there for a good reason. I think in your case the problem
may be that the list has length 0, the loop is therefore going over
the range [0:-1] which is the same as [-1:0] and it gets undef due to
invalid indexing.
On Sat, Jan 15, 2022 at 9:52 PM Sanjeev Prabhakar
sprabhakar2006@gmail.com wrote:
please see the attached scad file "example of heart".
Not able to figure out why so many warnings, but it renders ok.
Is there a way to suppress these warnings
Thanks done
have alook
On Sun, 16 Jan 2022 at 09:18, Adrian Mariano <avm4@cornell.edu> wrote:
> You are getting warnings because a range like [10:4] gives a warning.
> To avoid these warnings, always use 3 values when giving a range, so
> [10:1:4] or [10:-1:4] as appropriate. So you can fix by editing the
> code so that it says [begin:1:end] or [begin:-1:end] as
> appropriate---whichever one you meant. Or maybe you really want
> [min(begin,end):max(begin,end)].
>
> For the second warning about undef you need to modify the code to
> check for undef instead of doing arithmetic on undefs. That is,
> instead of foo-bar, if foo might be undef then write
> is_undef(foo)?undef:foo-bar. But this advice only applies if the
> undef is there for a good reason. I think in your case the problem
> may be that the list has length 0, the loop is therefore going over
> the range [0:-1] which is the same as [-1:0] and it gets undef due to
> invalid indexing.
>
> On Sat, Jan 15, 2022 at 9:52 PM Sanjeev Prabhakar
> <sprabhakar2006@gmail.com> wrote:
> >
> > please see the attached scad file "example of heart".
> > Not able to figure out why so many warnings, but it renders ok.
> > Is there a way to suppress these warnings
> >
>
>
AM
Adrian Mariano
Sun, Jan 16, 2022 2:11 PM
It looks like you're getting closer. You have some funny looking
stuff happening in the concave corner of the heart, and (as a result?)
your model fails to render. (Add cube(5) to your model to force CGAL
to run so you can see it fail.)
On Sun, Jan 16, 2022 at 12:49 AM Sanjeev Prabhakar
sprabhakar2006@gmail.com wrote:
Thanks done
have alook
On Sun, 16 Jan 2022 at 09:18, Adrian Mariano avm4@cornell.edu wrote:
You are getting warnings because a range like [10:4] gives a warning.
To avoid these warnings, always use 3 values when giving a range, so
[10:1:4] or [10:-1:4] as appropriate. So you can fix by editing the
code so that it says [begin:1:end] or [begin:-1:end] as
appropriate---whichever one you meant. Or maybe you really want
[min(begin,end):max(begin,end)].
For the second warning about undef you need to modify the code to
check for undef instead of doing arithmetic on undefs. That is,
instead of foo-bar, if foo might be undef then write
is_undef(foo)?undef:foo-bar. But this advice only applies if the
undef is there for a good reason. I think in your case the problem
may be that the list has length 0, the loop is therefore going over
the range [0:-1] which is the same as [-1:0] and it gets undef due to
invalid indexing.
On Sat, Jan 15, 2022 at 9:52 PM Sanjeev Prabhakar
sprabhakar2006@gmail.com wrote:
please see the attached scad file "example of heart".
Not able to figure out why so many warnings, but it renders ok.
Is there a way to suppress these warnings
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
It looks like you're getting closer. You have some funny looking
stuff happening in the concave corner of the heart, and (as a result?)
your model fails to render. (Add cube(5) to your model to force CGAL
to run so you can see it fail.)
On Sun, Jan 16, 2022 at 12:49 AM Sanjeev Prabhakar
<sprabhakar2006@gmail.com> wrote:
>
> Thanks done
> have alook
>
> On Sun, 16 Jan 2022 at 09:18, Adrian Mariano <avm4@cornell.edu> wrote:
>>
>> You are getting warnings because a range like [10:4] gives a warning.
>> To avoid these warnings, always use 3 values when giving a range, so
>> [10:1:4] or [10:-1:4] as appropriate. So you can fix by editing the
>> code so that it says [begin:1:end] or [begin:-1:end] as
>> appropriate---whichever one you meant. Or maybe you really want
>> [min(begin,end):max(begin,end)].
>>
>> For the second warning about undef you need to modify the code to
>> check for undef instead of doing arithmetic on undefs. That is,
>> instead of foo-bar, if foo might be undef then write
>> is_undef(foo)?undef:foo-bar. But this advice only applies if the
>> undef is there for a good reason. I think in your case the problem
>> may be that the list has length 0, the loop is therefore going over
>> the range [0:-1] which is the same as [-1:0] and it gets undef due to
>> invalid indexing.
>>
>> On Sat, Jan 15, 2022 at 9:52 PM Sanjeev Prabhakar
>> <sprabhakar2006@gmail.com> wrote:
>> >
>> > please see the attached scad file "example of heart".
>> > Not able to figure out why so many warnings, but it renders ok.
>> > Is there a way to suppress these warnings
>> >
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
SP
Sanjeev Prabhakar
Sun, Jan 16, 2022 3:39 PM
Thanks for pointing out there was some error in the swp module, after
correction there was no issue in rendering.
On Sun, 16 Jan 2022 at 19:41, Adrian Mariano avm4@cornell.edu wrote:
It looks like you're getting closer. You have some funny looking
stuff happening in the concave corner of the heart, and (as a result?)
your model fails to render. (Add cube(5) to your model to force CGAL
to run so you can see it fail.)
On Sun, Jan 16, 2022 at 12:49 AM Sanjeev Prabhakar
sprabhakar2006@gmail.com wrote:
Thanks done
have alook
On Sun, 16 Jan 2022 at 09:18, Adrian Mariano avm4@cornell.edu wrote:
You are getting warnings because a range like [10:4] gives a warning.
To avoid these warnings, always use 3 values when giving a range, so
[10:1:4] or [10:-1:4] as appropriate. So you can fix by editing the
code so that it says [begin:1:end] or [begin:-1:end] as
appropriate---whichever one you meant. Or maybe you really want
[min(begin,end):max(begin,end)].
For the second warning about undef you need to modify the code to
check for undef instead of doing arithmetic on undefs. That is,
instead of foo-bar, if foo might be undef then write
is_undef(foo)?undef:foo-bar. But this advice only applies if the
undef is there for a good reason. I think in your case the problem
may be that the list has length 0, the loop is therefore going over
the range [0:-1] which is the same as [-1:0] and it gets undef due to
invalid indexing.
On Sat, Jan 15, 2022 at 9:52 PM Sanjeev Prabhakar
sprabhakar2006@gmail.com wrote:
please see the attached scad file "example of heart".
Not able to figure out why so many warnings, but it renders ok.
Is there a way to suppress these warnings
Thanks for pointing out there was some error in the swp module, after
correction there was no issue in rendering.
On Sun, 16 Jan 2022 at 19:41, Adrian Mariano <avm4@cornell.edu> wrote:
> It looks like you're getting closer. You have some funny looking
> stuff happening in the concave corner of the heart, and (as a result?)
> your model fails to render. (Add cube(5) to your model to force CGAL
> to run so you can see it fail.)
>
> On Sun, Jan 16, 2022 at 12:49 AM Sanjeev Prabhakar
> <sprabhakar2006@gmail.com> wrote:
> >
> > Thanks done
> > have alook
> >
> > On Sun, 16 Jan 2022 at 09:18, Adrian Mariano <avm4@cornell.edu> wrote:
> >>
> >> You are getting warnings because a range like [10:4] gives a warning.
> >> To avoid these warnings, always use 3 values when giving a range, so
> >> [10:1:4] or [10:-1:4] as appropriate. So you can fix by editing the
> >> code so that it says [begin:1:end] or [begin:-1:end] as
> >> appropriate---whichever one you meant. Or maybe you really want
> >> [min(begin,end):max(begin,end)].
> >>
> >> For the second warning about undef you need to modify the code to
> >> check for undef instead of doing arithmetic on undefs. That is,
> >> instead of foo-bar, if foo might be undef then write
> >> is_undef(foo)?undef:foo-bar. But this advice only applies if the
> >> undef is there for a good reason. I think in your case the problem
> >> may be that the list has length 0, the loop is therefore going over
> >> the range [0:-1] which is the same as [-1:0] and it gets undef due to
> >> invalid indexing.
> >>
> >> On Sat, Jan 15, 2022 at 9:52 PM Sanjeev Prabhakar
> >> <sprabhakar2006@gmail.com> wrote:
> >> >
> >> > please see the attached scad file "example of heart".
> >> > Not able to figure out why so many warnings, but it renders ok.
> >> > Is there a way to suppress these warnings
> >> >
> >>
> > _______________________________________________
> > 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
>
JB
Jordan Brown
Sun, Jan 16, 2022 4:46 PM
On 1/15/2022 6:50 PM, Sanjeev Prabhakar wrote:
Is there a way to suppress these warnings
In general - in OpenSCAD and any programming environment - you should
not suppress warnings. Instead, you should understand and fix them.
Warnings tell you that something is at least questionable, and possibly
wrong.
Unfortunately, often 90% of the warnings are harmless - the program does
what you want. However, if you don't fix that 90%, it's very hard to
see the other 10% where something is actually going wrong.
On 1/15/2022 6:50 PM, Sanjeev Prabhakar wrote:
> Is there a way to suppress these warnings
In general - in OpenSCAD and any programming environment - you should
not suppress warnings. Instead, you should understand and fix them.
Warnings tell you that something is at least questionable, and possibly
wrong.
Unfortunately, often 90% of the warnings are harmless - the program does
what you want. However, if you don't fix that 90%, it's very hard to
*see* the other 10% where something is actually going wrong.
AM
Adrian Mariano
Sun, Jan 16, 2022 9:44 PM
I always enable the "stop on first warning" option in OpenSCAD and do
not allow my code to produce any warnings.
On Sun, Jan 16, 2022 at 11:46 AM Jordan Brown
openscad@jordan.maileater.net wrote:
On 1/15/2022 6:50 PM, Sanjeev Prabhakar wrote:
Is there a way to suppress these warnings
In general - in OpenSCAD and any programming environment - you should not suppress warnings. Instead, you should understand and fix them. Warnings tell you that something is at least questionable, and possibly wrong.
Unfortunately, often 90% of the warnings are harmless - the program does what you want. However, if you don't fix that 90%, it's very hard to see the other 10% where something is actually going wrong.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I always enable the "stop on first warning" option in OpenSCAD and do
not allow my code to produce any warnings.
On Sun, Jan 16, 2022 at 11:46 AM Jordan Brown
<openscad@jordan.maileater.net> wrote:
>
> On 1/15/2022 6:50 PM, Sanjeev Prabhakar wrote:
>
> Is there a way to suppress these warnings
>
>
> In general - in OpenSCAD and any programming environment - you should not suppress warnings. Instead, you should understand and fix them. Warnings tell you that something is at least questionable, and possibly wrong.
>
> Unfortunately, often 90% of the warnings are harmless - the program does what you want. However, if you don't fix that 90%, it's very hard to *see* the other 10% where something is actually going wrong.
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
SP
Sanjeev Prabhakar
Sun, Jan 16, 2022 11:33 PM
my code is too messy and not able to figure out reason in many cases, due
to paucity of time .
but you are right. Once I have some time will fix these.
On Sun, 16 Jan 2022 at 22:16, Jordan Brown openscad@jordan.maileater.net
wrote:
On 1/15/2022 6:50 PM, Sanjeev Prabhakar wrote:
Is there a way to suppress these warnings
In general - in OpenSCAD and any programming environment - you should not
suppress warnings. Instead, you should understand and fix them. Warnings
tell you that something is at least questionable, and possibly wrong.
Unfortunately, often 90% of the warnings are harmless - the program does
what you want. However, if you don't fix that 90%, it's very hard to see
the other 10% where something is actually going wrong.
my code is too messy and not able to figure out reason in many cases, due
to paucity of time .
but you are right. Once I have some time will fix these.
On Sun, 16 Jan 2022 at 22:16, Jordan Brown <openscad@jordan.maileater.net>
wrote:
> On 1/15/2022 6:50 PM, Sanjeev Prabhakar wrote:
>
> Is there a way to suppress these warnings
>
>
> In general - in OpenSCAD and any programming environment - you should not
> suppress warnings. Instead, you should understand and fix them. Warnings
> tell you that something is at least questionable, and possibly wrong.
>
> Unfortunately, often 90% of the warnings are harmless - the program does
> what you want. However, if you don't fix that 90%, it's very hard to *see*
> the other 10% where something is actually going wrong.
>
>
