#### Archived

This topic is now archived and is closed to further replies.

# PVS for heightfields

This topic is 6439 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Spent a few moments working out a way of working out what polygons are visible from a heightfield (an array of heights with no overhangs). I noticed people saying how wonderful roam and oct/quadtrees etc are - and can''t quite see the benefit when using heightfields. my idea - you know where on the heightfield you are (P) and which way you are looking (V). you can draw (this was done on paper, in theory) a triangle with one point at P and bisected by V. work out the intersects of the two lines extending from P and the edges of your map (assuming it''s finite, if not, it''s not a problem - at some arbitrary maximum distance, you will have a line joining the end points of those two lines - which is extendable to do LOD too). work out the start and stop point for each raster line of the triangle - ie, as if you were to draw it on the screen. but rather than drawing it, you use it to reference the height map. so a quick scan across the map for each line will give you a visible point. any point contained in the intersection of the triangle''s area and the heightmap''s area is a visible point. to do LOD, you could have the two sides of the triangle extending from P only go a fixed distance, with the third side being the limit of that LOD. the next area will be a trapezoid (clipped by the map if it''s finite) and so on. I''m not too good at explaining it. i could try and write an explanation with graphics sometime if people want. my point is - this method uses fast integer iterations to work out the PVS, without needing to store your data as anything but a heightfield. is this going to be faster or slower and more or less efficient than any of the other methods out there (for a heightfield) ? Wyzfen

##### Share on other sites
There is a thread at flipcode about this, one of the image of the day was created with a method like it. It was a couple of day''s ago.

Anyway, the frustrum culling shouldnt have large overhead computationally however you implement it. Storage is an issue, but since you want to be able to use static vertex buffers you dont have much choice...

When I read PVS I thought you were going to explain a good occlusion culling method for landscapes

##### Share on other sites
I would say that this method would be slower in fact than using the transformed values you get from a ROAM tri-tree. You would still have to transform all the heightfield points into triangles and project them into worldspace, so for each frame you would not only have to determine visibility but also transform the visible heightfield into something you can feed the rasterizer. I guess it could be faster in some ways...perhaps you could pair this approach with a quadtree method, where you can quickly do integer calculations on the visible landscape trapezoid and then taking the lines that compose the edges of that trapezoid and usign them in the quadtree calculations.

Of course I haven''t done any of this myself, so the above might be mindless rambling.

• 10
• 48
• 12
• 10
• 10
• ### Forum Statistics

• Total Topics
631382
• Total Posts
2999679
×