> 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 _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by nophead
nophead wrote
>> >> CGAL may be slow, but the architects' decision to build on a rational >> number representation had good reasons . > Yes but OpenSCAD gains zero advantage from this because it converts back > to > doubles and snaps to a grid and then feeds the results back to CGAL. 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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.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 <[hidden email]> wrote: nophead wrote _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.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. ... 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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by DanS
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. > Will OpenSCAD really convert the result of the union twice before 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 <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by Alan Cox-2
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. Carsten Arnholm _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by NateTG
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 <[hidden email]> wrote: > ... So the extended discussion of the internals is interesting and _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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 <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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 <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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 <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by cacb
On Mon, 08 Jul 2019 17:49:46 +0200
[hidden email] 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 _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by DanS
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 [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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 <[hidden email]> wrote: DanS wrote _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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, <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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 <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by nophead
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. -- ** [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 |
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 <[hidden email]> wrote: On Mon, Jul 08, 2019 at 05:13:15PM +0100, nop head wrote: _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Free forum by Nabble | Edit this page |