<div dir="ltr">So the extended discussion of the internals is interesting and worthwhile but my original intent on the thread was to see if what I was doing made sense geometrically.  Similar to the thread about taking apart the three cones that were joined.<div><br><div>I later figured that since I was trying to join two things that were in different octants (which crossed over slightly at the end) would be to subtract a box that was in the other octant.</div></div><div><br></div><div>One concern I do have is that this makes 1/3 of my hallways and the rest would be made by 120 degree rotations.  Earlier in this thread someone was noting that various rotations would give irrational numbers (maybe this isn't any worse than the standard floating point, because they are just implicitly 'rounded' into something nearby that isn't irrational?).  How does one avoid doing a rotation operation which is "bad"?  Is there a "safe" way to do rotations?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019 at 10:12 AM Parkinbot <<a href="mailto:rudolf@digitaldocument.de">rudolf@digitaldocument.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">nophead wrote<br>
>><br>
>> CGAL may be slow, but the architects' decision to build on a rational<br>
>> number representation had good reasons .<br>
> Yes but OpenSCAD gains zero advantage from this because it converts back<br>
> to<br>
> doubles and snaps to a grid and then feeds the results back to CGAL.<br>
<br>
I am aware that CGAL only internally gains advantage of this and that it<br>
would be a large progress (and amount of work), if OpenSCAD didn't dismiss<br>
CGAL representations when looping, respectively if OpenSCAD also supported<br>
transformations in CGAL-representation to avoid such conversions for all<br>
intermediate steps. This would reduce the need of conversions to I/O<br>
operations only. <br>
<br>
What I don't know is, how many loops OpenSCAD actually uses when it renders<br>
a design. So what happens exactly for<br>
<br>
difference()<br>
{<br>
  union() {A(); B();}<br>
  C(); <br>
}<br>
<br>
with A(), B(), C() defined as modules with visual output? Will OpenSCAD<br>
really convert the result of the <br>
union twice before difference is called? <br>
<br>
And here: <br>
<br>
difference()<br>
{<br>
  rotate(45) <br>
  union() {A(); B();}<br>
  C(); <br>
}<br>
<br>
will OpenSCAD excute rotate in floating point representation? <br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://forum.openscad.org/" rel="noreferrer" target="_blank">http://forum.openscad.org/</a><br>
<br>
_______________________________________________<br>
OpenSCAD mailing list<br>
<a href="mailto:Discuss@lists.openscad.org" target="_blank">Discuss@lists.openscad.org</a><br>
<a href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" rel="noreferrer" target="_blank">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a><br>
</blockquote></div>