portals and zones

#1 Things in a zone render, things outside do not. Opposite if you/camera is outside of zones.

Portals connect zones. Turn portal so that the ends of the plane inside the portal is touching 2 zones - it will go green. (this is a little counter intuitive from how the zone first appears on creation). Resize portals as neccessary but try to keep distance between zones (the portal width) fairly small as things inside a zone and not touching a portal won't render unless camera is inside same zone (fix maybe/maybe not coming next beta).

Zones and portals are good for interiors, tunnels etc, not good for outside because they occlude anything not in them.

I hope that vaguely made sense. Have a play around and you'll see.

#2 Hmmm...the zones work fine, but I really don't like the way the portal works. A much better way would be to require the creation of two portals, tie them together through name reference or whatever, and then have what's visible to the one portal rendered through the other portal and vice verse. This of course would more or less eliminate the need for the zone object as the portal and everything visible through the portal would be culled out until the portal actually enters the view frustum. This would also allow for unusual affects such as having doors to completely unconnected rooms simply by having one portal in one room and another portal tied to it in another room. The zones could still be usefull for forcing the engine to cull out objects when the player is outside of the zone, but the usage of the portal and zone combination is just strange and not particularly useful.

#3 I disagree. You are thinking of these portals in the traditional sense, ie a subview into the scene. That is expensive and slow. Even the game Portal, which had some very smart people working on it, maxed out at about 6-7 portals with very limited environments. A single portal in Torque3D would have a huge performance impact because of the dynamic lighting.

So if they are going to have to be physically consistent for performance, then there's no reason to go with an abstract linkage. Make it make spatial sense - which it does.

I think the interface for working with this system could be improved, but that the functionality is ideal.

#4 The interface definitely needs cleaned up as I keep losing track of where the zones are until I've actually clicked on them, making it impossible to place portals unless the zones are right next to each other.

I guess I'll have to come up with some complicated render-to-texture material and a warp zone system to implement anything more abstract.

EDIT: The portals used in the game Portal were also dynamic and therefore far more complex. Unreal Tournament had a number of maps which showed the true power of portals as they were based upon some of M. C. Escher's works whereupon you had players appearing to run around the ceilings and walls without ever having to modify gravity or the up axis and there was no framerate difference between those maps and the usual UT maps.

#5

Quote:
I keep losing track of where the zones are

In Visibility tabs you can force portals and zones to render, that way you can see them in-game and in-editor.

#6 Ah yes, that does make things a lot more usable since default behavior is for the red highlight to only appear around zones once it's been deselected and then reselected and then only while it's selected. Thanks.

#7 There is no functional difference between the UT portals and the portals in Portal (if you ignore the fancy physics/border effects).

Because world geometry isn't a uniform BSP tree of convex geometry anymore, because views require more passes and interstitial data, and because the performance picture has changed tremendously since 1999, doing rendering that way is a lot costlier nowadays.

Anyway I'm just being a cranky programmer. I'm glad Steve was able to get you a good answer, and I know the tools are only getting better thanks to the great work by the T3D team. :)

#8 Actually dynamic portals requires render-to-texture techniques, while portals as used in UT were just a case of clever pre-compiled BSP optimization as at the moment the portal is rendered the BSP for that geometry really is adjacent to the current geometry chunk so all it's doing is rendering that part of the level. This is part of the reason that BSP is usually pre-compiled to separate out zones for easy referencing. Of course, BSP has it's problems and is a complete pain to work with, and T3D can never expect to get efficient portals without it.

But at least I now have zones and portals as used in T3D figured out, even if they can only be used for basic optimizations of the level.