Well, as I said, it is possible there was a problem with HTPS, and this morning, when I woke up and read the posting of my techfile it came to me. There is a possiblity, although rare that in an arrangement of occluders, we could end up marking a object invisible, that could be visible. This is because if all the edges are covered by the buffer, then it is still possible for "some" of the node to be visible. Curses, so I went back to the drawing board, rather literally in fact. It came to me while I was working in art on the design for my sculpture studio piece. I could use instead a 2d + Quad tree to instead test whole faces in nodes.
Fortunately, it is actually impossible, that I know of, for the occluded object to be visible if the tangent planes cover all the faces. Phew. But, why the hell am I thinking about this?
Well, currently, the potential set I use to ease up the load on the secondary culler works for very generic scenes, whether they be outdoor urban or suburban scenes, or indoor dungeon roaming. Unfortunately however, there is the possibility that the set ( which you can read about in "Precalculated Nice Visibility Sets" ) will not be 100% efficient for the node based potential set it builds. This is because it is possible for two occluders to occlude one node totally from the perspective of another, but they the node is not set as invisible, as each test is done singularily.
Effectively, I could have solved this by simply clipping nodes on each new tangent beam, and only testing one occluded object at a time. I don't like this method though.
So, I thought for a bit, and came up with HTPS. Unfortunately, my hopes for the system turned out to be a premature relief of anguish. So, angst ridden again, I came up with this new system, I dubbed CSS. CSS stands for Confeti Scatz System. A bit of a joke at the fact that I made up an abbreviation for a system that didn't work.
The idea is creating a set of 2d BSPS, with a quadtree which allows us quick reference to the partitioning lines. These partitioning lines occur where the tangent beam planes cut the axis aligned plane. So, effectively, on each pass in our generic potential system, we can build up a set of these axis aligned planar 2d BSPs. The quadtree comes from the fact that each face on each node in the tree must be facing a 2d bsp, so we can cross section the entire tree, and make a quadtree. Even when nodes are split partially by the system. Then, for each possibly occluded object, we insert its corresponding planes into the trees, and create them. When we insert a new beam into the bsp, we then check if any of the faces in the quadtree are now covered. As soon as a face in the quadtree is covered, we can mark it and not worry about it anymore. Once a node has all 6 of its faces marked, then the node or occluded polygon is invisible (I only test nodes). Bonza.
So, for each possibly occluded node, we insert the tangent planes between it and its occluders into the 2d bsps. When we move onto the next possibly occluded node, we can start again. By doing this, in the right order, we can efficiently compute an more efficient potential set.
There is another bonus of this set, that I have not mentioned. If you wish, you can allow the plane of the quadtree to go through a node without being one of its faces. You still get your square in teh quadtree, but it doesn't correspond to a face. In this way, if the visibility changes, we can partition the node into two parts, one where a polygon is visible, and one where it isn't. I think this could be used at lower level nodes to again increase the level of accuracy.
This fairly simple idea allows us fast management of the entire potential set for a node rather well, and although I personally feel the data set would be too large for realtime purposes, it would be useful to generate the potential set I use. It would offer a very generic potential set, capable of handling many areas that are often not handled by a portal based pvs system well.
Another thing, not my own invention, but that of a friend, Martin Hristov, is the idea of using a mini-sbuffer within nodes to gain sorted visibility, then sending it to a global s-buffer. This means you can skip the set of the mini-bsp. How ever, in mentioning this to Phantom, he came up with the idea that you could switch between the mini-bsp and the mini-s-buffer in dealling with dynamically altered nodes. Expanding on this idea, we could allow this, with the case that we still use the pre-generated mini-bsp, but we do this to get our static polygons in s-buffer inserted order first, skipping the sorting step here. Then we can simply determine which static scans the dynamic ones lie between, and then sort only the dynamic scans. So, this way we could quickly sort scans, by using a depth list of the scans, based on the mini bsp. This would avoid the hassles of sorting all the scans.