Well...I mean, I don't see why they can't...

Do you mean portals in the "portal engine" sense of the word, or just generic portals?

Are you using a particular engine or is this something you're coding yourself?

If you're doing it yourself then of course it's possible.

If you're using a pre-written engine then it depends on whatever engine you're using.

Portals are "teleporters".. In an editor you usually place them at the boundries of sectors, but this is mostly to make it easier to create the level (build level first then place portals). There's nothing, except possible limitations in the editor, to keep you from separating the portals in the editor. As long as you "link" the exit-portal polygon of sector A to entry-portal polygon in sector B you won't be able to see a difference in the game. Interesting effects such as mirrors, seemingly infinitely long corridors (looping Aexit->Aentry) or buildings that are bigger on the inside than on the outside are possible (even easy - you just specify a different target portal). Free floating "teleporter" entry portals wouldn't be a problem.

To make it easier to make you could make the entry portal in the cloud static, but the teleporter to the cloud can be placed dynamically during gameplay. AFAIK you can place the entry-portal dynamically as well but I suspect it will be a bit more work.
One problem I can see is with the geometry and texture data. If you're paging a huge level and just storing the nearby area in memory you might get a delay as you open the teleporter portal. The reason is of course that the game can anticipate which portal you'll be entering and preload the needed data, but for the teleporter exit you either have to always keep it it in memory or let it grab it when you open the portal. A possible solution is if you have to use an object to open the portal. As soon as the player selects the object the game can anticipate the new portal and start pre-loading. If you need more time you can also use a "long" animation of the portal being formed.

See the videos from Prey to see major portal action.

Quote:Original post by stroma
hmm, i dont see any limit but i want to know that if you move portals dont we have to re-calculate PVS (if in use)?? and this cant be done in real time?

BSP type PVS isn't as useful as it used to be.. It's more efficient to let the GPU render some occluded triangles than to use the CPU to cull.
Anyway, portals would still work for visibility tests, even with dynamic portals, at least to a degree (some overdraw).

Each portal is "two" planar polygons, one is the exit from the current sector and teh second is the entrance to the adjacant sector. I used ""'s because in practice you usually just place one in the editor, but since sectors don't have to be physically connected I say "two".

I'm a bit unsure how occlusion is done with portals these days. In the days of legends they used to use them as culling frustrums. First you culled with the viewing frustrum, then the portal for the joining frustrum and so on until there were no visible frustrums. Also, the sectors couldn't be concave (AFAIK they can be now since we no longer care if we get vasted overdraw).

These days I think they just do a polygon-in-volume test to see if there is a portal visible from the camera. If it is then they check if there are other portals visible through the frustrum. Then all sectors whose portal were visible are rendered. Because of this it doesn't matter if you place a portal dynamically. You know the position and shape of the portal-polygon, and the world/camera transformations and thus you can render dynamic portals in just the same way as fixed portals.

Sorry if I couldn't make myself understood... I can look for some more info later this evening if you want.. Otherwise, as they say, Google it [smile].