Doug moen doug@moens.org wrote:

Alan Cox alan@lxorguk.ukuu.org.uk wrote:

I am amused by this discussion -- a 3rd year computer science
lecturer debating with Alan Cox on the appropriateness of fixed point
calculations.

I'm pleased to see that OpenSCAD is a useful enough program that you
would like to try improving it.

• D

On 26/11/15 08:13, David Eccles (gringer) wrote:

Sorry, I got my wires crossed with that statement. Presumably a student
rather than a lecturer.

• David

On Thu, 26 Nov 2015 13:43:04 +1300
"David Eccles (gringer)" bioinformatics@gringene.org wrote:

And long may it continue because age doesn't make you right, experience
doesn't always make you right and someone who is a student today is
learning stuff we never did because the world has moved on.

Alan

The way I see it, yes you could use integers for the model coordinates if
you pick a very small unit, but I don't see how that is an advantage. If
you want to stack three equal cubes to make 100mm you can't do it because
100/3 is not an integer. As soon as you start doing trigonometry you can't
use integers, you need at least fixed point but that is just a poor man's
floating point. If you have hardware floating point why use fixed point?
Yes you can represent it with integers and an implicit scale but it doesn't
have any better properties than floating point regarding accuracy and
representing fractions.

The basic problem is trigonometry has fractions, irrationals and
transcendental numbers and none of these can be exactly represented with
integers, fixed point or floating point. CGAL uses rationals to allow exact
fractions but is very slow. Not sure why because a lot of numbers are
irrational as soon as you do rotations. But it seems to do a good job of
keeping things manifold.

Floating point doesn't cause non-manifold problems per se but any
truncation or rounding needs to be be topologically aware to avoid
collapsing vertexes. Using integers for the model doesn't help as you can
still have very close vertices that collapse under scaling or rotation.

Z fighting is just due to limited precision maths. Two coincident surfaces
have exactly the same depth, so theoretically which one you see should only
depend on the order they are drawn. But in practice when you rotate the
surfaces and then calculate the Z value of every pixel in a triangle and
quantise it to the Z buffer resolution the values are not always exactly
the same. Nothing to do with the model using floating point as it may all
be done in integer maths in the GPU at that point. The problem is the two
coplanar triangles have different vertices, so when you calculated the
depth at an arbitrary point you get slightly different results numerical
when you start from different vertices.

Unless computers start computing symbolically instead of numerically,
processing geometry is always going to cause problems like these. Using
integers is no solution.

On 26 November 2015 at 11:04, Alan Cox alan@lxorguk.ukuu.org.uk wrote:

If you view your integers (or floats or whatever) as points then yes, but
they are not - they are little cubes. Thats such a huge shift from what
CGAL does that I don't see any way it could be changed to work
symbolically and then use marching cubes or similar.

Alan

Sounds like high-res voxels.

On Thu, Nov 26, 2015, 21:32 Alan Cox alan@lxorguk.ukuu.org.uk wrote: