Visual Portal World (fmtBSP) is currently on its 10th build to date, being used for the Ocarina Engine.
However i wouldn't say that it is entirely a complex format.
The hardest part was making the Visibilty Tree, as each world you make with it is cut into Grid Squares.
So you can imagine a 3D Grid ... In each of these grid points the first byte is a binary %110000 which means there are polygons within it, this is for the Vis Beams use - from that you then have the geometry cut down into the visible sections in a similar way to early BSP.
- Branch (Grid)
-- Boolean Fill
-- Leaf (Limb Mesh Geometry)
--- Node (Visible Polygons)
each Node used to be a dual byte - dword combo, where the byte was a boolean visible or not and the dword was the index number.
to make sure it was all small enough the whole world was Gzipped.
as the actual geometry is different to the Vis Tree, then the Vis tree was actually an Array tagged onto the end of the DarkBasic Mesh Export file.
So the format was almost no different, except you'd have a second set of UV Co-ordinates for the Lightmapping ... this would mean that all you did when you reconstructed the geometry was combine the first UV Map with the cross referanced second UV Map which covered the Entire world rather than just than one face (so the map construction was face based really)
This ment that it was relatively simple to combine both.
yesterday when i noticed that i could use Binary values within DBpro i've been tinkering with actually changing the geometry to Binary bits
would save alot of space.
later on the collision would be calculated based on the Limb Mesh Geometry - so is basically extremities box based, but wasn't much of a problem ... as within the the Limb you has a first byte value to signify its type, assigned by the entity set you're using - it was a quite effective way to achieve this.
Also the vis beam would work within clear grids only.
So you'd vector a heading and check each grid, and then skip to the final grid to check.
This saves alot of calculation time over larger distances, because it isn't calculating say 6mile long Vis - it is only calculating the final block in the puzzle.
And yes using a vector to predict where it should be isn't really the most effective way - certainly kept the speed high.
i'll see what i can do for a tutorial for BSP when i have the time... becuase you'll be surprised how easi it is.
i have a new tech demo comming soon "Shaders"
Shaders, Decals and projection mapping is actually amazingly simple to do, as long as you're working as if on a small mesh - which the Visibility culling allows.
This allows you to create a single UV map for the entire model you wish to project to, and then you can simply plot and combine
Anata aru kowagaru no watashi! 
