Large, Outdoor areas.

[Downsider]

What should I be using? A heightmap seems to be much faster to read and interpret.. However, I'm going to end up wanting buildings on the map, which is where I want to "place" BSP "objects" on the heightmap. Sound good?

Well, see, I'm wondering if working with a heightmap rather than a BSP tree for large outdoor areas would yield a performance gain that's considerable enough.

Lets say our target platform is the PSP..

The performance of our largest outdoor area in BSP form yields about 30 FPS. I don't think our mappers are running VIS correctly, though. I'm looking to get this number a bit higher. I'm also looking for some better displacements.

Another suggested idea was just a massive BSP with more efficient culling/clipping.


What's the most effective and efficient way to go?! Furious discussion below.

Note: If I'm totally off my rocker about this, let me know.

[ceriux]

Downsider, doesnt the psp have a view distance issue , in turn large out door maps would still look like blah...

[Downsider]

Downsider, doesnt the psp have a view distance issue , in turn large out door maps would still look like blah...

Not really.

[ceriux]

well in halo : solitude we're not aloud to have a certain distance viewable because of a view distance issue, unless you have it fixed?

[Downsider]

well in halo : solitude we're not aloud to have a certain distance viewable because of a view distance issue, unless you have it fixed?

I think this view distance issue is all in your head, or your not using VIS correctly.

[ceriux]

when i joined the team, dandi, samuk , and i belive one other person told me that our maps couldnt be too large and or open. because of the fact of that.

[Stealth Kill]

If you use -visdist xxxx then you have a visible distance.
If not then you can see whole map.

[Downsider]

when i joined the team, dandi, samuk , and i belive one other person told me that our maps couldnt be too large and or open. because of the fact of that.

There is not a limit on the view distance; Perhaps you mean a limit on the map's size? I think it's 2048 units or something, but it's easy to expand in the engine.

[ceriux]

no, i know that any map has its size which it cant exceed you can tell right within the editor... idk ... they may have just been wrong and misinformed me.

[Downsider]

no, i know that any map has its size which it cant exceed you can tell right within the editor... idk ... they may have just been wrong and misinformed me.

They're wrong

[Spike]

traditional quake network protocols support coordinates only between -4096 and 4096 (details are fine, so long as they're not models beyond that space).
the bsp format itself supports coords between -32768 and 32767.

DarkPlaces uses floats for coords so bipasses the first limit (sv_bigcoords 1 in FTE will do the same).
DarkPlaces uses portal stuff, so ignores the second limit.

So you can have insanely huge maps in DarkPlaces. Other engines are more limited.

Default view distance is set to 4096 units in a standard quake engine. This is a radial distance limit. The actual box sizes are smaller, and doesn't include joining passageways. DP doesn't have this limit. FTE requires gl_maxdist set to 0 or something large. Most other GL engines are limited to 4096 by default I gather. gl_maxdist? r_maxdist? dunno, depends on the engine.
Software rendering is similarly capped.

Editors like worldcraft limit the viewable map area to +/- 4096.

[mh]

You have two options:

One - measure the size of the map at load time; all you need is a minimum point and a maximum point (you can get this from the surface verts); then get the distance between them and set this as the zFar in your glFrusum or gluPerspective calls.

Two - do the same at runtime but measure it from the surfs that are actually drawn (whether or not this is viable depends on the structure of your surface renderer).

Either way you get a dynamically scaling far clipping plane that doesn't require any mucking about with cvars or command line options.

[Spike]

or you can compute your perspective matrix with the far clip plane at infinity without any measuring nor any extra work, plus this means you don't need to clamp your stencil shadow volumes or anything.

But hey, mapper vs engine hacker perspective.

[mh]

Y'know, an infinite far clip is something I've seen a lot of people talk a lot of things about, but I don't actually recall any of them ever putting their trousers where their mouth is and showing some code.

Stencil shadow volumes are overrated anyway. Ugly hard-edged things.

Anyway, knowing the extents of the world can be very useful for other things too (such as how far do you draw your sky at, etc), so it does have practical applications beyond pure OpenGL.

[Spike]

Code: Select all

float r_projection_matrix[16];

void GL_InfinatePerspective(double fovx, double fovy,
           double zNear)
{
   double xmin, xmax, ymin, ymax;
   float nudge = 1.0 - 1.0 / (1<<23);

   ymax = zNear * tan( fovy * M_PI / 360.0 );
   ymin = -ymax;

   xmax = zNear * tan( fovx * M_PI / 360.0 );
   xmin = -xmax;

   r_projection_matrix[0] = (2*zNear) / (xmax - xmin);
   r_projection_matrix[4] = 0;
   r_projection_matrix[8] = (xmax + xmin) / (xmax - xmin);
   r_projection_matrix[12] = 0;

   r_projection_matrix[1] = 0;
   r_projection_matrix[5] = (2*zNear) / (ymax - ymin);
   r_projection_matrix[9] = (ymax + ymin) / (ymax - ymin);
   r_projection_matrix[13] = 0;

   r_projection_matrix[2] = 0;
   r_projection_matrix[6] = 0;
   r_projection_matrix[10] = -1*nudge;
   r_projection_matrix[14] = -2*zNear*nudge;
   
   r_projection_matrix[3] = 0;
   r_projection_matrix[7] = 0;
   r_projection_matrix[11] = -1;
   r_projection_matrix[15] = 0;
}


Then modify R_SetupGL to call that instead of whatever it is that it normally calls (MYgluPerspective by the looks of it).
Anyway, the result is a projection matrix which can be loaded via glLoadMatrixf.

The near clip plane can't be 0, so don't even try that.

The nudge thing can just be set to 1 if you have problems. it helps a little.

Anyway, this is hardly formatted as a tutorial... or even a howto...
I'm sure Baker could do something a lot more readable than I could ever bother doing. Lazyness is a curse. :s

Tbh, who cares where the sky is when its about 1000000000000.3 units away from the origin.

The provided code is from FTE. DP has a near identical projection matrix, except that DP's uses frustum instead of fov, and its all a bit more DP specific. The FTE one should be more portable to other engines, hence why I give that one.