
12

So I'm wondering if my general approach to a problem is bad. To simplify I'm trying to make an arched structure where the arches change form. The first shape I'm trying to make is to have the archway itself form an ogee arch (you can roughly think of it as wishbone shaped thing).
So what I did was to do this:
difference() { hollowHalf() mirror([1,0,0]) { solidHalf() } mirror([1,0,0]) { hollowHalf() }
Either that approach is invalid, or there is some other problem going on.
The thing that puzzles me is I'd think it would work from a geometric point of view (I know the interior walls would be wrong but the exterior I would think should be fine)
If in OpenScad I just render the hollowHalf() and then click It looks like the last archway is centered versus the y and z axies to me (+z is coming straight at the viewer, +y is going up, +x is to the right).
That suggests to me that after they were joined they should overlap with no gap
alternately I was thinking two differences might give both a correct interior and exterior view
difference() { hollowHalf(); mirror([1,0,0]) { solidHalf(); } } difference() { mirror([1,0,0]) { hollowHalf(); } solidHalf() }
is the logic wrong?
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Administrator

DanS wrote
> So I'm wondering if my general approach to a problem is bad.
>
> difference() {
> hollowHalf()
> mirror([1,0,0]) {
> solidHalf()
> }
> mirror([1,0,0]) {
> hollowHalf()
> }
What is hollowHalf & solidHalf?
As a general rule your should try to check what each component looks like
before doing bigger pictures, so use the '!' modifier* in the above, first
on 'hollowHalf()', then on 'mirror()[1,0,0]) solidHalf()' the on
'mirror([1,0,0]) hollowHalf()'. Then remove '!' and use '#' on
'mirror()[1,0,0]) solidHalf()'.
* see https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Modifier_CharactersI can't see how mirror() can work here? Mirror will put the object in an
opposite plane which will not overlap so there is nothing to difference().
Try:
// ball  sphere in the positive quadrant
module ball(s=10, c="black") color(c) translate([s,s,s]) sphere(s, $fn=s*3);
ball(10,"blue");
mirror([1,0,0]) ball(10,"red");
Isn't the solid=false, 'wishbone' already hollow?
I'm not seeing what type of structure you want.
> My end goal is to make six passageways that interconnect with arches2().
Is that 6 passages each of which is an arches2()? [perhaps with different
inputs?]
How are they arranged?
Perhaps there is a picture on google resembling what you want?

Admin  email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin  email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!


DanS wrote
> So I'm wondering if my general approach to a problem is bad.
> To simplify I'm trying to make an arched structure where the arches change
> form.
So the best approach is to form a sequence of (morphing) polygons that
neither self intersect nor mutually intersect, skin this sequence and test
it by unioning a cube. This is what you seem to do, but only half way down.
As long as you do not skin a cross section with holes, it is straight
forward to generate polygons describing the full crossection. To exploit
symmetries, better reuse/modify a precalculated point sequence respectively
by means of list comprehension in order to compose full shaped polygons. I
think in your case this is feasible and preferable.
While the use of Boolean ops after skinning is allowed  despite being quite
slow, you must take care to
1) produce proper manifolds as operands  which you don't seem to check
properly (see other thread).
2) avoid operands using the same (or very close) points or partial identity.
OpenSCAD can have representation problems with very close vertices.
Another hint: Try to break down complexity. Do proper testing of each
component  especially when you use polyhedron (which is called during
skin), because OpenSCADs F5 and F6 don't give semantically equivalent
output. F5 displays anything even nonvalid manifolds. F12 can indicate
orientation problems, but not each and everything.

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 20190707 13:52, Parkinbot wrote:
> OpenSCAD can have representation problems with very close vertices.
OpenSCAD/CGAL is said to use 'fractional numbers', supposedly without
data loss, at the price of slow execution and high memory use. However,
the statement "OpenSCAD can have representation problems with very close
vertices" is a characteristic for a system representing vertex
coordinates using ordinary floating point numbers (single or double
precision). If what you say is true, it may seem users are paying a
price (slow execution and high memory use) for something (lossless
computations) that isn't available?
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Yes that is true because the user side of OpenSCAD uses floating point and even snaps to a grid, so all the precision of CGAL is lost. CGAL can make manifold geometry and then OpenSCAD breaks it by snapping to a grid and gives it back the CGAL, which then barfs.
That said representing geometry with rational numbers is doomed because as son as you rotate something all the coordinates become irrational. On 20190707 13:52, Parkinbot wrote:
> OpenSCAD can have representation problems with very close vertices.
OpenSCAD/CGAL is said to use 'fractional numbers', supposedly without
data loss, at the price of slow execution and high memory use. However,
the statement "OpenSCAD can have representation problems with very close
vertices" is a characteristic for a system representing vertex
coordinates using ordinary floating point numbers (single or double
precision). If what you say is true, it may seem users are paying a
price (slow execution and high memory use) for something (lossless
computations) that isn't available?
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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" snaptogrid. Would it be an
idea to make it more explicit: All coordinates are integer multiples
of the grid, but the userunits 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.

