Jump to content
  • Advertisement
Sign in to follow this  
iosys

Quadtree + PVS

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

To start off, I'm just using PVS as a term for exactly what it is, a potentially visible set. I don't really know what's stored in them in the standard BSP/Quake games. I'm searching for a way to handle static world geometry with multiple textures, indoor or outdoor with no special cases, where a Quadtree + PVS might work. Here's the basic idea: Each leaf in the quadtree has a PVS. The PVS stores: a) a list of every face that is potentially visible from the current leaf. b) a list of every leaf that is potentially visible from the current leaf. Build an array of vertices from (a). Make a vertex buffer from this array. For each texture used in (a), build an array of vertices. Make an index buffer from each of these arrays. Keep every vertex buffer based on (b) in memory. These might have to be loaded over multiple frames to keep FPS from dropping when the camera enters a new leaf in the tree. Unload vertex buffers that no longer reside in (b). Set the vertex buffer and loop through each index buffer changing the texture accordingly. One major factor is the size of a leaf (which can be adjusted to best performance during design). Just about all of this can be precomputed, allowing for static buffers which should give speed increases. Normally I would just code something in and test it out, but this seems to be a big task and I don't want to waste time on it if there's a fatal flaw I come across down the road. Please comment on this. If there are other ways of doing this similar task, feel free to mention them. Thank you.

Share this post


Link to post
Share on other sites
Advertisement
Sorry for the late reply, I just remembered this thread [smile].

This sounds like a technique I was considering implementing a little while ago, as a result of my occlusion culling article. I never actually did it, because I figured it was overkill. Usually, a well-constructed octree routine can successfuly cull a scene with minimal overdraw. Also, PVS data can take up a lot of file space and memory (and since you are already going to have to implement a quadtree, it may not help that much). The tough part, of course, is creating a system that works for both indoor and outdoor environments [wink]

Share this post


Link to post
Share on other sites
I actually did implement just about the same idear, however I only did step b), that is in every leaf I had a pointer to a visible array, say bool *pPVS, hence when drawing:

//stand in leaf with some ID
Loop through octree leafs
if (octreeLeaf in Frustrum)
{
If (octreeLeaf->pPVS[ID])
render(..)
:
}
else //recursive further ..

The problem was mainly making the pvs array for each leaf, since it took a bit of time tracing through the scene making a correct pvs array in all positions.

Well, right now I’m trying the software-occlusion HOM approach, but I doubt it will be faster ... but more general I think!





Share this post


Link to post
Share on other sites
Quote:
Original post by Mille
Well, right now I’m trying the software-occlusion HOM approach, but I doubt it will be faster ... but more general I think!
Awesome - keep us posted on how that turns out. It may be faster, depending on how optimized your routines are. And it's *definetly* a better system for both indoor and outdoor worlds.

Share this post


Link to post
Share on other sites
Quote:
Original post by circlesoft
Awesome - keep us posted on how that turns out. It may be faster, depending on how optimized your routines are. And it's *definetly* a better system for both indoor and outdoor worlds.


Sure :) I've also tried the occlusion query extension (similarly to one of your tutorials), and actually is was also quit fast if you do NOT update the query each frame. However, the leafs has to consist of many primes, at least 1000 triangles I would say, but again, depends on the scene, hardware etc ..

But as I learned from Yann, the query can introduce bubbles, so why not try a CPU HOM implementation .. hell, its fun trying different approaches anyway - and I have all the time in the world




Share this post


Link to post
Share on other sites
Guys thanks for the replies; I thought this post was dead :)

This could also work with a grid system instead of tree. I'll do an estimation on how much memory this system would take up because I'm all for sacrificing memory for speed, but that brings up some newb questions: If a vertex buffer is over 32mb will a 32mb video card have trouble with it? Is there a guideline for how much data to send to the video card depending on it's onboard memory?

Thanks again, and I'll check out these occlusion techniques also.

Share this post


Link to post
Share on other sites
Quote:
Original post by iosys
If a vertex buffer is over 32mb will a 32mb video card have trouble with it? Is there a guideline for how much data to send to the video card depending on it's onboard memory?
Considering that you only have 32mb of video memory, yes. As a guideline, the optimal vertex buffer size is 3-4 mb - no matter how much video memory the card has. This spec is from an excellent Nvidia presentation on batching.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!