In my most recent endeavors with LaserBoy I've been working a lot more with double precision floating point numbers for 3D coordinate math. The frame set I posted above actually has a specific purpose. The white outline around the 2D view of the vector art is an irregular convex polygon. And It has a point inside of it called its centroid. A centroid point can be calculated to be the same point regardless of the rotation of the polygon. This is much different than calculating a point that is half the height and half the width (rectangular center). Just consider the case of an equilateral triangle. If it's sitting on its base, half of its height is certainly not the rotational center of the shape. So if you want to rotate or scale an element in a frame, you have to have a reference point to do it from. If you simply multiple all the coordinate values by some number larger than one, the object will get bigger and it will also move away from the origin of space , the point {0, 0, 0}. But if you first subtract the centroid from all of the vertices, then do the multiplication, then add the centroid back to the vertices, the object will scale unto itself. The same applies to rotation. You have to pick at least two of the three values of x, y and z to define a line, parallel to an axis, to spin around.
It is worth nothing that a centroid is entirely a 2D concept. It is calculated by determining the area of the irregular polygon. This is done by breaking the irregular polygon into a set of triangles and adding all of them together. This area is then used in another calculation that averages all of the centroids of the triangles together.
https://en.wikipedia.org/wiki/Centroid
See the section "Of A Polygon".
A polygon is a 2D entity. So I came up with the idea of using all three views of space, front, side and top, to find the 2D polygons, their areas and centroids and using that information to calculate a sort of 3D centroid. Each 2D view can contribute information about 2 of the coordinate's values (x, y) (z, y) & (x, z). The influence each view has on the 3D centroid point is weighted in the calculation based on the area of each view's polygon.
A polygon is defined by no less than three non-co-linear points (at least a triangle). A single point has no area, nor does a line.
All of this is factored into my calculation for the 3D centroid.
Basically I take all of the coordinates of the vertices in a frame and reorder them in order of rotation around their rectangular center from zero to 2 pi radians (counter-clockwise). Then I find the point that is farthest away from the center and reorder the coordinates from that point as I know it must be on the outside of the polygon. The point set is still in order of rotation. Then I look at the angles made by starting at p1, going through p2 and on to p3. If that angle is zero to pi radians, then it forms a concave angle (pointing inward to the polygon) and I remove p2 from the set.
I use the atan2 function in C++ and I define the special cases where p1, p2 or p3 might be the same point to be zero radians. (The atan2 function itself considers this situation to produce an out_of_range answer as it makes no sense).
This is where it all falls apart in Windows.
Even though I am using MinGW and GNU GCC as my compiler in Windows, by default, the way it processes floating point numbers in the CPU / FPU is significantly different in Linux than it is in Windows. I have to set switches in the g++ compiler instruction in the Makefile so that it knows to setup the CPU / FPU floating point mode and translate the C++ code to specific machine code instructions to do all of the math correctly.
Linux does this by default. Windows does not. As one result (of many) all of the fp comparison operators like if(a < b) are completely unreliable and therefore useless. This issue is not at all associated with the GCC compiler. This odd behavior is the default for any compiler that runs in Windows.
I don't know about you, but I think that's just nuts.
James.