[OpenSCAD] General approach
tabbydan at gmail.com
Sun Jul 7 18:59:56 EDT 2019
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 2-manifold (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 <rudolf at digitaldocument.de> wrote:
> 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
> involved and not snap-to-grid 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
> more general sense, since the thread originator asked to get some opinion
> 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
> 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
> Discuss at lists.openscad.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Discuss