AC
Alan Cox
Mon, Jul 8, 2019 8:15 PM
On 2019-07-08 15:47, Alan Cox wrote:
using STL than the difference between double precision and 'rational
numbers'. Single precision is equivalent to just 6-7 significant
digits.
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
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.
Sure but that is the easy bit. Good STL exporters use a point dictionary.
It's not rocket science. Binary STL is not a good system in the first
place as you say.
Alan
On Mon, 08 Jul 2019 17:49:46 +0200
arnholm@arnholm.org wrote:
> On 2019-07-08 15:47, Alan Cox wrote:
> >> using STL than the difference between double precision and 'rational
> >> numbers'. Single precision is equivalent to just 6-7 significant
> >> digits.
> >
> > 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
>
> 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.
Sure but that is the easy bit. Good STL exporters use a point dictionary.
It's not rocket science. Binary STL is not a good system in the first
place as you say.
Alan
N
NateTG
Mon, Jul 8, 2019 8:21 PM
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).
DanS wrote
> 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).
So you're trying to make something like a triangular pyramid but with ogee
profiles?
--
Sent from: http://forum.openscad.org/
DS
Dan Shriver
Tue, Jul 9, 2019 1:37 AM
Nate: it's not a pyramid, its a series of arched hallways. The form of the
arch morphs between ogee and roman arch styles. The o. verall path of
1/3 of the hallways is in the shape of an ogee arch.
Once I finish with that I'll put in domes and decorative buttress works.
Nop head: given what you were saying about how if you had two things with
an exact union, and then you rotated it and they came apart. I am
wondering if I need to rethink how to make 1/3 of the archway. Since I
intend to do it where I rotate it (and right now I'm using a box to exactly
saw off what is in the next octant), I am thinking that for the ones I
rotate I need to shift the bounding box so there is more overlap. But how
much do I need? 1 unit, 0.5 units???? Any ideas?
On Mon, Jul 8, 2019 at 4:22 PM NateTG nate-openscadforum@pedantic.org
wrote:
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
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).
Nate: it's not a pyramid, its a series of arched hallways. The form of the
arch morphs between ogee and roman arch styles. The o. verall path of
1/3 of the hallways is in the shape of an ogee arch.
Once I finish with that I'll put in domes and decorative buttress works.
Nop head: given what you were saying about how if you had two things with
an exact union, and then you rotated it and they came apart. I am
wondering if I need to rethink how to make 1/3 of the archway. Since I
intend to do it where I rotate it (and right now I'm using a box to exactly
saw off what is in the next octant), I am thinking that for the ones I
rotate I need to shift the bounding box so there is more overlap. But how
much do I need? 1 unit, 0.5 units???? Any ideas?
On Mon, Jul 8, 2019 at 4:22 PM NateTG <nate-openscadforum@pedantic.org>
wrote:
> DanS wrote
> > 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).
>
> So you're trying to make something like a triangular pyramid but with ogee
> profiles?
>
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
AC
A. Craig West
Tue, Jul 9, 2019 1:49 AM
I usually use a 0.01 unit overlap, it really doesn't need to be much
On Mon, 8 Jul 2019, 21:38 Dan Shriver, tabbydan@gmail.com wrote:
Nate: it's not a pyramid, its a series of arched hallways. The form of
the arch morphs between ogee and roman arch styles. The o. verall path
of 1/3 of the hallways is in the shape of an ogee arch.
Once I finish with that I'll put in domes and decorative buttress works.
Nop head: given what you were saying about how if you had two things with
an exact union, and then you rotated it and they came apart. I am
wondering if I need to rethink how to make 1/3 of the archway. Since I
intend to do it where I rotate it (and right now I'm using a box to exactly
saw off what is in the next octant), I am thinking that for the ones I
rotate I need to shift the bounding box so there is more overlap. But how
much do I need? 1 unit, 0.5 units???? Any ideas?
On Mon, Jul 8, 2019 at 4:22 PM NateTG nate-openscadforum@pedantic.org
wrote:
Nate: what I was asking in the original post was how to take 1/6th of
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
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).
I usually use a 0.01 unit overlap, it really doesn't need to be much
On Mon, 8 Jul 2019, 21:38 Dan Shriver, <tabbydan@gmail.com> wrote:
> Nate: it's not a pyramid, its a series of arched hallways. The form of
> the arch morphs between ogee and roman arch styles. The o. verall path
> of 1/3 of the hallways is in the shape of an ogee arch.
>
> Once I finish with that I'll put in domes and decorative buttress works.
>
> Nop head: given what you were saying about how if you had two things with
> an exact union, and then you rotated it and they came apart. I am
> wondering if I need to rethink how to make 1/3 of the archway. Since I
> intend to do it where I rotate it (and right now I'm using a box to exactly
> saw off what is in the next octant), I am thinking that for the ones I
> rotate I need to shift the bounding box so there is more overlap. But how
> much do I need? 1 unit, 0.5 units???? Any ideas?
>
> On Mon, Jul 8, 2019 at 4:22 PM NateTG <nate-openscadforum@pedantic.org>
> wrote:
>
>> DanS wrote
>> > 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).
>>
>> So you're trying to make something like a triangular pyramid but with ogee
>> profiles?
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
NH
nop head
Tue, Jul 9, 2019 6:49 AM
I use 1/128 because it is a round number in floating point. 0.01 is a
recurring fraction. It probably doesn't make any difference in most cases,
but seems like a good idea.
Nop head: given what you were saying about how if you had two things with
an exact union, and then you rotated it and they came apart.
They would only possibly come apart if you rotate them individually before
the union. Rotating a unioned object should not break it, but it can
perturb the vertices and make flat plans no longer exactly flat.
On Tue, 9 Jul 2019 at 02:50, A. Craig West acraigwest@gmail.com wrote:
I usually use a 0.01 unit overlap, it really doesn't need to be much
On Mon, 8 Jul 2019, 21:38 Dan Shriver, tabbydan@gmail.com wrote:
Nate: it's not a pyramid, its a series of arched hallways. The form of
the arch morphs between ogee and roman arch styles. The o. verall path
of 1/3 of the hallways is in the shape of an ogee arch.
Once I finish with that I'll put in domes and decorative buttress works.
Nop head: given what you were saying about how if you had two things with
an exact union, and then you rotated it and they came apart. I am
wondering if I need to rethink how to make 1/3 of the archway. Since I
intend to do it where I rotate it (and right now I'm using a box to exactly
saw off what is in the next octant), I am thinking that for the ones I
rotate I need to shift the bounding box so there is more overlap. But how
much do I need? 1 unit, 0.5 units???? Any ideas?
On Mon, Jul 8, 2019 at 4:22 PM NateTG nate-openscadforum@pedantic.org
wrote:
Nate: what I was asking in the original post was how to take 1/6th of
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
to be using a box.
After that I take that whole shape and need to displace it and rotate
by
120 (I need to do that twice).
I use 1/128 because it is a round number in floating point. 0.01 is a
recurring fraction. It probably doesn't make any difference in most cases,
but seems like a good idea.
>Nop head: given what you were saying about how if you had two things with
an exact union, and then you rotated it and they came apart.
They would only possibly come apart if you rotate them individually before
the union. Rotating a unioned object should not break it, but it can
perturb the vertices and make flat plans no longer exactly flat.
On Tue, 9 Jul 2019 at 02:50, A. Craig West <acraigwest@gmail.com> wrote:
> I usually use a 0.01 unit overlap, it really doesn't need to be much
>
> On Mon, 8 Jul 2019, 21:38 Dan Shriver, <tabbydan@gmail.com> wrote:
>
>> Nate: it's not a pyramid, its a series of arched hallways. The form of
>> the arch morphs between ogee and roman arch styles. The o. verall path
>> of 1/3 of the hallways is in the shape of an ogee arch.
>>
>> Once I finish with that I'll put in domes and decorative buttress works.
>>
>> Nop head: given what you were saying about how if you had two things with
>> an exact union, and then you rotated it and they came apart. I am
>> wondering if I need to rethink how to make 1/3 of the archway. Since I
>> intend to do it where I rotate it (and right now I'm using a box to exactly
>> saw off what is in the next octant), I am thinking that for the ones I
>> rotate I need to shift the bounding box so there is more overlap. But how
>> much do I need? 1 unit, 0.5 units???? Any ideas?
>>
>> On Mon, Jul 8, 2019 at 4:22 PM NateTG <nate-openscadforum@pedantic.org>
>> wrote:
>>
>>> DanS wrote
>>> > 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).
>>>
>>> So you're trying to make something like a triangular pyramid but with
>>> ogee
>>> profiles?
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://forum.openscad.org/
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
RW
Rogier Wolff
Tue, Jul 9, 2019 12:06 PM
On Mon, Jul 08, 2019 at 05:13:15PM +0100, nop head 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.
rotate (2) cube (10);
I have now represented a rotation with numbers (numerically) on a
digital computer (mine, yours currently in your Email program or maybe
browser).
But yes, that "2" represents 2 degrees, which for technical reasons
needs to be in radians ASAP. Then it becomes irrational. And most of
the vertices of the cube move to irrational coordinates.
For an example of "not exactly meeting":
Suppose I do something like:
rotate (30) {
for (i=[0:10:60])
rotate (i) cube (10);
}
now onthe last object you'd think it's rotated by 90 degrees but in fact
its 30+60. Each of which was at one point converted to radians, rounded to
the nearest double and then used to do trigonometry functions...
In fact in this case I know that 30 and 60 in radians will be rounded
precisely in the same direction: in floating point only the exponent
differs. Thus the tolerance on the 90 degrees is even larger. And now
that rotation is no longer precisely 90 degrees....
Roger.
--
** R.E.Wolff@BitWizard.nl ** 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.
On Mon, Jul 08, 2019 at 05:13:15PM +0100, nop head 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.
rotate (2) cube (10);
I have now represented a rotation with numbers (numerically) on a
digital computer (mine, yours currently in your Email program or maybe
browser).
But yes, that "2" represents 2 degrees, which for technical reasons
needs to be in radians ASAP. Then it becomes irrational. And most of
the vertices of the cube move to irrational coordinates.
For an example of "not exactly meeting":
Suppose I do something like:
rotate (30) {
for (i=[0:10:60])
rotate (i) cube (10);
}
now onthe last object you'd think it's rotated by 90 degrees but in fact
its 30+60. Each of which was at one point converted to radians, rounded to
the nearest double and then used to do trigonometry functions...
In fact in this case I know that 30 and 60 in radians will be rounded
precisely in the same direction: in floating point only the exponent
differs. Thus the tolerance on the 90 degrees is even larger. And now
that rotation is no longer precisely 90 degrees....
Roger.
--
** R.E.Wolff@BitWizard.nl ** 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.
NH
nop head
Tue, Jul 9, 2019 1:42 PM
I have now represented a rotation with numbers (numerically) on a digital
computer (mine, yours currently in your Email program or maybe browser).
I would say that is a symbolic representation like cos(30) or sqrt(3) /2.
The numerical representation is 0.86602540378443864676372317075294........
On Tue, 9 Jul 2019 at 13:07, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Mon, Jul 08, 2019 at 05:13:15PM +0100, nop head 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.
rotate (2) cube (10);
I have now represented a rotation with numbers (numerically) on a
digital computer (mine, yours currently in your Email program or maybe
browser).
But yes, that "2" represents 2 degrees, which for technical reasons
needs to be in radians ASAP. Then it becomes irrational. And most of
the vertices of the cube move to irrational coordinates.
For an example of "not exactly meeting":
Suppose I do something like:
rotate (30) {
for (i=[0:10:60])
rotate (i) cube (10);
}
now onthe last object you'd think it's rotated by 90 degrees but in fact
its 30+60. Each of which was at one point converted to radians, rounded to
the nearest double and then used to do trigonometry functions...
In fact in this case I know that 30 and 60 in radians will be rounded
precisely in the same direction: in floating point only the exponent
differs. Thus the tolerance on the 90 degrees is even larger. And now
that rotation is no longer precisely 90 degrees....
Roger.
--
** R.E.Wolff@BitWizard.nl ** 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> I have now represented a rotation with numbers (numerically) on a digital
> computer (mine, yours currently in your Email program or maybe browser).
I would say that is a symbolic representation like cos(30) or sqrt(3) /2.
The numerical representation is 0.86602540378443864676372317075294........
On Tue, 9 Jul 2019 at 13:07, Rogier Wolff <R.E.Wolff@bitwizard.nl> wrote:
> On Mon, Jul 08, 2019 at 05:13:15PM +0100, nop head 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.
>
> rotate (2) cube (10);
>
> I have now represented a rotation with numbers (numerically) on a
> digital computer (mine, yours currently in your Email program or maybe
> browser).
>
> But yes, that "2" represents 2 degrees, which for technical reasons
> needs to be in radians ASAP. Then it becomes irrational. And most of
> the vertices of the cube move to irrational coordinates.
>
> For an example of "not exactly meeting":
>
> Suppose I do something like:
> rotate (30) {
> for (i=[0:10:60])
> rotate (i) cube (10);
> }
>
> now onthe last object you'd think it's rotated by 90 degrees but in fact
> its 30+60. Each of which was at one point converted to radians, rounded to
> the nearest double and then used to do trigonometry functions...
>
> In fact in this case I know that 30 and 60 in radians will be rounded
> precisely in the same direction: in floating point only the exponent
> differs. Thus the tolerance on the 90 degrees is even larger. And now
> that rotation is no longer precisely 90 degrees....
>
> Roger.
>
>
> --
> ** R.E.Wolff@BitWizard.nl ** 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
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>