BSP vs Portals

Where an I find information about BSP culling and portal culling?

What are the advantages and disadvantages of each one?

-Quaternion

www.flipcode.com 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.

tip:
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

Well, I like green…

as u wish.

Sylvain, what other suggestions do you have, besides portals and bsp’s? occlusion? view frustum(that is done anyway)?

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.

heh

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

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.
Tim

>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.

I prefer octrees…handles perfectly right indoor and outdoor scenes.

eh? nothing to do with ‘space organisation’ but Kaber has launch an interesting question… What kind of IDE are u using under Linux guys??

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.

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?

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!)

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.

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.

thank you all, you have given me a few idea’s to play with.

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??

lol
it’s all about nedit

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

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.

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