Getting the feeling like I’m about to get stuck with my engine, so I though I’d post a little description of what I’ve done hoping some people may offer advice based on past experience. My aim is to get a flexible portal engine up and running. Currently I have Sectors that are defined by bounding boxes. Each sector contains a static mesh and portals to other sectors. I’ve just implemented a Frustum class that will be used to clip portals against. So in the game we start by placing the player in Sector X and because (though the portals links) we know what sectors to test I’m able to limit the number of sectors to test player position against by the current one + all directly connected sectors. That’s fine but when it comes to rendering I’m a little confused as to how I should approach it. My first thoughts are to attach a portal to the front viewing plane of the camera, then track what sector that plane is in. Rendering the camera would render through its portal and into the sector, thus checking all associated portals -> sectors ect. But then I remember I wanted a flexible portal engine, where I can do mirror effects and, teleports. Teleports are interesting because we need one portal to look into and another to be looking out of. So from that perspective should I… Class Portal { Public: Portal *DestinationPortal … } And let the destination portal render into it’s sector. Or should I do this. Class Portal { Public: Sector *DestinationSector Int DestinationPortal_ID … } And allow the destination Sector to render it self. Basically I think I can get it to work both ways but am not sure.. (p.s sorry for the incoherent gibberish)

You mention bounding boxes, but is it really needed to define bounding volumes for areas that strictly (or even to define them at all)? Shouldn't the important thing really be to have portals in every room (or sector)?

I suppose it makes it easy to find which "sector" the camera is in, but that's not really something you need to care about, is it? All you need to do is keep track of which sector you are in (you know where you start, and you can update it when you cross a portal).

As for the rendering, it seems rather trivial to me. The most complicated should be the bit of linear algebra math you will need to perform to test shapes for visibility... But let's see...

You have a portal. It's basically a gateway. Ignoring its actual appearance, it's only a section of a plane, which, whatever entities go through, end up in another room on the other side. It's basically a hyperlink in 3D space. To render a scene in a portal engine, you want to use these portals to speed things up.

You can just go like this:

1. Render the area the camera is in. This area should pretty much always be visible, at least partially.
2. Test for visible portals in the area you are in (those in your frustum).
3. For each visible portal, render the area they link to, since it is visible.
4. Test for visible portals in each visible area. Using your camera's frustum clipped by the incoming portal (the portal you see that area through).
5. Goto 3.

For teleports, it's simply a portal linking to a room which is not immediately linked to yours (in space). But remember, portals are like "hyperlinks" in space. They don't even need to have the same shape on both sides. And for teleports, if you use a smart coordinate system (where room coordinates are relative to the center of the room, and not the world origin), then you can easily use a transform matrix to render the remote room like it was directly linked to your "teleporter" portal. You can introduce whatever graphical effect to hint the player that it's a teleport if you wish. You will also want to introduce a maximum recursion level to avoid infinite loops in the rendering from ever occuring if you have teleporters as well.

As for mirrors... You have two options. The first is to specialize your portals with an option that say's "can't go through", and then to apply a texture over it to make it look like glass or water, etc... The second is to implement them separately, but still use the area rendering mechanism to render the room from the mirror's perspective. I would personally go with the second option because I find it cleaner than having mirrors be portals that aren't really portals and link to themselves.

If you want my opinion, you should have a class for areas, with a CArea::Render() method that takes the view frustum as a parameter. This makes it easy to reuse the system for mirrors. Each area can then internally have a vector of portals linking to portals from remote areas. If you make this flexible, you can have some quite funky effects... Like a corridor which you can step in through a portal in a room, but then two portals at both ends of the corridor simply link to one another (the player is then trapped in an infinite corridor).

Thanks for that, it’s given me a lot to think about. I did not consider working it without sector bounding boxes. As, like you say, I can track this as the player moves through a portal. Something along the lines of casting a ray from the player in the direction of movement and testing intersection of portals, Although I’ll need to think that through also J.

As far as mirrors for portals go, I would not have self-linked one portal to itself. I was thinking of two portals both on the same plane making up one mirror except with opposite winding orders. Because I was wanting to discard back face portals any way. This would keep true to a rule I made a while ago being that you can look out through the front face of a portal and into the back face of another portal. Or course in most situations this requires two portals to simply walk through a door.