Re: [Algorithms] Portal VS BSP

[Alen L. <ale...@cr...>]

From: "Tom Forsyth" <tom...@bl...>
>> case are your
>> artists manually tagging polygons wrt which sector they are
>> in?
>Level-editor tool and automatic flood-fill outwards from portals.

Ah, flood fill, I guess Unreal is using something similar then as well, since
they too have portals, but without occluders, AFAIK.

>> And how are
>> dynamic objects classified?
>First time they are placed, they find the nearest static mesh that encolses
>them, and obviously they're in that sector. Then as they move, they check
>whether they have moved through each of the portals in that sector. If they
>have, they're now in the next sector. There's also a check to see if they're
>inside the bbox of the sector as a whole, and if not they do the "first
>placement" check again. Normally this shouldn't happen, but accidents do
>happen.

Sounds a bit complicated. What we do is to give each zone an actual shape.
Then classifying an object is simply a matter of walking it down a BSP. You
can have a global BSP for entire world, or one for each zone. This is a
fool-proof solution. You can just make a bsp from the polygons in a zone
together with portals on its border. But for a lot of polygons it would create
a very deep tree. So using a separated, very simple, zone borders geometry is
better. Once you have the shape of the zone, it can be inconvex, and the
border polygons serve as simplistic occluders.

>> Are you saying that you actually cull polygons inside a zone,
>> based on clipped
>> frusta? Isn't it too much overhead to even touch each
>> rendering polygon with
>> the CPU?

>Each sector will have lots of separate objects and instances in it. So you
>decide whether to draw or not draw them each based on clipping their
>projected screen bbox against the visible frustum (fusion of the visible
>portals intot he sector). So a small portal into a big room doesn't
>necessarily draw the whole of the big room,

Aha, I see. Per object rather than per poly. Nice.

Cheers,
Alen