[OpenSCAD] General approach
nop head
nop.head at gmail.com
Sun Jul 7 12:15:47 EDT 2019
I avoid floating point problems by never relying on values being exact
unless they are integers and by avoiding very close vertices that might get
merged. See
https://github.com/nophead/NopSCADlib/commit/9cb0b78bb76fde29c71e499c336aae10f67c4b5b
for
an example.
On Sun, 7 Jul 2019 at 16:43, Dan Shriver <tabbydan at gmail.com> wrote:
> So, I'm not sure how I should be doing things.
>
> What I'm hearing is:
> -floating point numbers are bad (sure I get that, but I think, under
> normal circumstances my values should be far enough apart so two points
> don't end up in the same space even with rounding errors); AND rounding
> floating point numbers to some (1/2)^n is pointless
> -behind the scenes stuff snaps to a grid (not sure how I change the
> settings on this), maybe this is why the rounding is pointless since it is
> doing rounding
> -doing rotations is inherently bad
>
> So what is a better way to do what I want to do?
>
> On Sun, Jul 7, 2019 at 11:07 AM nop head <nop.head at gmail.com> wrote:
>
>> Coordinates are pairs or triples of numbers so "One of the coordinates
>> becomes irrational if you rotate by +/-30+-n*90 degrees. " doesn't make
>> sense. One of the ordinates will be rational but the other not, so the
>> coordinate can't be represented exactly by rationals.
>>
>> All integer degree angles are irrational because they are converted to
>> radians. The exceptions are just multiples of 90 because they are special
>> cases in the OpenSCAD trig functions.
>>
>> Yes rotating by atan of a rational would give a rational rotation in
>> theory, but it is done in floating point and converted from radians to
>> degrees and back again, so it would be lucky to yield integers. Your
>> example does seem to but rotating by atan(12/5) is slightly off.
>>
>> I think OpenSCAD snaps to a grid to avoid CGALs infinite precision
>> precision rationals exploding. The problem is if you limit the precision in
>> any way you risk near vertices becoming coincident and that requires the
>> mesh to be repaired before being fed back to CGAL. I had a go at removing
>> degenerate triangles but in some cases truncation and snapping can create
>> self intersections and that is harder to fix.
>>
>>
>>
>> On Sun, 7 Jul 2019 at 15:12, Rogier Wolff <R.E.Wolff at bitwizard.nl> wrote:
>>
>>> On Sun, Jul 07, 2019 at 02:44:03PM +0100, nop head wrote:
>>> > That said representing geometry with rational numbers is doomed
>>> because as
>>> > son as you rotate something all the coordinates become irrational.
>>>
>>> Technically ALMOST correct.
>>> None of the coordinates become irrational if you rotate by 90 degrees.
>>> One of the coordinates becomes irration if you rotate by +/-30+-n*90
>>> degrees.
>>> In all other cases
>>> > All of the coordinates become irrational
>>>
>>> Just kidding. (but true, or have I missed a case?)
>>>
>>> Yup! I've missed a case! Lots of them: If you rotate (0,13) by atan
>>> (5/12) you get a rational result (integer even). In this case the
>>> rotation angle is irrational.
>>>
>>>
>>> I personally don't like the "invisible" snap-to-grid. Would it be an
>>> idea to make it more explicit: All coordinates are integer multiples
>>> of the grid, but the user-units are settable to a multiple of the
>>> grid. The default being something like a million.
>>>
>>> So when I specify [1,0], internally that's represented as [1000000,0]
>>> and when I rotate that by 45 degrees that becomes [707107,707107]
>>> exactly. Predictable, verifyable, etc.
>>>
>>> You can compare this with the "scale" variable in "bc".
>>>
>>> "bc" Does arbitrary precision integer math. But when you set scale=100,
>>> the "user interface" remains the same (77*13 is still 1001), but
>>> internally numbers are multiplied by 10^100 before being used and
>>> divided by
>>> 10^100 before being printed (and after being multiplied). This results in
>>> a 100 digit approximation to pi if you type
>>> scale=100
>>> 4*a(1)
>>>
>>> Roger.
>>>
>>> --
>>> ** R.E.Wolff at BitWizard.nl ** https://www.BitWizard.nl/ **
>>> +31-15-2049110 **
>>> ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233
>>> **
>>> The plan was simple, like my brother-in-law Phil. But unlike
>>> Phil, this plan just might work.
>>>
>>> _______________________________________________
>>> 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/20190707/3d275db5/attachment.html>
More information about the Discuss
mailing list