** [hidden email] ** https://www.BitWizard.nl/ ** +31152049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brotherinlaw Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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, 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" snaptogrid. Would it be an
idea to make it more explicit: All coordinates are integer multiples
of the grid, but the userunits 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.

** [hidden email] ** https://www.BitWizard.nl/ ** +31152049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brotherinlaw Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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? 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, 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" snaptogrid. Would it be an
idea to make it more explicit: All coordinates are integer multiples
of the grid, but the userunits 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.

** [hidden email] ** https://www.BitWizard.nl/ ** +31152049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brotherinlaw Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On Sun, Jul 07, 2019 at 04:05:30PM +0100, nop head 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.
Elaborating on my jokecornercase of rotating by 30 degrees, the
point [2,0] becomes [sqrt(3), 1] Add an extra zero to do this if you
want this to happen in 3D. I maintain that one of the twoorthree
coordinates becomes irrational. Yes that makes the whole POINT
unrepresentable by rationals.
All this is irrelevant: Many rotations, including those by 30 degrees
will yield points notpreciselyrepresentable 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.
Right. Good.
> 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.
rotating [0,13] by atan (12/5) should yield the point
[12,5]. Something with Pythagoras. For rationals on the Xaxis, you
still get a rational destination point. But for any nonXaxis point
you still go offrationalgrid. I think. Where does 12,1 end up?
Rotate that vector back to the X axis and the point on the Xaxis is
irrational (0, sqrt (145)), so when you rotate that by the atan (12/5)
you get something like [5/13*sqrt(145), 12/13*sqrt(145)] which remains
irrational.
Still, all this is of no practical use: Most cases people will design
things with irrational coordinates, so we have to do something about:
> 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.
When my suggestion of a userconfigurable scaledintegergrid is
implemented, the user has a crude way of controlling things. And it
offers extra functionality. If you know ALL your coordinates are a
multiple of 1 micron, you can set the scale of 1mm to 1000. If you are
designing a model of the death star, then setting it to 1 may be more
appropriate. The current "hidden" grid is not appropriate if you are
say designing say a model of a few atoms. Like when IBM used their new
SFM to move a few atoms into spelling IBM in a 5atom high font.
It may not be too long from now when someone in a lab somewhere uses
openscad to design a 3D structure that might be manipulated into
existence with such tools. With the current hidden grid, that's going
to lead to surprises. Make it uservisible and when things go wrong,
that guy didn't read the manual. Case closed. Design software for
the future.
I suspect that the ATA and SD card spec guys consider their strategy
"job security". Each time we really hit the limits of the previous
standard they tack on a bunch of bits with a "well within my lifetime"
expiration date. Moore's law is pretty predictable. 5 extra address
bits expire in 10 years.
Setting the default scale to 1 million would mean the grid is 1 nm:
about ten atoms. A slight nudge is needed to design atomscale objects
and that's acceptable.
This "there is a grid deep down below somewhere..." leads to
unpredictable behaviour. And that's not good.
Roger.
>
>
> On Sun, 7 Jul 2019 at 15:12, Rogier Wolff < [hidden email]> 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" snaptogrid. Would it be an
> > idea to make it more explicit: All coordinates are integer multiples
> > of the grid, but the userunits 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.
> >
> > 
> > ** [hidden email] ** https://www.BitWizard.nl/ ** +31152049110
> > **
> > ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
> > The plan was simple, like my brotherinlaw Phil. But unlike
> > Phil, this plan just might work.
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > [hidden email]
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org> >
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
** [hidden email] ** https://www.BitWizard.nl/ ** +31152049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brotherinlaw Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


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?
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, 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" snaptogrid. Would it be an
idea to make it more explicit: All coordinates are integer multiples
of the grid, but the userunits 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.

