Started writing a series of brutal tests and also looked into the math of limits for input to ensure that the output will always be correct. I had done all the math for the predicates between the planes, but not on the actual plane construction.
To be able to store planes with native data types such as 32bit or 64bit values accurately and without overflow, the constructors need to ensure that the input is below a certain numerical limit.
Computing a plane from 3 sets of integer points, sets a limit on the value of these coordinates, we compute the Hadamard Inequality to determine the bounds of the volume. So a hard limit of 727041 to be able to ensure that the D component of the planar equation can be fit within 64 bits. Which is not that bad, since it will give you ~1.4 cubic kilo-meters to work with if you were working in milli-meters. Which fits nicely into the rest of my constrictions, since the maximum coefficient value you can possibly end up with, within those limits would be able pass into my orientation predicates to compute with <= 352 bits.
With these constraints set in place, I can impose the restrictions I need on value input to ensure that the rest of the computations will return the correct values.
Now, I need add more tests to test all the boundaries of those inputs and make sure they are all producing the correct result. Then I will look at the procedural input and try to break that and impose similar rules.
Since this is all fixed point stuff, creating any shape with a width of 1, would return a cube. In addition, any sort of tessellation values would need to be limited by the distance between the sample points it could possible produce.
So, as with any good software that is out there. It imposes restriction on what you can possibly do so that the system can ensure you can do it correctly. That is basically how games work as well. A humble set of rules and restriction that you have to follow to be able to solve your problems within their domain.
V 