Generating 2D Mini-Maps Idea
Generating 2D Mini-Maps Idea
It would probably make something like this, except without even the slightest (or maybe only the very slightest) 3d aspect to it.
-------------
I think about 2 years ago ezQuake came out with some sort of spectator radar system that does a 2D overlay:
Now as far as I know, these minimaps are probably noclip + gl_clear 1 screenshots of some sort made in an image editor so it would only work on levels where someone made one.
I have a concept idea that hasn't been tested yet but I probably will soon.
Now, this concept isn't for Quake, but for total conversion ideas and having a mini-map HUD element is rather common in games.
1. Using glscalef, alter all 3D game data to have a very small z size. This will turn the map representation into a very thin 3 object and it probably must remain 3d to avoid z-fighting.
2. Determine some method to "capture" the screen without displaying it via SwapBuffers. Do this upon level load to have the texture created. I'm still learning so I don't know if the first part is possible. If not, then at least it could really help a developer make a 2d "map" of the entire map.
3. Some sort of scale information would have to be stored or calculated for sure including a way to identify where 0,0 is.
4. An interesting extension of this idea, if it is ultimately workable would be to generate additional "2d map representation" textures based on the z location or even have some sort of QuakeC extension to update the "2d map representation" if a major in-game change occurred like the lowering of a bridge.
Raw concept, but I'd like to try it out. The idea of having some sort of brainless [=no work for a map author] mini-maps available is something I think would be useful.
-------------
I think about 2 years ago ezQuake came out with some sort of spectator radar system that does a 2D overlay:
Now as far as I know, these minimaps are probably noclip + gl_clear 1 screenshots of some sort made in an image editor so it would only work on levels where someone made one.
I have a concept idea that hasn't been tested yet but I probably will soon.
Now, this concept isn't for Quake, but for total conversion ideas and having a mini-map HUD element is rather common in games.
1. Using glscalef, alter all 3D game data to have a very small z size. This will turn the map representation into a very thin 3 object and it probably must remain 3d to avoid z-fighting.
2. Determine some method to "capture" the screen without displaying it via SwapBuffers. Do this upon level load to have the texture created. I'm still learning so I don't know if the first part is possible. If not, then at least it could really help a developer make a 2d "map" of the entire map.
3. Some sort of scale information would have to be stored or calculated for sure including a way to identify where 0,0 is.
4. An interesting extension of this idea, if it is ultimately workable would be to generate additional "2d map representation" textures based on the z location or even have some sort of QuakeC extension to update the "2d map representation" if a major in-game change occurred like the lowering of a bridge.
Raw concept, but I'd like to try it out. The idea of having some sort of brainless [=no work for a map author] mini-maps available is something I think would be useful.
I have no idea but maybe the fancy bsp2bmp tool could help?
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Yeah, I'd like to see that.mh wrote:Nice!
I've some automap code in an old engine I can give you if you like.
I know there is some sort of .bsp to .wad tool and some sort of rewad tool. I'll probably find the answer in the txqbsp source code.Spirit wrote:I have no idea but maybe the fancy bsp2bmp tool could help?
If I remember correctly, Quake Royale has a minimap which updates by 'zone' to tell you where you can safely travel and what will soon be a danger zone. Rich might be helpful in this endeavor.
...and all around me was the chaos of battle and the reek of running blood.... and for the first time in my life I knew true happiness.
Sure, I'll dig it out over the next while, but be warned: I might get motivated to put it into my current engine!Baker wrote:Yeah, I'd like to see that.mh wrote:Nice!
I've some automap code in an old engine I can give you if you like.
Ah, here we go. Set the time machine for 29th January 2005!
https://sourceforge.net/project/showfil ... _id=216046
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
Ah sorry, I should have been more wordy. bsp2bmp is a tool to create "schematics" from bsp files. Maybe some of the code could help you.Baker wrote:I know there is some sort of .bsp to .wad tool and some sort of rewad tool. I'll probably find the answer in the txqbsp source code.Spirit wrote:I have no idea but maybe the fancy bsp2bmp tool could help?
http://www.quaddicted.com/stuff/xyz/rpgsp1.bsp_Z.png (nevermind the other stuff in that folder)
http://www.quaddicted.com/tools/bsp2bmp-0.0.15b.tar.gz
http://www.quaddicted.com/tools/bsp2bmp-0.0.15b.zip
From what I know that is what the QW minimaps originate from. The rest was manual work afaik.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Ah, that does look interesting. Thanks I will check that out.Spirit wrote:Ah sorry, I should have been more wordy. bsp2bmp is a tool to create "schematics" from bsp files. Maybe some of the code could help you.
The name "bsp2bmp" sounded like a WAD tool name and I thought you were suggesting a way to add the texture into an existing .bsp.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Well, that utility that Spirit posted in one of the third does it from a compiled .bsp. I'm not sure the advantage that you would be looking for using an original .map file, unless you are trying to preview .map files for a specific reason.JasonX wrote:I've been thinking about creating the same thing, a mini-map image, using the original MAP file. Should i read the three brush points, except the Z value, and get a proper laydown?
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
I've done exactly this, but outside Quake and in D3D, you ideally don't want to scale all z and use regular 3d perspective, what you want is a hybrid between 3d perspective and 2d ortho, which I in my engine call 3d ortho, its basically an orthogonal proecjtion but with real near / far clip
perspective camera usually has a nearclip of 0.01 and fraclip at 512 ( or ifinite )
2d ortho usually is -1.0 to 1.0 but everyone usually always render 2d stuff at 0.0 making the last thing you renderede end up ontop ( you can have proper z-test even in ortho so you don't need to render 2d stuff i na particular order )
anyway, the approach i call 3d ortho is an orthogonal projection with near and far clip matching my 3d perspective projection. This way i made a "live" minimap thatis generated at level load by the game, and updates while playing whenever a change happens. All using the real geometry of the level. This removed a huge step for our oartists by not having to generate a new minimap each time they redeisgned / changed a level.
Long post but I hope you got the idea.
Edit:
http://temp.snowcold.net/Perspective%20 ... 20Test.rar
Found one of my old demos showing what my 3d ortho projection is, the demo is of 2 fighters, looks like your regular 2d fighting game, but its actually 3d ortho, press '2' to turn it into a 3d perspective projection ( it interpolates between the 2 projections giving a nice transition )
pressing '1' turns it back into 3d ortho again
Thats the same approach i used when making the "load-time" minimap except i rendered to a texture instead of to the screen
perspective camera usually has a nearclip of 0.01 and fraclip at 512 ( or ifinite )
2d ortho usually is -1.0 to 1.0 but everyone usually always render 2d stuff at 0.0 making the last thing you renderede end up ontop ( you can have proper z-test even in ortho so you don't need to render 2d stuff i na particular order )
anyway, the approach i call 3d ortho is an orthogonal projection with near and far clip matching my 3d perspective projection. This way i made a "live" minimap thatis generated at level load by the game, and updates while playing whenever a change happens. All using the real geometry of the level. This removed a huge step for our oartists by not having to generate a new minimap each time they redeisgned / changed a level.
Long post but I hope you got the idea.
Edit:
http://temp.snowcold.net/Perspective%20 ... 20Test.rar
Found one of my old demos showing what my 3d ortho projection is, the demo is of 2 fighters, looks like your regular 2d fighting game, but its actually 3d ortho, press '2' to turn it into a 3d perspective projection ( it interpolates between the 2 projections giving a nice transition )
pressing '1' turns it back into 3d ortho again
Thats the same approach i used when making the "load-time" minimap except i rendered to a texture instead of to the screen
Re:
(Yeah ... this isn't exactly an immediate reply but storing the info here or someone else finding it might be helpful to them)Tomaz wrote:I've done exactly this, but outside Quake and in D3D, you ideally don't want to scale all z and use regular 3d perspective, what you want is a hybrid between 3d perspective and 2d ortho, which I in my engine call 3d ortho, its basically an orthogonal proecjtion but with real near / far clip
perspective camera usually has a nearclip of 0.01 and fraclip at 512 ( or ifinite )
2d ortho usually is -1.0 to 1.0 but everyone usually always render 2d stuff at 0.0 making the last thing you renderede end up ontop ( you can have proper z-test even in ortho so you don't need to render 2d stuff i na particular order )
anyway, the approach i call 3d ortho is an orthogonal projection with near and far clip matching my 3d perspective projection. This way i made a "live" minimap thatis generated at level load by the game, and updates while playing whenever a change happens. All using the real geometry of the level. This removed a huge step for our oartists by not having to generate a new minimap each time they redeisgned / changed a level.
Long post but I hope you got the idea.
Edit:
http://temp.snowcold.net/Perspective%20 ... 20Test.rar
Found one of my old demos showing what my 3d ortho projection is, the demo is of 2 fighters, looks like your regular 2d fighting game, but its actually 3d ortho, press '2' to turn it into a 3d perspective projection ( it interpolates between the 2 projections giving a nice transition )
pressing '1' turns it back into 3d ortho again
Thats the same approach i used when making the "load-time" minimap except i rendered to a texture instead of to the screen
In FitzQuake using what you advocate with the Z Scaling can be done like this (probably translates nearly exactly to GLQuake):
gl_rmain.c
Code: Select all
/*
=============
R_SetupGL
=============
*/
void R_SetupGL (void)
{
//johnfitz -- rewrote this section
glMatrixMode(GL_PROJECTION);
glLoadIdentity ();
glViewport (glx + r_refdef.vrect.x,
gly + glheight - r_refdef.vrect.y - r_refdef.vrect.height,
r_refdef.vrect.width,
r_refdef.vrect.height);
//johnfitz
GL_SetFrustum (r_fovx, r_fovy); //johnfitz -- use r_fov* vars
glCullFace(GL_BACK); //johnfitz -- glquake used CCW with backwards culling -- let's do it right
glMatrixMode(GL_MODELVIEW);
glLoadIdentity ();
glRotatef (-90, 1, 0, 0); // put Z going up
glRotatef (90, 0, 0, 1); // put Z going up
glRotatef (-r_refdef.viewangles[2], 1, 0, 0);
glRotatef (-r_refdef.viewangles[0], 0, 1, 0);
glRotatef (-r_refdef.viewangles[1], 0, 0, 1);
glTranslatef (-r_refdef.vieworg[0], -r_refdef.vieworg[1], -r_refdef.vieworg[2]);
glScalef (1,1, 0.01); // <--------------- Baker: slap Z scaling in right here
glGetFloatv (GL_MODELVIEW_MATRIX, r_world_matrix);
//
// set drawing parms
//
if (gl_cull.value)
glEnable(GL_CULL_FACE);
else
glDisable(GL_CULL_FACE);
glDisable(GL_BLEND);
glDisable(GL_ALPHA_TEST);
glEnable(GL_DEPTH_TEST);
}
1. Instead of setting glFrustum ... do a glOrtho. Capture the mins and maxs of the map first using Electro's post from this thread: http://forums.inside3d.com/viewtopic.php?t=1353
2. Eliminate all the FOV culling and surface culling. Kind of like a bit more than r_novis 1.
3. Kill the "point of view" positioning stuff that looks like this (elimating the "View" from the equation) ...
Code: Select all
glRotatef (-r_refdef.viewangles[2], 1, 0, 0);
glRotatef (-r_refdef.viewangles[0], 0, 1, 0);
glRotatef (-r_refdef.viewangles[1], 0, 0, 1);
glTranslatef (-r_refdef.vieworg[0], -r_refdef.vieworg[1], -r_refdef.vieworg[2]);
To localize the mini-map, the glOrtho could be adjusted to player/camera origin r_refdef.vieworg +/- some X and Y range like glOrtho (r_refdef.vieworg[0] - 200, r_refdef.vieworg[0] + 200, r_refdef.vieworg[1] - 200, r_refdef.vieworg[1] + 200, worldminz, worldmaxz). The visibility culling could still be used to prevent seeing stuff you should be able to see, but the frustum culling (frustum = what is in front of you) would have to go.
Sure the minimaps stuff in older DirectQ probably did exactly that +/- or minus, but back then I simply didn't know enough about the engine or the 3D stuff to even get the mechanics of this stuff. Not in a way that I actually understood. glOrtho more or less just tells OpenGL where a pixel gets rendered so if you say glOrtho (-32768, 32768, -16384, 16384, -999999, 999999) the pixels the top left of the viewport (or screen usually) would be (-32768 X, -16384 Y) through (32768 X, 16384 Y) and the Z range wouldn't do anything.
[I wonder how much my browser's "auto-spell check" screws up what I type by auto-correcting it stupidly?]
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Generating 2D Mini-Maps Idea
The biggest complexity with this is PVS - the server may not send entities that are not in the regular PVS but should be in the 2D view. An example was the start map - you pick a skill and go through the teleporter, then go back. Switch to the 2D view and the floor over the pit to Shub isn't there. I hacked around that by caching entity states client-side and using the cached state when in the 2D view and when the entity was not updated in the current frame. It was slightly nasty code and I could never get it satisfactorily robust.
Standard R_RecursiveWorldNode and Frustum culling would work for the 2D view provided you set your viewpoint a little above the center of the view and your frustum planes according to the new projection (just extract them from your MVP - the way GLQuake does this is completely unnecessary).
You also need to slice off geometry at some point so that you can see into the map - anything more than 32 units or so above the player's real position in the map is good to start with. You could test in software or just add a user clip plane in hardware (that would involve some extra processing as a lot of verts that otherwise wouldn't be sent to the GPU would need to go to it for testing).
Standard R_RecursiveWorldNode and Frustum culling would work for the 2D view provided you set your viewpoint a little above the center of the view and your frustum planes according to the new projection (just extract them from your MVP - the way GLQuake does this is completely unnecessary).
You also need to slice off geometry at some point so that you can see into the map - anything more than 32 units or so above the player's real position in the map is good to start with. You could test in software or just add a user clip plane in hardware (that would involve some extra processing as a lot of verts that otherwise wouldn't be sent to the GPU would need to go to it for testing).
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