   Why are BSPs and PVS techniques not advisable nowadays?
  I always hear people say that you shouldnt be using BSP and PVS techniques nowadays. Now I understand that they were created for a time where rendering one polygon made a difference or something, but now, will using these techniques limit me in any way? or are other techniques just more "cool" or something?Why do people say this exactly?Thanks again! 
  PVS techniques you most definitely should be using, but the BSP technique (or at least, the most ''popular'' application of it) was created for a time when hardware Z-buffering was pretty poorly supported.That''s not true any more, so it becomes better to use more up to date techniques. ;  Its not that you shouldn''t be using BSP trees, but that you shouldn''t be touching individual polygons each frame - which is what a BSP tree implies due to its very nature. I think the best approach is to abstract to such a level that you can easily replace the BSP tree with another tree type with no change to the interface i.e. define a standard interface which every tree type can support then you can support dynamic changes between different tree types.James ;  A lot of it has less to do with anything that happens in realtime and more to do with tools and preprocess.  Doing BSP\PVS on millions of polygons isn't very practical.  Engines that use BSP (Unreal for example) tend to use a lot of detail meshes that can be rendered quickly and instanced.  PVS doesn't have any performance benefits over artist placed portals and those are becoming the standard in modern FPS engines. Many games also have outdoor components, if not being entirely outdoors. BSP and PVS is useless is wide open natural settings and impractical for cities.  These types of games get more performance benefits from LOD and\or occlusion culling than they do from PVS. There are games out there built on BSP\PVS engines with wide open levels (Call of Duty and Medal of Honor built on Q3A) and these guys ran into problems with it (artists were manually editing the PVS.)  There was a good discussion on the gd algorithms mailing list called portal vs pvs that talked about a lot of this stuff. You can look at the archives at http://sourceforge.net/mailarchive/forum.php?forum_id=6188, but they appear to be broken unfortuanately. Finally, PVS is very rigid. Occlusion culling is nice because in theory it works with any kind of geometry dynamic and static and requires very little preprocessing if any at all. Even portals are a lot more flexible than PVS. Polygon aligned BSP trees are still useful for somethings, especially collision detection, but they don't give you a huge benefit over other more flexible data structures.  A lot of games out there are still using BSP in some form (Doom III, Halo, Halo 2, HL2, most Unreal Engine games, etc.)  Half Life 2 still makes use of a Quake style BSP\PVS system, even though they have more general purpose occlusion culling for outdoor areas.   [edited by - impossible on February 12, 2004 3:30:48 PM];  transformation:it is better to explain that the bsp you mean is a quake style bsp,so a polygon aligned bsp.The Axes Aligned bsp is still new! In particular that technique such as loose bps (here is named ABT bye is "inventor") is interesting!bye davide ;  Reasons in addition to those above include:1. When a dividing plane intersects a polygon it chop the polygon into at least two polygons. In a level with milions of polygons this turns millions in to many many more milions of polygons (slow and wasteful)2. In large levels the tree becomes very deep and therefore slow to traverse.3. The BSP encloses all the space in the level, even empty space with no polygons.;  thanks for the replies so far, however, still confused. If I understand this correctly, the reasons why BSP shouldnt be used is because:1) On large levels it has a very high memory foot print2) It''s useless for outside and cities (Do you mean useless or that there are better methods but BSP will still work fine)3) It takes a million polygon scene and turns it into a 2 milion polygon scene4) Too much preprocessing involved (is it really that much preprocessing that its so unbearable?)5) (Any missing? or any extra?)Now It''s still not clear whether to use PVS or not. PVS is just a list of nodes visible from the current node yes? So it would be good to use. quote:PVS doesn''t have any performance benefits over artist placed portals and those are becoming the standard in modern FPS engines. So PVS should still be used. Portals can be used instead but there''s nothing wrong with using PVS, or are there specific reasons like the ones mentioned for BSPsquote:artists were manually editing the PVS.huh? I though PVS was determined in a preprocessing step in the program itself? Cause the PVS depends on the BSP right? Like in each node, you have a list of nodes visible from it. ie the visibility set.quote:I think the best approach is to abstract to such a level that you can easily replace the BSP tree with another tree type with no change to the interface i.e. define a standard interface which every tree type can support then you can support dynamic changes between different tree types.This sounds very intresting. Have you done this or tested any  system? If you have, could you maybe elaborate a bit on it?Thanks a lot for your replies.(incase you havent figures it out, its me transformation, lost me password, just hit the forgot password linky) ;quote:Original post by Anonymous Poster  quote:artists were manually editing the PVS.huh? I though PVS was determined in a preprocessing step in the program itself? Cause the PVS depends on the BSP right? Like in each node, you have a list of nodes visible from it. ie the visibility set.PVS doesn''t necessarily have anything to do with BSP; if anything BSP can just be used as a utility to generate an initial PVS that you then tweak.If you''ve got complex geometry in a cluster, or you''re using things like alpha textures to get greater detail, then it becomes practically impossible to generate a full accurate PVS. What you''d have to do is something like render the level from every possible camera position, recording cluster ID numbers into the stencil buffer, then scan the results and see which clusters are actually visible. You''d then be able to kill alpha-transparent pixels, but you''d have to pick a higher resolution to run in than the game itself will ever let the players use, and you''d have to leave it for a couple of months to run the process...A much more effective technique, that I myself have used, is to have the artists run around the level, and record which clusters are visible and which are not as they go. For example, you could turn off all culling, draw clusters within the current PVS in regular colors, and clusters not in the current PVS in a different color. If that different color can ever be seen, then the sector producing it can be seen and should be added to the PVS. ;quote:Original post by Anonymous Poster  quote:PVS doesn''t have any performance benefits over artist placed portals and those are becoming the standard in modern FPS engines. So PVS should still be used. Portals can be used instead but there''s nothing wrong with using PVS, or are there specific reasons like the ones mentioned for BSPsThe major disadvantage of using a precalculated PVS over more dynamic methods (Portals, Occlusion culling, etc.) is the PVS is "set in stone."  If your level changes in a dynamic way you can''t really use PVS.  Even games with a PVS (Quake III) use portal techniques that take into consideration things like doors closing and allow you to do some portal special effects (like mirrors.) ;  BSP trees are still a great option IMHO. there are some misconceptions floating around.Sure in the days of Doom 1 every leaf had only polygon, and adding a node would split up a lot of leafs; but today every leaf will contain thousands of polygons. This is because in the days of Doom1 rendering a single polygon was very expensive, but today not so.So you might be saying "why not use octrees then". well octrees are ok but they dont support occlusion queries as well as bsp trees do. for example to send an occlusion query to see if something is visible, you want to draw the geometry closest to you first, send the query, and get the result. with a bsp tree you can see which of the 2 possible sub nodes are closer by a very simple if statement. with octrees you have to sort all 8 sub nodes closest first. 