Skip to main content
gamedev.net
🔒 Locked

Terrain PVS/Quadtree

Started by schupf 1 reply 1k views
Original Post
schupf
schupf
Hi, two little questions about PVS and Quadtrees in the context of terrain rendering: 1) Does a quadtree have any performance advantages while rendering a terrain (lets say 512*512 vertices) if the Vertex shader is trivial (in the most extreme case just a passthrough vertex shader). The only purpose of a quadtree is to reduce the vertex count sent to the gpu - but what if the vertex processing is really cheap cause of a trivial vertex shader? 2) I wanted to implement PVS for my terrain. If the camera is always low on the ground (lets say 0 to 100meters) then I thought about this algorithm: I divide the terrain into patches (maybe 32*32) and compute for all patches which patches are visible. Lets say I want to calculate which patches are visible from the patch N, then I create a bounding box with height 100 (max cam height = worst case) for patch N and shot a ray for all 4 top corner points of the bounding box to all 4 top corner points of all bounding boxes of the other patches. This is a worst case scenario test and if you know any better algorithm please tell me! But the problem is: the algorithm doesnt work if the user can fly up as high as he wants. Is there any way to make PVS work with a camera that isnt bound to the ground?
RobM
RobM
A quadtree definitely has performance advantages regardless of whether your vertex processing is cheap or expensive. If you don't use a quadtree (or some kind of spacial partioning, octtree, etc), you'll undoubtedly be sending vertices to the gpu that are required.

As your terrain is relatively small, there's probably a chance you'll get a speed DEcrease because of the extra Draw calls, but if your application is destined for very low performance video cards as well as high, it's worth implementing a simple quadtree. You can always implement it regardless and just decide at which node to draw based on the current hardware. That would be a scalable approach and would allow you to increase your terrain size easily.

I'm going to implement PVS in my terrain engine and my thoughts are exactly as yours are. If you create a quadtree for your terrain, then you'll get the PVS bounding boxes for free. In my app, the user won't be able to go any higher than 20 feet or so above the bounding box of a patch, but if it does, I'll just disregard the PVS information.

There is another potential visibility algorithm you can add which is based on a cone of visibility. I can't remember the specifics but it essentially allows you to avoid rendering entire patches if all of its normals are facing away from you - so if you're on one side of a mountain, you don't need to render the other side because not one of its triangles is facing you. This is precalculated into an irregular cone per terrain patch which contains the maximum (or minimum) slope from any particular viewpoint.

Saying that, if you're aiming at high-end cards and you're not going to need any more than 512x512, I'd go for the brute force approach.

Hope that helps
paic
paic
Just a quick note on your PVS algorithm : it won't work for all scenarii. Imagine a terrain with lots of peaks and now imagine two nodes where there is a peak between each of the bounding boxes' corners, but nothing in-between.
It won't be visible by your algorithm although obviously it is.

Try looking for existing PVS algorithms, this problem is explained a lot better.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.