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.
Large, Outdoor areas.
-
Stealth Kill
- Posts: 83
- Joined: Fri Dec 29, 2006 12:34 pm
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 wrote: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.
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.
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.
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.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
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.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
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;
}
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.