i want to build a little portal engine. i know the theory, but one thing im not sure about, how can the editor determine what is a room (a cell), and what is a simple object inside a room. is it done manualy, or the algorithm makes brushes with brushes inside them to be cells?
That has always been the question I think. I believe that UnrealED used the cutting planes of two “primitives” as Portals (a CSG algorithm seems to be used), from what I saw of it. But I’m not sure about that. The most effective rendering should be done by manually adding portals to the scene, where they can help. But, it is obvious, that this is the most time expensive way for modelling a map.
i was thinking that it might be possible to consider a brush that was made hollw a cell.
n most editors there is the “make hollow” command. maybe this is possble, waht do you think?
Yeah, that is exactly what I meant. If you hollow a brush, it’s nothing more than
Brush -> CSG-Sub Hollow brush.
If you’ll make an indoor shooter it will probably be better to consider a brush a “hollow-brush”. Means, at the beginning all the world is “full” of concrete or something else. Then you add a brush, which is actually a “hollow” brush. Get what I mean. Okay then, if you add another hollow brush, do a csg-unity, get somehow the faces that could be portals (that is a bit tricky) and seperate the resulting brushes into sectors. But after all, most of the portals that happen to come out or more or less unncessary, and the only pro is, that you’ll have only convex vectors. That is another thing, sectors should be convex. But what a bout putting a sphere into an room. That would end up in many many many sectors. I think a combination of sector/portal and bsp design is the most useful. The model-editor should place portals where they can help, or where some cool effects are necessary, say the editor which things make up an sector, and then there’ll be a leaf-based bsp per sector. Get what I mean?
Nobody else is interrested in this? I’d like to have a discussion here… 
This stuff is very interresting to me!!!
I’m interested but don’t know enough about it to contribute much. Learning how portals and BSP-Trees work is on my long list of things to learn.
Originally posted by Michael Steinberg:
The model-editor should place portals where they can help, or where some cool effects are necessary, say the editor which things make up an sector, and then there’ll be a leaf-based bsp per sector. Get what I mean?
In my engine, I use concave sectors (defined by the designer; portals are placed manually). I also construct a BSP for each sector like you suggest, but I only use it for depth sorting. Visibility checking is only done on a per-sector basis, using the portals. I think this helps to cut back CPU overhead quite a bit. The transparent polygons are rendered the hard way, of course, because they require sorting, but everything else I can put in a display list or vertex arrays or whatever, so it can be rendered quite efficiently.
so you are saying, that if my rooms are all just squares, i mean no diaognal walls, so i can use their brushes as the cells, and when u perform a cutting csg operation, i use the results as the portals?
that sound resonable, right?
A portal based renderer and a bsp based renderer are quiete different. Portals in bsp levels are just small optimizations to glue quake1 like levels together, but it is not a portal engine.
If sectors have to be convex, it is quite a mess, since I can think of thousands of situations, where you’d get millions of sectors. Also, you’ll get more portals than you need, since you can’t make up a room that has some detail at for example its walls without adding useless portals. If you want to use concave sectors and place the portals manually, you’ll get problems with to know in which sector you are and to handle collision detection. In this case, a bsp for a sector helps you out. So, I disagree with you mfugl. Might be that I got something wrong…