# General approach

37 messages
12
Open this post in threaded view
|

## General approach

 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 gapalternately I was thinking two differences might give both a correct interior and exterior viewdifference() {   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
Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

 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 non-valid 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
Open this post in threaded view
|

## Re: General approach

 On 2019-07-07 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
Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

 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. -- ** [hidden email] ** 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 [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

 On 2019-07-07 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
Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

 cacb wrote > On 2019-07-07 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 snap-to-grid problem, because the problem rather *arises* with the use of floating point representation. Any translation within a non aequidistant grid will suffer from a snap-to-grid result. As floating point arithmetic is not commuative (e.g. a+b-c = a-c+b will not hold) Boolean operations will have to deal with snap-to-grids 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
Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

Open this post in threaded view
|

## Re: General approach

 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:-Survey-of-CSG-algorithmsThat 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