Archived

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

tres

Is BSP dead ?

Recommended Posts

BSP can be used in combination with other, more powerful storage and rendering techniques quite successfully in certain places, but all by itself it won''t hold up for big, complex, outdoor, etc., geometry. People want something better-looking than Quake levels nowadays

Share this post


Link to post
Share on other sites
I was refering to hidden surface removal, etc.

I was reading a doc on how modern cards ( ie. GeForce4 ) does this already. Or is the article wrong ?

If not a BSP tree then what other systems are there for cutting down the amount of non-visable polys ?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Yes, BSP and hidden surface removal are very different things.
BSP is used to segment a level into different areas such as corridors or rooms so that only the areas in the level that need to be rendered are rendered, and hidden surface removal is used so that any surfaces that are obscured by other surfaces when looking through the players camera are not needlessly rendered.

Luke

Share this post


Link to post
Share on other sites
If you not drawing no visable polys are you going to get a performance increase ?

Also it would seem that if you are reducing the amount of polys using a BSP tree there would be a lot less geometry to do you calculations against ( texturing, collision, etc. )

Share this post


Link to post
Share on other sites
Well, now what you''re saying sounds like it invloves using a bsp tree in conjuction with some kind of hidden surface removal system. The bsp tree itself doesn''t remove hidden sufaces, it just tells where they are.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
the bsp tree will prevent you from sending ALL of the data to the renderer, thereby avoiding every single polygon being depth tested for rendering. By only sending a few polygons to the renderer before hand, the rendering device has to make much fewer depth tests for displaying. In other words, before you send your poly''s to the graphics card, you pre sort the scene and chop out the obviously invisible parts, like behind you, to the right and left, that way all the data isnt sent to the card, just the parts you KNOW need to be tested and rendered.

Share this post


Link to post
Share on other sites
As a collision detection algorthm, BSP is dead. For graphics rendering, its still kicking. Its just very convinent to break up indoor levels using BSP. The walls become your splitting planes.

Although to split a level, you may have to use Marching Cubes, which is patented(i.e. you''ll have to pay to use it), or one of its alternatives, which takes a lot longer...

Share this post


Link to post
Share on other sites
I have made a simple level consisting of three buildings with a plane object underneath. I converted this geometry to an .x file and opened it up in my application.

From what I am reading here I can only assume that my approach is all wrong. Because given the .x model I am using for my level I can''t see anyway of breaking up it''s geometry into individual pieces for culling.

Unless I am missing something in DirectX that allows me to cull the .x model I am rendering.

I would be better off taking my level and saving it as a BSP tree so I could cull geometry that isn''t in the viewing frustum. Leaving less geometry to work with during collision detection, depth testing...



Share this post


Link to post
Share on other sites
I''m interested in developing me own space partitioning format which works with well with terrain, what articles or tutorials should I read up on? Are there any specific ones which are worth mentioning?

Also, I have a terrain engine which uses quadtrees. I would like to have a system which allows me to have indoor areas on the terrain as well. Sort of like, you''re out on a terrain and then you walk into a building and its as if you''re playing in a half-life level or something. I suppose this would be similar to the game Tribes 2 (though I''m only guessing, I''ve never played it.)

Share this post


Link to post
Share on other sites
actually bsp makes things slower because you have tons of nodes

i suggest you create vis leafs and add all polys to a segment of a very large vertex array
then do portal testing and draw the entire now whithout caring about backfacing polys ... the depth buffer will do the rest

the major slowdown in ogl apps is the glbegin glend

the less of those calls the fast the engine

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Dede said, "As a collision detection algorthm, BSP is dead. For graphics rendering, its still kicking."

Erm, I would have thought it was the other way around. What do you use to reduce the number of polys your passing to your collision detection code, then?

Share this post


Link to post
Share on other sites