On 11.06.23 23:14, neri-engineering via Discuss wrote: > I am making further progress at looking into OpenSCAD/CGAL issues of > sub-optimal polyhedron combination. Before you dive very deep into the CGAL topic, make sure you are aware of the recent use of the Manifold library. If it can/will replace CGAL completely, or maybe just for most operations is still undecided. But Manifold seems more targeted to real world applications where CGAL tries to go the slower route modeling ideal math. The general topic probably still applies, but it might do so in a quite different way as the approaches seem to be quite different between CGAL and Manifold. ciao, Torsten.

I had a further idea. If I implemented a CSG engine then I would like to try to use fixed-point arithmetic for added precision. I have thought about fixed-point fractional numbers for my line-drawing, and soon realized that it would indeed be possible but that it is a large undertaking with many mental challenges and puzzles. So for example all the vertices in the engineering "world" could be constrained to be in the range [-32768.0,32768.0). The number of fractional numbers between two adjacent integer which both fall within that range could be 2^(64-16) or 2^48. E.g., in the interval [0,1) there would be 2^48 finer points, spaced equally apart. In the intervals [1,2), [2,3), ... [32767,32768) likewise. There are 32768 such positive intervals, which is 2^15. On the negative spectrum, in the interval [-1,0) there would also be 2^48 points. Same with the intervals [-2,-1), ... [-32768,-32767), of which there are a total of 32768 once again which is 2^15. So is there are 2*2^15 intervals, e.g. if there are 2^16 intervals each of which contains 2^48 equally spaced points within, then there are a total of 2^64 points, perfect for a 64 bit integer data type. If some pieces extend beyond these bounds then the entire piece can be scaled before and after the CSG operations, the cost being a slight reduction in accuracy. In can be determined how values are input into the system - could be fixed point or could be 64 bit floating point, but using 64 bit fixed point internally would improve accuracy a lot. An improved file format with named/referenced vertices that can be re-used would be better as well. I don't believe that STL currently supports this but I could be wrong. I don't want to get too carried away in this email here. We can assume that inputs are standard STL, but would be nice to allow STL coordinates to be more precise, namely in 64 bit floating point. Not required but optional. Lastly with very careful computations, at the core of which are operations such as simple line segment intersection, cross product, vector length and the like, a wicked fast CSG engine could be created esp. if a spacial index such as R-tree is employed. You could have an engine that performs an operation in more or less time that is proportional to N*log(N) where N is the number of facets in your model(s). Right now I think the time complexity in OpenSCAD for compiling (F6) seems to be at least N^2, and on top of that the operations create little jaggies and extra facets everywhere, which slows things down even more. I would very much like to take on this task as an intellectual pursuit, to keep my mind sharp, over the coming months and years. I have been thinking about the possibility of such a project for at least 6 months now. I don't think it's worth my time to look into existing open source projects because I will likely be dismayed at the level of attention to detail in those other projects, which is usually the case when I look at open source projects. Probably written in Java, so that too much focus isn't paid on simple kinds of errors that Java catches, with added overhead cost of course. My favorite license is the BSD license, which does not force itself onto others touching your code, as is the case with GPL and its variants. I esp. like how Apple managed to use much of the FreeBSD code base in their operating system. I wonder what Linus Torvalds would have done had he known that BSD existed before he started working on the Linux kernel. Cheers, Nerius Anthony Landys Sent with Proton Mail secure email. ------- Original Message ------- On Sunday, June 11th, 2023 at 4:40 PM, Torsten Paul <Torsten.Paul@gmx.de> wrote: > On 11.06.23 23:14, neri-engineering via Discuss wrote: > > > I am making further progress at looking into OpenSCAD/CGAL issues of > > sub-optimal polyhedron combination. > > > Before you dive very deep into the CGAL topic, make sure you are aware > of the recent use of the Manifold library. If it can/will replace CGAL > completely, or maybe just for most operations is still undecided. But > Manifold seems more targeted to real world applications where CGAL tries > to go the slower route modeling ideal math. > > The general topic probably still applies, but it might do so in a quite > different way as the approaches seem to be quite different between > CGAL and Manifold. > > ciao, > Torsten. > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org