Generating 2D Mini-Maps Idea

[Baker]

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.

[Baker]

I've done some more work on a mini-map generator:

[Willem]

Baker, you're a head case. Fucking awesome stuff, man.

[Spirit]

I have no idea but maybe the fancy bsp2bmp tool could help?

[mh]

[Baker]

[scar3crow]

[mh]

[Spirit]

[Baker]

[JasonX]

[Baker]

[Tomaz]

[Baker]

[mh]

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).