** [hidden email] ** https://www.BitWizard.nl/ ** +31152049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brotherinlaw Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 20190707 18:15, nop head wrote:
> 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.
Which is the same as assuming floating point coordinates everywhere. It
seems the use of 'rational numbers' in CGAL adds no real benefits in
precision, but instead adds cost in the form of lost performance and
increased memory consumption. Add the unpredictable grid stuff in
OpenSCAD and it is questionable if anything is gained compared to
computing with floating point numbers everywhere.
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


All this discussion leads far away from the origin of the thread. It may
explain, why in very rare cases extrusions fail, when vertices are to close
(even not identical) or a Boolean operation leads to a CGAL error. But I
dare to say that in 99.99% of all problems people have when sweeping,
skinning, or constructing polyhedra, there are computational or logical bugs
involved and not snaptogrid effects.
I only mentioned this category of possible errors, because they can indeed
occur if e.g. mirrored, translated or rotated versions of skinned objects
are unioned, or symmetries are constructed by use of Boolean operations in a
more general sense, since the thread originator asked to get some opinion on
this technique.
cacb wrote
> Which is the same as assuming floating point coordinates everywhere. It
> seems the use of 'rational numbers' in CGAL adds no real benefits in
> precision, but instead adds cost in the form of lost performance and
> increased memory consumption. Add the unpredictable grid stuff in
> OpenSCAD and it is questionable if anything is gained compared to
> computing with floating point numbers everywhere.
Carsten, as CGAL is a piece of software on its own, and there seems no
floating point number alternative in sight, one would have to change/adopt
the number representation and arithmetics (!) in OpenSCAD in order to avoid
all this problems and gain a sort of seemless representation. Obviously this
will hold only up the point, where STL imports are involved, or floating
point numbers come into play for similar reasons. This theme has been
discussed extensively a while ago, without concrete results  no way to do
away with it.

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Actually, now I can see a better way to do what I wanted. I'm trying to join two arched pathways one is in one octant and the other is in the next octant, they intersect.
Before I was subtracting a mirror of a solid version of one from the other. Now I simply subtract a cube (actually a rectangular box) that is wholly in the next octant. I take the resulting shape and mirror it.
OpenSCAD gives me a warning that it might not be valid 2manifold (which is probably due to some error in the arched pathway before a cube was even subtracted from it) but things LOOK close to what I want (unlike before). So this is progress.
Thanks for the help people. All this discussion leads far away from the origin of the thread. It may
explain, why in very rare cases extrusions fail, when vertices are to close
(even not identical) or a Boolean operation leads to a CGAL error. But I
dare to say that in 99.99% of all problems people have when sweeping,
skinning, or constructing polyhedra, there are computational or logical bugs
involved and not snaptogrid effects.
I only mentioned this category of possible errors, because they can indeed
occur if e.g. mirrored, translated or rotated versions of skinned objects
are unioned, or symmetries are constructed by use of Boolean operations in a
more general sense, since the thread originator asked to get some opinion on
this technique.
cacb wrote
> Which is the same as assuming floating point coordinates everywhere. It
> seems the use of 'rational numbers' in CGAL adds no real benefits in
> precision, but instead adds cost in the form of lost performance and
> increased memory consumption. Add the unpredictable grid stuff in
> OpenSCAD and it is questionable if anything is gained compared to
> computing with floating point numbers everywhere.
Carsten, as CGAL is a piece of software on its own, and there seems no
floating point number alternative in sight, one would have to change/adopt
the number representation and arithmetics (!) in OpenSCAD in order to avoid
all this problems and gain a sort of seemless representation. Obviously this
will hold only up the point, where STL imports are involved, or floating
point numbers come into play for similar reasons. This theme has been
discussed extensively a while ago, without concrete results  no way to do
away with it.

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 20190707 23:24, Parkinbot wrote:
> Carsten, as CGAL is a piece of software on its own, and there seems no
> floating point number alternative in sight,
Actually, that is not true. There is at least one surface mesh /
floating point vertex based alternative, namely Carve. The original is
at https://github.com/folded/carve and my fork is at
https://github.com/arnholm/carve. My fork fixes some compiler warnings
and makes carve MSVC compatible, plus replaces some deprecated C++
features (auto_ptr) with modern equivalents (unique_ptr).
I use Carve in AngelCAD, so indeed it is possible. You can compare the
features of AngelCAD and OpenSCAD to verify.
> one would have to change/adopt
> the number representation and arithmetics (!) in OpenSCAD in order to
> avoid
> all this problems and gain a sort of seemless representation.
All you need to do is a bit of software redesign, i.e. define the API
(Application Programming Interface) between the application (=OpenSCAD)
and the library (=CGAL today). I.e. what is the minimum set of features
used by OpenSCAD. Such a C++ API will have floating point vertices since
that is what the application generates anyway. Defining the API is stage
1.
Stage 2 is to implement the API backend using CGAL and check that
OpenSCAD still works as before. Stage 3 is to implement the API backend
using Carve (eliminating 'rational numbers').
> Obviously this
> will hold only up the point, where STL imports are involved,
STL import is a different animal which isn't directly related to
coordinate representation, importing STL is a problem regardless of
whether one employs floating point or 'rational number' coordinates
internally.
The issue with STL import to a modeller (as opposed to a slicer) is that
it is a 'polygon soup' with zero topological information, requiring
extensive coordinate matching. Such matching is prone to failure as it
is a matter of subjective interpretation. For this and other reasons, I
have chosen to do STL import in 2 stages, first convert to OBJ/OFF/AMF
in a separate application (polyfix, ref
https://github.com/arnholm/angelcad/releases ) that does
interpretations/repairs and establishes a topology. Then import from
OBJ/OFF/AMF into AngelCAD.
OpenSCAD could choose to do it differently, e.g. one could declare STL
import as a legacy feature and promote formats such as OBJ (or whatever)
as better alternatives.
> or floating
> point numbers come into play for similar reasons. This theme has been
> discussed extensively a while ago, without concrete results  no way to
> do
> away with it.
See above. As you say this was discussed before and like now I was told
it could not be done. Therefore, I did it :)
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


