User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive
 

Description

this is the page for the Legacy Fail Safe Build at adminless.ovh of the original release of the idsoftware Q3Map tool from the original Quake 3 1.32b GPL source code release (quake3-1.32b-source.zip). before you get started please have a read first at the introduction article at this category here to know what these Legacy Fail Safe Builds at adminless.ovh are about.

Q3Map is is the idtech3 map compiler, i.e. is the tool which takes a map source file and produces a bsp file to be loaded by the engine. typically this process involves three phases:

  • the bsp phase: is the initial step where all the map binary geometry is created from the map source geometry (text)
  • the lighting phase: in this step is where the map gets illuminated, this process is very computational intensive and complex, even till this day map lighting is something that still remains as an work in progress problem
  • the visibility phase: final step where actual player visibility is computed for each cluster in the map this allows the game to only render those clusters who are actually visible for the player, instead of the whole map, hence greatly improving the performance

beside map compiling this tool has also some other extra functionality like texture and/or entities replacement. this is the 1999 version 1.0s of Q3Map apparently this looks like a alpha unfinished release (a development release) to me however is fully functional and it looks like it was the one which was used to create the final version of the game.

Recommended Usage

the Q3Map program can take several parameters, I was unable to find its specific documentation (if it's that ever existed and/or was released) all I was able to find in some radiant package (I haven't tried them all) was this manual here for a higher version than this 1.0s, however to get a notion of the general program usage it can be a starting point.

anyways most of the program parameters aren't really of use and some of them doesn't even work so the typical usage is as follows:

    q3map [-notjunc] q3map_file && q3map -light [-extra[wide]] [-notrace] q3map_file && q3map -vis q3map_file    

where braced parameters are optional parameters. this version contains the old and well know extra (and extrawide) lighting algorithms. the notjunc and notrace parameters are optional parameters only supposed to be used in case the junction or shadowing algorithm malfunctions (happens in some maps) respectively.

Experimental Usage

in addition to the regular lighting algorithm wrote above (-light parameter) is introduced in this release a "new" lighting algorithm (-vlight parameter). this "new" algorithm make use of volumetric lighting as well as also multipass lighting (radiosity) and it's mostly supposed to produce a much more realistic and sharp lighting however all this code here is still in a very early state (experimental), this code didn't really mature until years later for the release of the the Wolfenstein: Enemy Territory game, so if you're looking for a more realistic touch of the game or multipass lighting you're better looking for a newer release than this one.

anyways, it seems that the overall outcome really depends on geometry, textures/shaders and amount and type of light of the map, in the case of neatly textured and bright maps you may give this a try however for the usual gothic ambiented maps seems to work better the classic algorithm. this algorithm also seems to be useful to have quick test compilations since is generally faster and it's generally enough to get an idea of how it's going. then in case you want to try with your map a experimental lighting phase command line will look like this:

    q3map -vlight [-radiosity i] q3map_file    

where the radiosity parameter is optional for multipass light and i is a whole number (integer) noting the number of passes. as for this multipass parameter note that as mentioned this is all very experimental code here yet and I found out that it actually overflowed and diverge instead of converge most times for any value above the first pass. I spent some time taking a look at the code and I applied some minor tweaks to it so I believe that it should now converge most times instead, however note that all this is still very far from perfect.

Download

now here on the list down bellow you have the relevant files to download:

this release has been tested with a bunch of maps so I think that it's known to be working and be stable, if you want to check how maps look like compiled with this tool you can download the bsp's for the sample maps from the q3radiant package compiled with it in the bellow links:

 

q3dm1sample.bsp q3dm7sample.bsp q3dm17sample.bsp

 

to test those sample maps you may need the full version of Quake 3 and/or optionally you may give a try a to this high resolution texture replacement pack you can download from here. to load those sample maps all you have to do is put those bsp files in a maps folder inside your game folder (ex: ~/.q3a/baseq3/maps/q3dm1sample.bsp) and then on your game console do \sv_pure 0 and simply load the map (ex. \map q3dm1sample).

Known Limitations

as already said this is a early version so it has several limitations, nevertheless, most of these limitations can be easily workaround and some of these limitations are as follow but bear in my mind that this list doesn't pretend to be comprehensive so you may experience another ones, shall be the case feel free to leave your findings in the comments:

  • the compile route where's located the map source must contain both a quake string and a game subfolder (ex. q3map ~/q3map/quake3/baseq3/q3dm1sample.map).
  • pk3 support (zip support) is broken meaning you have to work with the unpacked files (i.e. unzip them).
  • it only supports tga images, nevertheless something like the command bellow (guessing you have imagemagick installed and your images names doesn't contain spaces) and minor shaders/scripts/textures renames/changes should do the trick in no time at all:
        for f in $(find ~/q3map/quake3/baseq3/ -iname *.jpg); do if convert $f ${f:0:$((${#f}-4))}.tga; then rm $f; fi; done    
  • ase model support is also broken. this one is a little trickier to be honest, ase models (in contrast to static md5 models) is the technique that was implemented in order to simplify the process of adding repetitive complex map geometry to a map and consequently many "modern" (above 2005) maps make use of it. if you're working with one of these modern maps you better go for a respective modern q3map version, all this ase model support was officially added and released for the q3map version corresponding to the free game Wolfenstein Enemy Territory. if you don't, your best shots are finish off the ase support code (most of it was there) or if not convert your ase models into md5 models, both of them not really recommended.
  • as mentioned above in the article, the radiosity lightning code is very experimental and while I tweaked it a bit to converge and work for any value above 2 or 3 is not even guarantee that it does. again like on previous point this more realistic lighting code wasn't really finished until the Wolfenstein Enemy Territory release so if you're looking for this kind of lightning you better finish that code yourself (or even better customized it to your very own specific needs, recommended) or go for a newer q3map version, this version is mainly intended for that classic old school "gothic" lightning style of the classic maps.

Add comment


Security code
Refresh