I recently asked a question on clipped portal polygons and the resulting explosion of vertices introduced due to clipping:
http://www.gamedev.n...ustum-clipping/

The best response was to generate a bounding quad from the clipped vertices:



This turns out to not be trivial. As long as the portals are always axis aligned, this becomes trivial since I can just ignore the axis where the min/max extents are within some epsilon. The issue is that I do not want to restrict the portals to being axis aligned. Looking at the above pic, assume that the portal is rotated 45° along the y (vertical) axis. Even though the resulting projected polygon on screen is an axis aligned quad, the result from testing the minimum and maximum object space extents would yield a 3D bounding volume and not a bounding quad.

I have searched Google and this board to death, but I simply do not know what search terms I should use. All of the results that I have found are for 3D bounding volumes, not planar quads. I'm not sure how to go about this and the lack of information is making it much more difficult. Any searches dealing with calculating a bounding quad turn up methods for calculating a bounding rectangle from 2D points.

I'm hoping that someone can give me some suggestions or point me in the right direction.

[edit] Replaced "rectangle" with "quad". Rectangle implies certain geometric constraints that I was not intending to imply.

How about just projecting the 3d portals onto the view plane and THEN generating 2d axis aligned quads from the projections? Once again, a bit more conservative, but still will give you most of th benefit.

How about just projecting the 3d portals onto the view plane and THEN generating 2d axis aligned quads from the projections? Once again, a bit more conservative, but still will give you most of th benefit.

The problem with that is that a sub-frustum needs to be created from the resulting portal. I'm not sure if that would be possible with 2D projected vertices, especially since the z coordinates will be undefined. I need to do this in object space.

The depth information is implicit in the order that you traverse the cell portal graph. I.e. You first need to see through the portals of your current cell in order to see through the portals in the next cell. Mathematical induction does the rest.

No subfrustum is needed - just the refined portal in image space which should be the 2D intersection of whichever portals were traversed to get to it.

... I'm not sure if that would be possible with 2D projected vertices, especially since the z coordinates will be undefined. I need to do this in object space.

If 2 points [sub]2[/sub]A and [sub]2[/sub]B in 2D space give a 3rd point [sub]2[/sub]C due to barycentric weighting
[sub]2[/sub]A * k + [sub]2[/sub]B ( 1 - k ) = [sub]2[/sub]C
then the weight can be computed as
k = | [sub]2[/sub]C - [sub]2[/sub]B | / | [sub]2[/sub]A - [sub]2[/sub]B |
For a vanishing distance between [sub]2[/sub]A and [sub]2[/sub]B also the difference between [sub]2[/sub]C and [sub]2[/sub]B vanishes, so that a k = 0.5 may be used for numerical stability; however, it means that the portal is seen from an almost orthogonal direction and hence probably is already caught in code.

Now, [sub]2[/sub]A and [sub]2[/sub]B are assumed to be the results of projecting [sub]3[/sub]A and [sub]3[/sub]B from original 3D space. Because the points on the 3D line are projected linearly to the 2D equivalent, the same weighting factor k can be used to compute the equivalent of [sub]2[/sub]C in 3D space:
[sub]3[/sub]C := [sub]3[/sub]A * k + [sub]3[/sub]B ( 1 - k )

So reconstructing the point in object (or any other) space is possible although the intersection was computed in 2D.

The depth information is implicit in the order that you traverse the cell portal graph. I.e. You first need to see through the portals of your current cell in order to see through the portals in the next cell. Mathematical induction does the rest.

No subfrustum is needed - just the refined portal in image space which should be the 2D intersection of whichever portals were traversed to get to it.

That is brilliant! I have never heard of a screen space portal algorithm before. One thing that always bugged me about traditional portal algorithms is that I would be performing clipping on the CPU for no other purpose than to create a new frustum based on the clipped portal. Once I knew that a portal in the current cell is visible, I would send the entirety of the current cell to the GPU for processing. Since the resulting clipped portals wouldn't be used past the current frame, it seemed a waste of resources.