cacb wrote
> On 20190707 23:24, Parkinbot wrote:
>> Carsten, as CGAL is a piece of software on its own, and there seems no
>> floating point number alternative in sight,
>
> Actually, that is not true. There is at least one surface mesh /
> floating point vertex based alternative, namely Carve.
Carsten, how could one miss this?
But even without having had a closer look into Carve and your adapation, I
dare to doubt that a pure floating point representation approach on both
sides, OpenSCAD and the rendering part, will be able to do away with the
snaptogrid problem, because the problem rather *arises* with the use of
floating point representation. Any translation within a non aequidistant
grid will suffer from a snaptogrid result. As floating point arithmetic is
not commuative (e.g. a+bc = ac+b will not hold) Boolean operations will
have to deal with snaptogrids all the time. So two operations will not
have the same result with respect to translation. What does this mean for a
union operation? Or for a symmetric object construction scheme as proposed
by the thread starter.
CGAL may be slow, but the architects' decision to build on a rational number
representation had good reasons ...

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


CGAL may be slow, but the architects' decision to build on a rational number representation had good reasons .
Yes but OpenSCAD gains zero advantage from this because it converts back to doubles and snaps to a grid and then feeds the results back to CGAL.
If Carve can do booleans in floating point then OpenSCAD will simply feed in floats and get floats back. There would be no need to snap to a grid and if it works in floats, rather than doubles, STL export will work.
cacb wrote
> On 20190707 23:24, Parkinbot wrote:
>> Carsten, as CGAL is a piece of software on its own, and there seems no
>> floating point number alternative in sight,
>
> Actually, that is not true. There is at least one surface mesh /
> floating point vertex based alternative, namely Carve.
Carsten, how could one miss this?
But even without having had a closer look into Carve and your adapation, I
dare to doubt that a pure floating point representation approach on both
sides, OpenSCAD and the rendering part, will be able to do away with the
snaptogrid problem, because the problem rather *arises* with the use of
floating point representation. Any translation within a non aequidistant
grid will suffer from a snaptogrid result. As floating point arithmetic is
not commuative (e.g. a+bc = ac+b will not hold) Boolean operations will
have to deal with snaptogrids all the time. So two operations will not
have the same result with respect to translation. What does this mean for a
union operation? Or for a symmetric object construction scheme as proposed
by the thread starter.
CGAL may be slow, but the architects' decision to build on a rational number
representation had good reasons ...

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 20190708 11:23, Parkinbot wrote:
> cacb wrote
>> On 20190707 23:24, Parkinbot wrote:
>>> Carsten, as CGAL is a piece of software on its own, and there seems
>>> no
>>> floating point number alternative in sight,
>>
>> Actually, that is not true. There is at least one surface mesh /
>> floating point vertex based alternative, namely Carve.
>
> Carsten, how could one miss this?
Being convinced no alternative exists, one stops looking for it?
> But even without having had a closer look into Carve and your
> adapation, I
> dare to doubt that a pure floating point representation approach on
> both
> sides, OpenSCAD and the rendering part, will be able to do away with
> the
> snaptogrid problem, because the problem rather *arises* with the use
> of
> floating point representation. Any translation within a non
> aequidistant
> grid will suffer from a snaptogrid result. As floating point
> arithmetic is
> not commuative (e.g. a+bc = ac+b will not hold) Boolean operations
> will
> have to deal with snaptogrids all the time. So two operations will
> not
> have the same result with respect to translation. What does this mean
> for a
> union operation? Or for a symmetric object construction scheme as
> proposed
> by the thread starter.
> CGAL may be slow, but the architects' decision to build on a rational
> number
> representation had good reasons ...
For your theory to hold you need to use exact arithmetic at all levels
and not just in parts. OpenSCAD doesn't do that so all you really get is
floating point precision anyway. All theory aside, what matters is
practice, try it for yourself. AngelCAD uses my Carve fork via xcsg
https://github.com/arnholm/xcsg . I suggest you try AngelCAD to see if
the theory holds (the AngelCAD binary bundles xcsg). Link to
documentation and download at https://arnholm.github.io/angelcaddocs/ .
All talk of 'grid' requirement is a misunderstanding the way I see it,
unless you talk about the special case of explicit coordinate matching
from an STL polygon soup, where there are no shared vertices. Boolean
operations don't work on polygon soups, they work on polyhedra. This is
true in both CGAL and Carve. In AngelCAD/xcsg there are no grids.
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 20190708 12:44, nop head wrote:
> Yes but OpenSCAD gains zero advantage from this because it converts
> back to doubles and snaps to a grid and then feeds the results back to
> CGAL.
Correct (on zero advantage).
> If Carve can do booleans in floating point then OpenSCAD will simply
> feed in floats and get floats back. There would be no need to snap to
> a grid and if it works in floats, rather than doubles, STL export will
> work.
Carve works in native double precision. I have implemented STL export by
casting to float (i.e. to single precision) at the point of writing to
*binary* file. Single precision in *binary* STL is another aspect of STL
(in addition to the polygon soup issue) that makes it unsuitable for
model exchange between modellers, including the case where the exporter
and importer application is the same (OpenSCAD). You lose more precision
using STL than the difference between double precision and 'rational
numbers'. Single precision is equivalent to just 67 significant digits.
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


If you cast double to float then you will have the same STL export problems that OpenSCAD has. Any reduction in resolution needs to fix degenerate triangles and self intersections.
Note also OpenSCAD uses its own PolySet format and that is also a polygon soup like STL. The only difference is it doubles and actually polygons, not just triangles.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

12
