[ Pobierz całość w formacie PDF ]
.Each cellrepresents empty space, and all of the polygons in the cell face inwards.They can be connected to anynumber of other cells, and the boundary locations become the portals.You can think of two adjacentcells (call them A and B) having two portals that connect them.One belongs to A and points to B as theneighbor, and the other belongs to B and points to A as the neighbor.The two portals must be exactlythe same except for vertex ordering and normal orientation.If this is not the case, portal rendering willnot work correctly.To help illustrate the point, consider a standard scene of polygons, as shown inFigure 11.2.632Figure 11.2: A regular scene of polygonsThis scene is of a few angular rooms, seen from a top-down view.The white area shows the region youcan move around in.As you have it set up now, there is no spatial relationship set up for this scene.You can draw the world using the z-buffer and not have to worry about anything, but you'll have to sufferthrough all the scene management problems detailed above.Instead, how about turning the scene into something with which you can portal render.I'll discuss laterhow you can take an arbitrary polygonal scene and decompose it into a bunch of convex cells, but forright now assume that I have a black box that can do it for you.It might come up with a composition likethe one that appears in Figure 11.3.Figure 11.3: The scene divided into eight cells633Now you have divided the scene into eight distinct convex rooms, all connected together with portals.Even without the rendering efficiency of having zero overdraw, this data representation is useful in manyways.Since the cells are convex, you can quickly perform a test between the bounding sphere of anobject and the cells in the world to find out which cell(s) an object is touching (it may be situated in aportal such that it is sitting in more than one cell).All you do is perform a plane-sphere test with eachpolygon and portal of the cell.If the sphere is completely behind any of the planes (remember that thenormals all point into the cell), then you know that the sphere isn't touching the cell at all.If you know the space of cells an object exists in, then suddenly the scene becomes much moremanageable.When you want to do any processing on an object that needs to be tested against otherobjects (for example, checking for collisions), you don't need to check all the objects in the scene; youjust need to check the objects that are in each of the cells that the target object is in.Even if the worldhas a hundred thousand cells and a hundred thousand objects wandering around those cells, the hardalgorithms will only need to be run with an extremely small subset of that total set; there might only beten or so other objects in the cell(s) a target object is currently in.You can imagine how much faster thismakes things.The extra bonus that you get with cell-based worlds of course lies in portal rendering, which allows youto efficiently find the exact set of cells that are visible from that viewpoint.Even better, you can find theexact set of polygons visible from that viewpoint.To generate this visibility data, I use what I'll call a viewing cone.A viewing cone is an n-sided pyramidthat extends infinitely forward, with all the sides meeting together in world space at the location of theviewer.The sides bound the visible region of space that can be seen from the camera.Before you doany portal rendering, the sides of the cone represent the sides of the screen; anything outside the conewill be outside the screen and shouldn't be drawn.Note that when you're rendering, the viewing conehas two extra conceptual polygons that lop off the tip of the cone (everything in front of the near z-planeis not drawn) and the bottom of the cone (everything behind the far z-plane is not drawn).You mustignore these two planes for right now; portal rendering won't work correctly if you don't.AsideA pyramid with the top and bottom chopped off is called a frustum.Given the viewing cone, clipping a polygon against it is fairly easy.You perform a polygon-planeclipping operation with the polygon and each of the planes of the cone.If at any time we completely cullthe polygon, we know that it is invisible and we can stop processing it.To use this functionality, we'll make a class called cViewCone.It can be constructed from a viewerlocation and a polygon (which can be extracted from a portal in our scene) or from a viewer location andthe projection information (width, height, field of view).It clips polygons with Clip(), returning true if somepart of the polygon was inside the viewing cone (and false otherwise).Also, an output polygon is filledwith the inside fragment, if one was there.The source for cViewCone appears in Listings 11.1 (header)and 11.2 (source).634Listing 11.1: ViewCone.h/******************************************************************** Advanced 3D Game Programming using DirectX 9.0* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ** copyright (c) 2003 Peter A Walsh and by Adrian Perez* See license.txt for modification and distribution information*******************************************************************/#ifndef _FRUSTUM_H#define _FRUSTUM_H#include ".\math3d\point3.h"#include ".\math3d\plane3 [ Pobierz całość w formacie PDF ]