Jump to content
  • Advertisement
Sign in to follow this  
BugSlayer

BSP tree for occlusion ++

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

I know there is lots of threads here about BSP I even see one 7 threads furuther down here. But I just need a some simple hints here..:) I am writing a simple indoor 3D engine just for fun in C# and GDI+, and I need to first find out what walls not to draw, then to draw them back to forth. I know how to set up a BSP tree and traverse it to draw from the back to the front, but how do I find out what walls are outside my FOV? Behind me or to the left or what ever? Is that what they call painters algorithm (ftp://ftp.sgi.com/other/bspfaq/faq/bspfaq.html#9.txt)? Or is that something else? If it is, is it a good way to do it, or is there an other way you would recomend for me to take away walls from my rendering queue? Thanks BugSlayer

Share this post


Link to post
Share on other sites
Advertisement
Culling -- if all the vertexes of the view frustum are on one side of the plane of a node, then the other side of the node is not in the view frustum and does not need to be drawn.

Painter's Algorithm -- this is a method of drawing polygons (back-to-front) so that they are properly obscured. Using a Z-buffer makes this unnecessary (except for polygons with transparency). In fact, when using a Z-buffer on modern hardware, polygons should be drawn front-to-back to take advantage of special hardware that rejects obscured pixels early in the pipeline.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by JohnBolton
Painter's Algorithm -- this is a method of drawing polygons (back-to-front) so that they are properly obscured. Using a Z-buffer makes this unnecessary (except for polygons with transparency). In fact, when using a Z-buffer on modern hardware, polygons should be drawn front-to-back to take advantage of special hardware that rejects obscured pixels early in the pipeline.



OK, thanks, don't think I will implement a Z-buffer right away, so will draw it back to front, and hope that it won't be too slow.


Quote:
Original post by JohnBolton
Culling -- if all the vertexes of the view frustum are on one side of the plane of a node, then the other side of the node is not in the view frustum and does not need to be drawn.


Can you elaborate a bit more on that? When you saw ALL the vertices of the view frustum, do you mean the 4 vertices for the near plane, and the 4 for the far plane, so in total all 8 of them?

And what do you mean by "plane of a node". A node is a wall? and the plane is the red line on this picture for the "node" C?

figure6.gif

And what do you mean by "then the other side of the node is not in the view frustum", do you talk about the "left" and "right" leaf in the binary tree. So if all the vertices is on the left side, then discard the right leaf and all its childs?


Thanks a bunch, really appreciate if you help me out with this.

- ØØ -

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
And what do you mean by "then the other side of the node is not in the view frustum", do you talk about the "left" and "right" leaf in the binary tree. So if all the vertices is on the left side, then discard the right leaf and all its childs?


Yes. That's it. One comment about terminology -- a leaf is a node that has no children.

Share this post


Link to post
Share on other sites
OK, thanks a bunch. English is not my first langauge, so sorry for the mix up with leaf. Will try to remember that next time.

Thanks a lot
- BugSlayer -

Share this post


Link to post
Share on other sites
I have one/two more questions about this, so sorry for bumping this thread.

But the Binary tree. Is it only constructed ONCE the first time when you load the level, and after that it will never get altered? Because walls never move? And we are talking world coordinates here right?

- BS -

Share this post


Link to post
Share on other sites
yes you build in world coordinates and yes the tree is built only once for stationary objects. the bsp tree arranges objects "realative" to one another, not to any specific world space point. thus if the relative position of the objects doesn't change, there is no need for the bsptree to change.

Tim

Share this post


Link to post
Share on other sites
Thanks, I kind of got what you ment by "relatively to each other". Because they are kind of dependent on each other. The world coordinates will tell you if one object is in front or back or left or right of an other object, hence also relatively.

Yeah, you know what I mean...hmm...so I think I got you. Will give it a shot and see what I can pull off.

Thanks
- BS -

Share this post


Link to post
Share on other sites
Ooops, one more question.

I can use an AVL tree right? I guess that won't mess up anyting? At least I guess it will give me an overall better performance, since all the balancing will be done at load time.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!