Talk:BSP (file format)

This is the talk page of a redirect that targets the page:
• .bsp
Because this page is not frequently watched, present and future discussions, edit requests and requested moves should take place at:
• Talk:.bsp

Video games

This redirect is within the scope of WikiProject Video games, a collaborative effort to improve the coverage of video games on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Video gamesWikipedia:WikiProject Video gamesTemplate:WikiProject Video gamesvideo game articles

Summary of Video games WikiProject open tasks:

Summary of Video games WikiProject open tasks

AfDs

Train simulator (disambiguation) (3 participants)
Preston Arsement (2 participants)
Jackpot World (1 participant)
Bejeweled Stars (5 participants)
Melee (game terminology) (5 participants)
Godzilla: Monster of Monsters (5 participants; relisted)
Godzilla 2: War of the Monsters (5 participants; relisted)
Crazy Bus (14 participants; relisted)

Merge discussions

Other discussions

No major discussions

Untitled

I disagree with "A .BSP file includes everything in the map, except the textures (with the exception of Half-Life, BSP version 30), ". I think that BSP-files for Quake I DO contain all the textures for that map. —Preceding unsigned comment added by 91.35.185.207 (talk) 10:11, 1 November 2007 (UTC)[reply]

Removed reference to Doom from the first paragraph, as none of these games (except for perhaps Doom 3) use the .BSP format for maps. 213.105.95.254 (talk) 09:37, 29 November 2009 (UTC)[reply]

Inaccuracies?

The opening paragraph seems a little inaccurate:

"BSP files use binary space partitioning to generate levels that can be rendered quickly while minimizing the number of polygons that need to be redrawn every time the screen refreshes."

Actually the BSP isn't directly used to cull the rendering - which seems to be a common error - perhaps because it can be used to minimise overdraw by drawing from front to back - but is used to lookup the current leaf or cluster that a point is in, or the set of leaves and clusters an AABB overlaps, etc.

The PVS data is used for the render culling, which groups BSP leaves into clusters which contain a list of which other clusters are visible to them. The BSP tree is used to generate this since it provides well behaved data (convex regions) that makes the PVS data easier to calculate. This is not unique to BSP trees or BSP files and the infact PVS data need not actually be included to create a valid BSP file... try compiling with novis in Radiant or whatever to see what I mean.

Also whats up with "minimizing the number of polygons that need to be redrawn every time the screen refreshes"? Its pretty wordy - how about: "minimising the number of polygons drawn".

"One of the biggest problems with the .BSP file format is that large open areas do not work well due to the nature of the partitioning algorithm used."

This has nothing to do with the BSP format or the BSP tree data structure, which has similar lookup complexity to any other binary lookup tree - O(log n). I suspect this again refers to the PVS implementation, because being a large open area is precisely the same thing as being difficult to optimise the PVS. Every visibility culling algorithm suffers from this problem by default.

Jheriko (talk) 13:27, 13 April 2010 (UTC)[reply]

... in fact reading the whole thing through its littered with small errors Jheriko (talk) 13:38, 13 April 2010 (UTC)[reply]