> While I think fixed point math is may be a good idea, I don't think it is

> the panacea for all performance problems. Yes, fixed point math makes it

> much easier to implement robust geometric predicates – but by using a

> filtered kernel, robust predicates are also possible to do efficiently with

> floating point. There is a performance difference, but my guess is that it

> is something like a factor of 2. In order to calculate exact geometric

> constructions, such as the intersection point of two lines, fixed point math

> is not sufficient and a rational representation is needed.

Its depends a lot on the processor, especially if you want to support non

x86 processors or to an extent x86 Atom processors

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdfis the guide for X86 timings.

All the good stuff really wants SIMD instructions.

> It may be possible to do CSG robustly without needing to calculate exact

It is, people have been doing it for ages. It's armwavingly equivalent to

replacing each point in space with a small sphere. This is not rocket

science. Minecraft is an extreme example 8)

However it really comes down to a different geometry engine.

> * Implementing a floating point to floating point (or fixed -> fixed) CSG

> mesh operation using a small amount of exact arithmetics for intermediate

> calculations. Degenerate and self-intersecting geometry can be a problem, so

> some kind of mesh cleaning must likely be performed afterwards. As an

> experiment I have implemented one such library based on Cyril Leconte's code

> in MEPP. The speed-up from CGAL Nef is currently in the order of 20–50 x.

In itself a very good start. In real terms thats a 5 minute render down to

10 seconds or so, which is a big big win!

> * A third option I find very interesting for additive manufacturing is

> deferring CSG operations to the actual slicing step. 2D CSG is much faster

> than 3D CSG and all slicers have polygonal slices as a simple intermediary

> representation.

That was kind of where ImplicitCAD was heading before it got abandoned

by its author. At that point the slicer simply solves the equation

describing what is inside/outside for the x and y range with z set for

each slice.

The mathematical manipulations are well understood (by mathematicians at

least 8)) and it is relatively easy to describe some quite complex

curves, fillets and rounding.

Alan

_______________________________________________

OpenSCAD mailing list

[hidden email]
http://rocklinux.net/mailman/listinfo/openscadhttp://openscad.org -

https://flattr.com/thing/121566