But if you are speed obsessed you can just fixed point, which is more
stable, means all your operations occur on fixed sized cubes that don't
change with position, and is somewhat easier to vectorise, especially on
low end processors.

Alternatively you use the GPU to do the work.

Alan

nophead wrote

I am aware that CGAL only internally gains advantage of this and that it
would be a large progress (and amount of work), if OpenSCAD didn't dismiss
CGAL representations when looping, respectively if OpenSCAD also supported
transformations in CGAL-representation to avoid such conversions for all
intermediate steps. This would reduce the need of conversions to I/O
operations only.

What I don't know is, how many loops OpenSCAD actually uses when it renders
a design. So what happens exactly for

difference()
{
union() {A(); B();}
C();
}

with A(), B(), C() defined as modules with visual output? Will OpenSCAD
really convert the result of the
union twice before difference is called?

And here:

difference()
{
rotate(45)
union() {A(); B();}
C();
}

will OpenSCAD excute rotate in floating point representation?

--
Sent from: http://forum.openscad.org/

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.

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.

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?

On Mon, Jul 8, 2019 at 10:12 AM Parkinbot rudolf@digitaldocument.de wrote:

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. ...

The stuff in the original post doesn't seem correct to me.  It seems like
you're confusing rotation by 180 degrees with reflection.

Can you try using:

"rotate (v=[0,1,0], a=180)"

instead of

"mirror([1,0,0])"

?

--
Sent from: http://forum.openscad.org/

The only exact rotations that can be relied on are by multiples of 90
degrees. If you rotate by 120 you get sqrt(0.75) factors in the matrix
which are irrational.

will OpenSCAD excute rotate in floating point representation?

Yes using matrices of doubles.

difference is called?

I think it depends if you have render anywhere and if you do an F5 before
an F6. If you clear the cache and do F6 it tends to keep things in CGAL
notation and give a cleaner result.

On Mon, 8 Jul 2019 at 16:18, Dan Shriver tabbydan@gmail.com wrote:

On 2019-07-08 15:47, Alan Cox wrote:

STL format has nothing to do with speed. You can use whatever method you
think will work (whether it does or not), but if you export to STL you
must adhere to the definition of that file format. In binary form that
means single precision with just 6-7 significant digits. This is
unrelated to computations employed, with or without obsessions.

Carsten Arnholm

Nate: what I was asking in the original post was how to take 1/6th of the
hallway design my head and make 1/3.  So yes it is a mirror operation.  The
best way to eliminate the stuff that overlapped the next octant turned out
to be using a box.

After that I take that whole shape and need to displace it and rotate it by
120 (I need to do that twice).

Nop head: on the irrationals do I just get a rounding error or is there a
more serious problem?  If it is a more serious problem is it possible to
avoid it?

On Mon, Jul 8, 2019 at 11:38 AM NateTG nate-openscadforum@pedantic.org
wrote:

You get rounding errors because it is impossible to represent exact
rotations numerically on a digital computer. Of course it is accurate
enough for real life but you can't rely vertex positions exactly meeting
for example.

Even without rotations you can't accurately stack two 0.1mm blocks because
0.1 is a recurring fraction in binary. So it is safe to union two 1mm cubes
without any overlap but not two 0.1mm cubes. One needs to understand how
numbers work on a computer to be able to avoid problems.

On Mon, 8 Jul 2019 at 16:51, Dan Shriver tabbydan@gmail.com wrote:

Thanks nop head:  I was just concerned because people were saying "barf"
etc.
Small errors, loss in precision, are acceptable to me.  I just don't want a
rotation to take a previously valid model and make it invalid.

On Mon, Jul 8, 2019 at 12:14 PM nop head nop.head@gmail.com wrote:

Rotating a whole model doesn't usually cause problems but consider this:
suppose you have a flat face and you union a cube with it. The intersection
points  will be exactly on the plane and so it remains a flat plane with a
cube sticking out. Now rotate the plane so it is inclined. The intersection
points probably can't be exactly on the plane because all its vertices are
irrational. They will be the nearest grid points to where they should be
put then the plane is no longer exactly flat. It has to be made with
triangles. Whether that matters or not depends if you have some vertices
that are very close and the rounding causes them to merge. For example if
you have a knife edge it might collapse and become self intersecting. I
think this is the reason CGAL uses rationals.

Even translating a model can cause it to break because as you move away
from the origin floats get less accurate. So close vertices at the origin
may merge when translated away from it.

On Mon, 8 Jul 2019 at 18:53, Dan Shriver tabbydan@gmail.com wrote: