BSP's still in use?
Author
I was reading a thread in Yann L's greatest hits about BSP's and a lot of people said that BSP's are outdated and the only reason they are still in commercial engines is because it is to help integrate with an existing code base.
Now my engine development teacher says that BSP's arn't outdated and thats just one mans opinion. Commercial games such as Doom3 and unreal are still using it so its still a viable topic to cover.
So whats the deal on BSP's?
Quote:Original post by ph33r
Commercial games such as Doom3
Doom 3 doesn't use BSP's for scene culling/representation, it uses portals. They may use BSP's in other areas, but for standard geometry culling ( aka Q1-3 ) they don't, they aren't the best approach to use these days.
Author
Quote:Original post by python_regious
They may use BSP's in other areas, but for standard geometry culling
So they still are using BSP's in there engine?
Exactly what do they use it for?
Quote:Original post by ph33rQuote:Original post by python_regious
They may use BSP's in other areas, but for standard geometry culling
So they still are using BSP's in there engine?
Exactly what do they use it for?
I've no idea, but it's possible. BSP's still have their uses in some areas, perhaps someone can give some real-world examples...
There is some point you might be missing while talking about BSPs.
BSPs are not outdated for stuff like collision detection on static geometry - they work very well here.
BSPs are no longer good struture to hold your geometry for rendering using modern 3d cards. The main reasons for this are:
1. BSP is static. If your world changes, you wouldn't really want to rebuild it, because BSP construction is rather expensive - it operates on single triangles, not bounding boxes, etc.
2. BSP produces quite a lot of extra faces because of its strict partitioning nature.
3. BSP requires you to split your mesh (usually consisting of hundreds or thousands of triangles) into separate sub-meshes. Splitting single mesh into several ones adds overhead for low-level graphics API state changes. These days you don't want to care about rendering few triangles less, because hardware will not notice it. What you want to care about is to send as few geometry batches to your low-level API as possible.
Besides, it's very inconvenient to handle one mesh as multiple sub-meshes from programmer's point of view. Added that it's less effective to render, no one being serious about efficiency will go for it nowadays.
So, in context of real-time graphics based on modern hardware BSPs are not a good choice. There are still uses which make BSP use practical though.
BSPs are not outdated for stuff like collision detection on static geometry - they work very well here.
BSPs are no longer good struture to hold your geometry for rendering using modern 3d cards. The main reasons for this are:
1. BSP is static. If your world changes, you wouldn't really want to rebuild it, because BSP construction is rather expensive - it operates on single triangles, not bounding boxes, etc.
2. BSP produces quite a lot of extra faces because of its strict partitioning nature.
3. BSP requires you to split your mesh (usually consisting of hundreds or thousands of triangles) into separate sub-meshes. Splitting single mesh into several ones adds overhead for low-level graphics API state changes. These days you don't want to care about rendering few triangles less, because hardware will not notice it. What you want to care about is to send as few geometry batches to your low-level API as possible.
Besides, it's very inconvenient to handle one mesh as multiple sub-meshes from programmer's point of view. Added that it's less effective to render, no one being serious about efficiency will go for it nowadays.
So, in context of real-time graphics based on modern hardware BSPs are not a good choice. There are still uses which make BSP use practical though.
BSPs haven't been used for visibility culling in any recent generation game (including Quake 1, 2, 3 or Doom. Q1-3 uses PVS, a pre-calculated per-leaf-based system, with the BSP only used to define, and accelerate finding, the leaf. )
BSPs remain usefull for collision querries. It's also a pretty good representation of the CSG nature of many FPS engines (such as Unreal).
Allan
BSPs remain usefull for collision querries. It's also a pretty good representation of the CSG nature of many FPS engines (such as Unreal).
Allan
Quote:Original post by __ODIN__
BSPs haven't been used for visibility culling in any recent generation game (including Quake 1, 2, 3 or Doom. Q1-3 uses PVS, a pre-calculated per-leaf-based system, with the BSP only used to define, and accelerate finding, the leaf. )
BSPs remain usefull for collision querries. It's also a pretty good representation of the CSG nature of many FPS engines (such as Unreal).
Allan
I think you're mixing up hidden surface removal and visibility detection.
Quote:Original post by __ODIN__
BSPs haven't been used for visibility culling in any recent generation game (including Quake 1, 2, 3 or Doom.
BSP is used in Half Life 2, in almost the exact same way that it was used in Quake 1. Sure a lot has been expanded on, but the core methods and algorithms remain the same. Precalculated lighting with entities encoded for calculating dynamic lighting during runtime, a complete PVS calculated beforehand, everything is a convex hull, etc.
Hell, even the cubemaps are rendered beforehand into the BSP file.
Quote:Original post by PromitQuote:Original post by __ODIN__
BSPs haven't been used for visibility culling in any recent generation game (including Quake 1, 2, 3 or Doom.
BSP is used in Half Life 2, in almost the exact same way that it was used in Quake 1. Sure a lot has been expanded on, but the core methods and algorithms remain the same. Precalculated lighting with entities encoded for calculating dynamic lighting during runtime, a complete PVS calculated beforehand, everything is a convex hull, etc.
Hell, even the cubemaps are rendered beforehand into the BSP file.
I really doubt that HL2 uses BSPs _for rendering_. Precalculated lighting, PVS, convex hulls...none of that stuff you mentioned necessarily means that they use BSPs for rendering - as in actually traversing the BSP in order to know which tris to draw, or anything related to that. That would be crazy in a modern engine, for reasons which MickeyMouse explained.
And what do you mean by "everything is a convex hull"? Obviously everything is not a convex hull...maybe some things are represented by convex hulls for collision, but that's not rendering.
Some engines, quake 3 for one, use a file named .bsp to store level geometry in. This is mostly a historical artifact; although the file does contain bsp data, it is generally just used for collision queries, and portals are used for the actual visibility determination. I bet HL2 uses portals, sharing as it does a lot of heritage with quake.
IMO PVS is not really a good solution compared to portals, because it is not view dependent, and I also doubt that HL2 uses PVS for HSR. Although I don't know for sure, and I could be wrong.
As previous posters said, BSP is still really good for some collision stuff (ray casts especially) and still used for those things.
Doom 3 uses KD-Trees (axis aligned BSP trees) for collision detection. Also when you compile a doom 3 map, the console says stuff about BSP. It may also use a BSP tree for figuring out which surfaces belong to which area that are separated by portals. In the doom 3 .proc files there is a section about nodes which has two numbers which are children indices. When rendering a doom 3 map, finding which area you are in goes something like this:
So obviously there is some kind of tree used to determine the player location. This is very similar to how you find a player location using a quake 3 bsp. So yep, doom 3 uses BSPs in some ways.
-SirKnight
int GetArea( vec3_t cam ){ int node = 0; do { if( PointIsInFront( map_nodes[node].plane, cam ) ) node = map_nodes[node].children[0]; else node = map_nodes[node].children[1]; } while( node > 0 ); if( !node ) return -1; return ~node;}So obviously there is some kind of tree used to determine the player location. This is very similar to how you find a player location using a quake 3 bsp. So yep, doom 3 uses BSPs in some ways.
-SirKnight
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
