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_Characters I 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! 
In reply to this post by DanS
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 Sun, 7 Jul 2019 at 14:38, <[hidden email]> wrote: On 20190707 13:52, Parkinbot wrote: _______________________________________________ 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, 7 Jul 2019 at 15:12, Rogier Wolff <[hidden email]> wrote: On Sun, Jul 07, 2019 at 02:44:03PM +0100, nop head wrote: _______________________________________________ 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? On Sun, Jul 7, 2019 at 11:07 AM nop head <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by nophead
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 
In reply to this post by DanS
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 <[hidden email]> wrote:
_______________________________________________ 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. On Sun, Jul 7, 2019 at 5:24 PM Parkinbot <[hidden email]> wrote: All this discussion leads far away from the origin of the thread. It may _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by Parkinbot
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. On Mon, 8 Jul 2019 at 10:23, Parkinbot <[hidden email]> wrote: cacb wrote _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by Parkinbot
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 
In reply to this post by nophead
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 
In reply to this post by cacb
On 08.07.19 12:55, [hidden email] wrote:
> Being convinced no alternative exists, one stops looking for it? Not sure who would be convinced of that. I can at least say, I'm not and I would find it awesome to have the option to use other libraries. https://github.com/openscad/openscad/wiki/Project:SurveyofCSGalgorithms That topic actually had a student applying for for this years GSoC  but we don't have enough people to mentor more than the two project we currently support. ciao, Torsten. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
 Torsten

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. On Mon, 8 Jul 2019 at 13:03, Torsten Paul <[hidden email]> wrote: On 08.07.19 12:55, [hidden email] wrote: _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Free forum by Nabble  Edit this page 