Jump to content
  • Advertisement

Archived

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

Maitrek

BSP Tree HSR

This topic is 6924 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

Okay - I admit HSR isn''t a really decent acronym, I just wanted to keep the title short. What I need to know is if there is anyone out there who might be able to point me to someplace that describes how to do Binary Space Partition tree hidden surface removal in good detail. Everyplace I go just says something about traversing the tree from back to front, which is just fine, but I don''t see how that really helps. I''m not a complete simpleton, I''m just not really up to the task of rediscovering the entire theory to BSP trees all on my own when it took three uni profs to do it in the first place.

Share this post


Link to post
Share on other sites
Advertisement
Oh and by the way, I know how to construct a BSP and sort it to do back to front rendering - so I have a little knowledge.

Share this post


Link to post
Share on other sites
well, you end up sorting the polygons in back to front order by traversing the tree.. the HSR is basically painters algorithm here.. the polys that are closer to you are drawn over the polys that are farther from you in the correct order..

-goltrpoat



--
Float like a butterfly, bite like a crocodile.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Do you want to achieve 0 overdraw? Or do you simply want items rendered in the correct order? You can let the hardware do it ( Z-Buffer ), but is slow. As others have stated, simple back to front rendering of a BSP will render the correct scene, with proper Z ordering. If you want to try to eliminate overdraw, then read Abrash''s articles on how they did it in Quake. One place to find it is in the recent articles he released.

Share this post


Link to post
Share on other sites
there are two reasons why you would want to eliminate overdraw:

1) software rasterizers (obvious speed issue)

2) dynamic shadowmap calculations

with hardware zbuffer, speed is barely if at all affected by overdraw. if your engine''s bottleneck is the system mem-card mem transfer, more power to ya, but for most people that''s not the case.



--
Float like a butterfly, bite like a crocodile.

Share this post


Link to post
Share on other sites
Actually overdraw is still a major bottleneck with hardware z-buffer. If you fill the screen 4 times it will be 4 times slower than filling the screen once.

Consider a game such as Quake3 that use shaders, i.e. 3-4 layers of textures, if this game had an overdraw of 4 per pixel in average it would actually fill the screen 3*4 = 12 times which is a lot.

Even with future cards with much higher fillrate than todays that bandwidth can be used for much better things than overdraw, for example FSAA.



- WitchLord

Share this post


Link to post
Share on other sites
Thanks - most likely I''ll use the span-buffer/BSP traversal algorithm that Abrash rambles on about for the DOS part, but I''m not sure how useful BSP trees will be in a opengl version of the engine that I''m working on. I guess there is a way to disable the z-buffer testing and I can use painters and that might speed things up. Whatever.
Thanks I got the idea now!

Share this post


Link to post
Share on other sites

  • 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!