Ooops, excluding the times that I have play-tested my own map, I haven't played Quake for years. 

So I'm just packaging the map for OneTruePurple to play test for me and have a quick look at the darker areas of the map and holy smoke, there's coloured banding all over the dark corners - there'a lot of dak corners as it's a 'cavern' map.

I've only seen these areas after quick Light and quick Vis and they have never shown up with this banding before. I thought running the Utils full-on was supposed to improve the quality?

I used my i7 laptop Nvidia with latest drivers, and my Pent4 with ATI, and they both show the same soddin' thing. What gives? (rhetorical question, I just need therapy) 

 

No, I really am cracking up. Four years ago I used the same computer, same video drivers, same utils, same settings, and the same map file (FMB_bdg). The FullLight/FullVis I did then produced a perfectly acceptable dark-corners map with no banding - I have the original bsp output file, I've checked it.

Now, the only thing I have added since then is the Skip util; I didn't use the Skip texture in the map but it runs automatically as part of the batch file for a FullVis.

Can anyone shed some light on this (not too much in the dark corners though)?

What seems quite rediculous is that I can run a quick Light/Vis and there is no banding. As there's also no grey-flash or snagging etc, should I just release it not fully Vis'd.

Is that heresy? 

But you should be able to run light independently of vis anyway - removing the banding by having the x4 or whatever turned off.

So you shouldn't need to re-run vis to regenerate the light map. I think. 

Just re-do light. 

What's this about banding - care to post a screenshot?

Btw, if you still have the original .prt and .vis files, you can fix certain things that require a QBSP recompile (texture errors to a certain degree, bmodel positions) and simply insert the fullvis information on the fly. 

First, this is a cavern with sculpted walls and fog.

The first picture shows -fast Light and Vis, the second with the banding, was -level 4 Light and FullVis.

http://s17.postimage.org/7zui23axr/fitz0000.jpg
http://s24.postimage.org/ytgmq1tcl/fitz0001.jpg 

your video card is set to 16bit rather than 32bit!

Weird, did you change the video settings? 

that has nothing to do with lightmaps 

No, both of those shots were taken today on the same laptop computer within a couple of minutes of each other; not more than 40 minutes ago.

The card in the laptop is definitely set to 32 bit. 

To benchmark? 

How does it look just with -extra (not 4)? 

That looks like a fog error, doesn't it? I can't imagine that has anything to do with his lightmaps. 

Shots taken in the same session or different sessions?

If different, launched with the same shortcut or batch file, or different shortcuts/batch files? 

That's probably gamma or brightness or something like that. Both look terrible on my night time red tint and 0.8 monitor gamma setup. If I disable that, the first one is find. 

it really does look like 32bpp vs. 16bpp to me. Even the down to the discoloration on the statusbar graphics in fitz0001 

A similar thing when using the SetGamma utility - which I use so that the worldcraft 3d window isn't too dark. 

Not the same session of FZ. Because I was running from batch files, I closed the FZ session between maps.

You might be pointing me in the right direction: I will now go and check the two batch files for differences in calling the -game and -map. 

From the config file:-

vid_bpp "32"
vid_fullscreen "1"
vid_height "768"
vid_refreshrate "60"
vid_vsync "0"
vid_width "1024"
viewsize "100.000000"
volume "0.7"
vid_restart
+mlook


However, one of the batch files has -bpp 32 in the command line it produces, and the other does not.

If I run the maps from the same FZ session using the command line with the -bpp 32, NO BANDING!

Is it correct that the config file does not take precedence over the command line? And is it correct that with no -bpp 32 in the command line, the entry in the config file is ignored?

And I suppose the default -bpp is 16? 

default bpp is 16, yes (glquake legacy, probably should default to 32 now)

if any video options are on the command line (-window, -width, -height, -bpp, -refreshrate) then the config file is ignored and the command line settings are used.

Otherwise it should use the config file during startup.

You can always verify by looking at the console for something like "video mode 1024x768x32 60Hz initialized" 

Got there in the end. Thanks.

But now the end is near and so I face the final curtain...

Stand by onetruepurple, it's on its way of that I'm certain (well give me a day or so to recover from this trauma) 

an autoexec.cfg file for your settings so it always uses the settings you want. (I don't know why it doesn't always save) 

Does anyone know why some editors have different texture projection axes which made it necessary to have -altaxis/-oldaxis on QBSP? Was it just a mistake or was there some reason for it? 

Note : TreeQBSP behaves slightly different than other QBSP variants. To make it behave more like
the others, the following command line can be used :

qbsp -oldaxis -oldleak [mapname]

In most cases, the new style leak line (default) is considerably easier to follow in Quake,
but if it doesn't seem correct (e.g. the line goes right through solid brushes) you might
want to try the old style line. You can always use the "-leakdist #" option to reduce the
amount of dots in pointfiles. If Quake cannot load the entire pointfile, use the Quake
command line option "-particles #" to increase the capacity.

Also, transparent water is not default (like in TxQBSP), but can be enabled via the
"-transwater" option. Beware of the performance hit in some maps.

Some lighting problems might occur when using most light tools together with a compiler
that supports enhanced texture positioning (e.g. QuArK ETP or Valve 220 Hammer). Light 1.27
and TyrLite 0.94 (see Tyrann's site below) or later versions support ETP.