Portals

[Guest CRiZ]

So Doom3 is going to use Portals? That's nice.... What are they?
If other games weren't using Portals, what then?
What are the advantages of Portals?

Anyone have any good URL's?

[Zaldron]

Let´s make it simple. The Quake engine powered games use VIS calculations to optimize each map´s speed. You can´t just let your video card draw ALL the triangles of the level each frame, so each map must be compiled in order to get visibility info. That´s pretty much like saying "Im here, what triangles CAN i see?". Doing this lot of times, taking different coords, you can make the level run more efficiently. The problem with this approach is that it takes a painful chunk of time to be completed. Everyone here who ever VISed a complex map for a Quake knows how much it can takes...

The Portal technology solution is simplier, split the levels into convex volumes, and calculate in real time what volumes are present (so you know what triangles must be drawn).

That´s pretty simple way to describe portal, altough I shall mention that level designers still have to assign to a lot of the level brushes the "detail" property so it doens´t mess up the portals. NURBSs will probably be detail-only brushes.

[Guest CRiZ]

Okay, bear with me. I appreciate you taking the time to answer my technical questions but reading your paragraph only brought up more questions.

So VIS operates at what spatial resolution? It can't possibly consider EVERY point in space in a map. I'm not sure if this is right, but I can imagine it working like this: VIS divides the map space into cubic volumes(eg. dxdydz differential volumes, if you have experience with calculus. I just wrote them this way because you could vary the size of each cube depending on how much precision you wanted. Hopefully that doesn't make everything more confusing) and then determines which triangles can be seen looking out from the 6 directions corresponding to the 6 faces of your cubic volume.
Okay... enough of VIS

More on Portals... gee, I hope other people are interested in this stuff... anyway:

Okay, I found this definition:

a convex volume can be defined as a volume whose every corner can be visible from all other corners in the same volume. Another way of defining the convexity is that all faces in the volume will be lit by a point light located anywhere within the volume.

Cool, makes sense.

But i don't understand how the convex volumes (which is another name for Portals, I assume) are assigned. Are these determined by the map author or by software?
So basically, when your player character is in one of the Portals, that portals is the entire map as far as the engine and rendering is concerned. This tech sounds great for twisting hallway type levels but I'm just trying to imagine how it helps at all when you have big outdoor areas or places where you can see long distances. The thing that bothers me with this is seeing into other portals. How does this work?
AHH! This is so confusing.

Do you know of any good references? How'd you learn all this stuff anyway? Just reading stuff on the net?

Thanks Zaldron

[Zaldron]

No, VIS does NOT make a minimum float precise calculation, that would take years to compile if the tools operated in the rawest way.

Altough I´m not completely sure how does VIS works, I think a cubic grid´s the most clever way. I dunno what are this imaginary cubes sizes on the Quake engines, but it doesn´t take that much to get precise renderings. Remember that most levels aren´t full of cracks, imaginary brushes, func_x types and so on. It all depends on how many triangles are on scene. That´s why there´s detail brushes, they do NOT intersect with the rest of the world, so there´s actual Z-buffer calculations. While this prevents absurd tesselations appear on your level, this makes the brush unable to project shadows, since there´s no VIS data to provide to the RAD command.

Going back to portals.

The engine automatically assign them. Altough several times you can use a set of tools to make things faster. Big clipping planes allow you to hide big chunks of levels without all the calculations. Detail brushes prevent the system of breaking the volumes into too many convex zones. Remember that this system works to hide/reveal rooms, it can´t be used as a general rule.
NURBSs can´t be portal-ed, that would spit thousands of results. Few times we have seen NURBSs working as walls, or entire rooms. In this cases, the designers should add clip planes, or create normal CSG brushes to "enclose" the bezier patches.

The big problem of Portals : they don´t support outdoors, specially terrain meshes. This is where a programmer should add Heightfield calculations. Things like clipping planes, terrain one-Z laws (hills hide plains geometry) and more weird stuff makes sense.

Seeing into other portals does not make that much trouble. Your view cone will intersect several convex areas, while a per-triangle ray casting would cost much, much more CPU power.
Remember, this is not a magic solution, it´s real time, so it takes some CPU to be processed. 30 or 50 convex areas are easier to understand than 59678 triangles.

I don´t know good references about this subjects, most of my knowledge´s based on DX programming, working in 3DSMAX, editing for games and common sense.