View Full Version : BSP vs Portals

06-13-2001, 07:45 AM
Where an I find information about BSP culling and portal culling?

What are the advantages and disadvantages of each one?


06-13-2001, 08:41 AM
www.flipcode.com (http://www.flipcode.com) www.gamedev.net (http://www.gamedev.net)

BSP is very useful for collission stuff, but not really relevent for modern graphics hardware.

Portals are not very useful for collission, but great for gross culling (as needed by modern cards).

Quick summary: use BSP for your collission data, and portals for your PVS/rendering.

06-13-2001, 11:51 AM
if your neighbours are painting their doors with a green paint, why not choose the color which looks the best for ya??

perhaps BSP & PORTALS are not the 'real' solution http://www.opengl.org/discussion_boards/ubb/wink.gif

06-13-2001, 12:01 PM
Well, I like green... http://www.opengl.org/discussion_boards/ubb/smile.gif

06-13-2001, 12:06 PM
as u wish. http://www.opengl.org/discussion_boards/ubb/wink.gif

06-13-2001, 10:34 PM
Sylvain, what other suggestions do you have, besides portals and bsp's? occlusion? view frustum(that is done anyway)?

06-14-2001, 11:33 PM
there pretty diffrent..

MAN, i so wish linux had a good ide for software development.

it really is a pain devin'g on linux imho.

/me misses the joys of hitting cntrl-b and that little intellisense popup.


i don't know how linux developers do it..
(write big projects in linux)
just seems like such a hassle..

Tim Stirling
06-15-2001, 12:29 AM
I am using octree at the moment and as far as I can tell they seem perfect (well almost) First of all you have very fast view frustum culling and also for collision detection it will cut down the potential colliders to just the few near the collider. They are fast to build is well and can allow dynamic geomtry. Another plus is that they are very easy to code. They are also good for moddern hardware and are not anywhere near as slow as BSPs. I think you need to get with the times, the time for BSPs died out with quake, on modern hardware most of its benefits are pointless. Just because John Carmack uses them doesn't mean you do, besides I don't think he is using BSPs for Doom3, I think it is a special portal rendering.
The use of multiple algoritms is best, if you use am octree then you can also use portals to further cutdown geomtry and make faster trees, they also make for good special fx. You can also use a BSP tree in each octree node if you want.

06-15-2001, 09:39 AM
>They are also good for moddern hardware and
>are not anywhere near as slow as BSPs. I
>think you need to get with the times, the
>time for BSPs died out with quake,

BSPs are much better than octrees for static collission data. You get "perfect" collission data just by running the algorithm, as opposed to octrees which is just a gross first-layer culling mechanism.

My thinking is that each new method adds a new tool, and will end up in the compartment where it makes most sense, so more advanced engines will have more tools, and use the best tool for each need.

Anonymous Coward
06-15-2001, 11:52 AM
I prefer octrees...handles perfectly right indoor and outdoor scenes.

06-16-2001, 12:42 AM
eh? nothing to do with 'space organisation' but Kaber has launch an interesting question.. What kind of IDE are u using under Linux guys??

06-16-2001, 01:03 AM
I use gvim/make and it is the best IDE you could ask for IMHO. I also use gvim extensively under Windows. You can hook it into Visual Studio so it's used as the editor. Integration could be better but it's still good. I've yet to find a programming editor better than gvim and it works on any platform I use. The most useful function I find is vertical block selection/modification. Great for commenting out functions with // at the start of each line or deleting multiple //'s.

06-18-2001, 06:48 AM
but one of the things portal's articles doesnt deal with is, how to generate these cells and portals. i know one way is to create a bsp tree, and use the convex hulls created. but this method generates a lot of unncessery portals and cells, and in these days, it is better to just do some overdraw or unnecessery drawing, instead of a lot of cpu work on culling, so convex hulls are not really needed for this purpose.
i have came up with a simpler method, which creates a cell when you make a brush hollow, and then cut the cells, to generate portals.
do you know of a better method, more general, but that take into acount today's chips and conditions?

06-18-2001, 08:51 AM
Have your artists place portal polygons manually. Or run some really smart heuristic on your global geometry, trying to find places where larger volumes constrict to smaller volumes (good luck with that one!)

06-18-2001, 10:27 AM
well, manual placing is an option i rather stay away from. and the other method you mentioned, well, i will think about that, can be a real problem, you are right.

Michael Steinberg
06-18-2001, 10:33 AM
I always thought that UnrealED would use the bodys as sectors and the intersections as portals. That might be an option. After that you could test wether some portals would be better if they weren't there at all. The best is however to place them manually. Maybe you'll find a pattern in what you do manually and can then setup an algo for that.

06-18-2001, 10:06 PM
thank you all, you have given me a few idea's to play with.

06-18-2001, 10:20 PM
Originally posted by Sylvain:
eh? nothing to do with 'space organisation' but Kaber has launch an interesting question.. What kind of IDE are u using under Linux guys??

it's all about nedit http://www.opengl.org/discussion_boards/ubb/wink.gif

btw, about manually placing portals for ld's...

they'll get by just fine.
i mean a lot of artists had to go through a signifacant relearning stage to get accustomed to the new way of doing things..

just something else they will learn how to deal with it..
but your choice.

i have to get back to hax0ring on linux http://www.opengl.org/discussion_boards/ubb/wink.gif

06-20-2001, 06:05 AM
Linux Developement IDE

I have found that XEmacs is the best choice, it will link directly with gcc, plus there are some games like tetris available. It handles numerous features, such as the commenting as metioned eariler along with auto-formatting, the nicest feature in my opinion.

06-20-2001, 06:13 AM
Sorry, I guess I should add something about BSP and portals. BSP's are great for collision as has been mentioned. If you wish to automatically generate the portals here is a good link to get you started. http://www.exaflop.org/site/frames.cgi?HREF=http://www.exaflop.org/contents/home.cgi. This uses a leafy bsp, and you can stop splitting when the leafs are convex.

Depending on how far you wish to take this you may wish to look at flipcode for information about a hybird system. This idea is you start will an extremely large world, and split it as an octtree, only to a point. Then from here you can make take the polygon pools found in each octtree node and create a bsp. This will greatly improve the collision detection, and will open up your possibilities for the future. Unfortunetaly portals will not operate the same as the document described above entirely.

Hope this helps some

Tim Stirling
06-20-2001, 06:40 AM
What I am thinking of using eventualy is this:

Portals to cut up giant world (with indoor and outdoor scenes together) into smaller chunks and to help remove large complex parts but also mainly for special effects and such like.
Special portals and sectors will exist where the landscape meets the indoors. Large polygons are chose as occluders to hide large parts of the inside or large parts of the outside depending on where you are(in or out). Also when inside the inside is rendered first to minimize overdraw from the terrain that might only be a sliver through a doorway or window.
Then there is an octree that isn't recursed too much, this handles mass culling and can make smaller, faster BSPs and also DYNAMIC geometry.
In each node of the octree a BSP tree is made. The BSP tree is rendered front to back to minimize overdraw. Transparent polygons are then drawn with a seperate BSP tree in back to front order.

The octree(and so also the BSP trees) will be fully programmable for different systems (fast CPU and slow GFX or slow CPU but very fast gfx etc.)


06-20-2001, 08:10 AM
Tim, that is very much like what I was saying. What I was curious about is using the large occulders. I haven't looked at this stuff before, how does that help you? By the sounds of things you will have to use an occulsion buffer to determine when to stop the front to back rendering, which means that large occulders will have no baring on the subject.

Can you explain how they help? Thanks

06-20-2001, 10:23 AM
the method i mention which genrates cells during the creation, and portals by cutting the cells with each other seams to work pretty well.

[This message has been edited by okapota (edited 06-20-2001).]