Hidden Surface Removal

Hidden Surface Removal
Author: Samuel Ranta-Eskola
Description: The article describes how to remove surfaces that are not visible with portal rendering. It also contains a detailed set of algorithms for implementing such hidden surface removal techniques.

Post a reply to ask a question or discuss the topic.

How complex would it be to create a C# example from this code or would I need to get one of the books? Are there any C# examples out there?

Thanks

If you know C# it shouldn't be too bad, C# doesn't lack anything needed to impliment it.

It appears that line 5 in the pseudo-code for DISTRIBUTE-SAMPLE-POINTS is incorrect and should be removed.

Discussion or pseudo-code for DISTRIBUTE-POINTS would be appreciated. For a large map the set of points for the root node could easily exceed 500 million, and that is using a course granularity that could miss small windows / portals between nodes.

I'm curious what granularity was actually used, and if it was attenuated based on the size of the bounding box of for the node.

Dan East

Hi Dan

Sorry that my reply was so late. The distribute sample points sux. If I might say so

Due to time issuses when I developed my thesis I didn't have time to create a more complex solution.

A bettter way to go is to create a volume between the two opening and then reduce it every time it passes through a polygon. If there are anything left when it arrives at the target opening it should be considered as visible.

About the sphere-frustum intersection test: although an exact test is not needed (false positives are ok, false negatives obviously not), a simple set of plane-sphere tests can be quite inaccurate when working with large spheres, due to the corner problem. If you draw a large sphere outside the frustum but near one of it's corners, the sphere can actually intersect multiple planes while it doesn't even nearly intersect the frustum. This is especially true for sharp corners, which view frustums tend to have after being clipped by multiple portals.

I'm currently working on culling and portal rendering for our upcoming engine, and this seems to be a major problem since we use large spheres as the bounding volumes for lights in order to test whether or not to draw the light or it's shadows on an entity. And to make it worse, lighting and shadowing are exactly the things that cost the most on the rendering side, so it pays to have a more accurate but slightly slower intersection algorithm .

But since we're nowhere near the optimization phase right now, I haven't looked into a better algorithm yet, although I do have some thoughts I need to work out. But I recon that won't be any time soon . A quick'n'dirty solution would be to add helper planes around those edges that are too sharp.

A solution to this problem can be to test the bounding volumes againist the frustum planes in the conventional way, then test those who passed, again, but now against a bounding volume built around the frustum. In .oisyn's case for example sphere vs OBB(built from the 8 corners of the frustum). The second test is more expensive, but in most cases we already eliminated most of the objects with the first swipe. Kind of a 2-pass VFC.

Again, the possibility of these invalid passes are slim, so the second pass might only be neeeded in cases again like .oisyn's, where even one invalid invalid failure can bring a lot of extra computation.