Major bug located in my triangle-splitting implementation.
My algorithm for finding the intersection of a line segment (ie 'edge') and a plane expects the two endpoints of the line segments to be handed in a particular order, which I was not observing in all cases.
The result was that some child triangles were being created with incorrectly interpolated vertices, directly leading to them being incorrectly classified in subsequent iterations of the tree generating algorithm.
I hope I fixed all the cases, I will check them over today. I don't want to continue to examining the portal generator output until I am absolutely convinced that the tree is correct.
This brings me to a small point of contention.
The surface normals for some of my planes are being returned as 0.99999994 rather than 1.0 , and although this inaccuracy might seem acceptable given my planar tolerance of +/- 0.005, rounding errors such as this quickly add up over several recursive iterations - and especially so when we are bisecting space !!!
Should I be clamping normals to 0 and 1 when they are very close to being so? This assumes that there is much orthogonality in the 3D world, which I guess is a common scenario, even today. But given that I expect to handle organic shapes too, is clamping a good idea?
The fact that my Normal is not always exactly unit length for a plane aligned to a Major Axis is a bit of a concern.
What would you do?