I've decided to spend a few hours hardening the current codebase through a series of exhaustive tests apon the triangle splitting code in the tree generator - I seem to be getting unreliable results for some reason (occasionally the output is not the same) and I need to understand why this is so.

I've been thinking about changing my Triangle class in the bsp tree gen too - and you haven't even seen it yet.
Looks like this:

// Defines a renderable triangle during tree generation
class Triangle
{
public:
Triangle(int iOrig, int iA, int iB, int iC):iOriginalIndex(iOrig), ivA(iA),ivB(iB),ivC(iC) { }
~Triangle() {};
// Vertex Indices
int ivA, ivB, ivC;
// Index of original triangle (since this triangle may have been 'fragmented' during tree generation)
int iOriginalIndex;
D3DXVECTOR4 Plane;
};


As you can see, each Triangle records its own Plane, this eliminates looking up the plane at runtime, a trivial optimization of a frequently performed lookup operation, which adds up quickly to provide a nice overall speedup.
Now, even though I am providing the plane for each triangle explicitly, the code for selecting a partitioning plane seems unreasonably slow (maybe its just my ASM background)... I am considering either replacing the vertex indices with pointers directly to the vertices, or just keeping the vertices in the triangles themselves. Either would effectively eliminate vertex lookups during the extremely cpu intensive task of selecting a partitioning plane. It also means I never have to record any geometric data that was generated solely due to splitting visible triangles (except within the triangles themselves) - I can leave my VBs and IBs alone.