Anyone played with these yet?

I tried dumping textures from the maps in pak1.pak with the bsp2wad tool, renaming the wad to whatever is specified in the .map, then running qbsp, vis and light in hopes of obtaining a .bsp identical to the original one, the one in pak1.pak. I used the qbsp, vis and light from the GPL Quake tools release (q1tools_gpl.tgz).

Now what I'm getting is very very similar to the original, but not quite. First, I'm always getting a slightly higher plane/face/vertex etc count (say 1003 vs 998) than in the original, as shown by bspinfo. Second, the lightmaps are a tad brighter.

That's weird because Romero's .maps do look like the original ones. The compiled maps are the same geometry-wise: I tried playing with a recompiled map on a server running an original one (checksum verification disabled), and it plays and feels all right, no prediction errors. Also the entity lumps in a recompiled map are 100% identical to the original.

So I'm guessing that either the qbsp included in the GPL tools release is different from the one used to compile the original maps (although it seems strange that a newer version of the tool produces higher plane counts), or that the C compiler on whatever architecture id used (DOS or Unix variant) produced slightly different code for floating point calculations, so their qbsp happened to produce slightly different bsps.

Okay, the bsp stats are not all that important because the checksums of GPL bsps will fail anyway because of a different texture set, but why the different lighting?

You can specify quite some options on both the light and the vis tool (and the qbsp tool probably too). I am sure id used different settings for some maps, I don't think they remember which.

Eg:


Sajt from www.inside3d.com seems to be deep in bug fixing & compiling the maps already. I'd suggest you talk to him about "official" builds.

There are a few things to note about the qbsp used for the official maps.

Firstly, the skys... Their qbsp considered sky surfaces as solid. They later changed this but didn't recompile all the maps. So that might explain the higher counts a little bit.

They also compiled on an alpha machine or whatever it was... Not an x86, so the fpu precision is restricted to 64bits max, not 80bits like the x87 provides. This will almost definatly have an effect somewhere (probably resulting in higher-precision inaccuracies!)

Light.exe has a few interesting quirks. When used multithreaded, it generates output in an almost random order (based on which thread finishes it's surface first).
Also there's an extra commandline option not mentioned in Spirit's post. -scalecos [scale] (I think). Which affects how much light levels are scaled based on direction of light, which is probably used more on the medieval levels. This definatly affects light levels.

Spike, you're the man! Sky's solidness sure affects poly counts!

[Stupid Question Mode On]

Why do you want they to be exactly the same?

[Stupid Question Mode Off]

vegetous: Coz it would make the maps 'truer to the original' Not that you would ever notice the difference, and it won't help the checksum anyway.

Okay, so Spike is right and I can get identical face counts when using a patched qbsp that treats sky brushes as solid. This also helps lighting: it turns out that the difference was due to a light source in a sky brush, so it was ignored by the old qbsp.

Here are two screenshots for comparison: the original dm6 we all know and love and dm6 compiled with sky-aware qbsp:

Original:


New (sky-aware):


Note the brighter roof textures in the second screenshots.

Now here's a screenshot of the GPL map compiled with a patched "sky-is-solid" qbsp. Yes that's right, it's indentical to the original!


The textures will of course be slightly different if we use QRP textures to build a legal GPL map, but you can expect it to look VERY familiar (check out the QRP screenshots: http://facelift.quakedev.com/retexture/)

compilers versions? or .map file format also matters... i use valve map format make the .map very bigs but with less bugs :\ dont know if in that time there were many options of map format and compilers :\ i use all bengt tools

It just dawned on me that different lightdata lumps result in inability to load .lit files
So producing an identical .bsp does matter after all.
Constructive feedback is welcome

I think it's worth mentioning that Sajt from www.inside3d.com has created a program called "Cobblin", which you can load all the quake map files into it and work on them at once. They (coding community from NQ) are planning on make a quake.bsp, a map where all the quake maps are connected

check out www.inside3d.com for the info (and make sure you see the potd)

Skybox talk reminds me that we are now able to get rain in id maps, exclamation mark.

sif you can't with vanilla id maps
just look for faces with sky textures instead of CONTENTS_SKY brushes

Even if we were to have the exact same tools, we'd never manage to recreate the exact thread timings used in light. We will not manage to get the light info in the same surface order. Not without depending on non-gpl at least.
I believe their Alpha machines have four cpus.
Well, we would end up with a lightinfo segment the same size, it would just be in a different order. Why do you think those fuhquake lits have lighting quirks?
FTE's relight feature uses the surface light offsets rather than calculating it's own - it's the only way to get it reasonably compatable. That's not really an option if you want to stay GPL.
I will be very very impressed if you get it any closer.

FTE's relight feature?!!

fte's r_loadlits 2 feature, which generates lit and lux files (lux files being deluxel info for bumpmapping). I only mentioned it because it seemed relevent to point out that it can't output the data in a linear order, but has to use the offsets the surfaces state.

What about this solution ...

I saw that thing about the .lit file problem. Rather than recompile the maps, have you considered merely RE-WADDING the ID versions of the .bsp?

Updbsp[/g]

[b]"Updates the textures in a BSP (Quake) file from a WAD file, creating a new BSP file."

Download: http://www.quaketerminus.com/tools/updbsp.zip

Since that doesn't actually recompile the map, there should not be a LIT file problem.

Yeah, that's one possible option.

I feel a bit uneasy about it however, as it doesn't really follow the letter of GPL where you're supposed to be able to produce the exact same binary from the sources.

But them you'll be using the compiled bsp instead of the GPLed map source. And I don't think it's legal!

do you think id can prove that? or follow what we're doing? or really care?

I think this thread is about the building of 100% free and legal versions of the classic maps. And I don't see the point of have all this work to end with a illegal version of them.

well, as i see it.. if you strip the copyrighted textures from the bsp, you have a free legal map. can anybody prove that dm4.bsp for example wasn't compiled from the .map file? i don't think id would ever bother to find out..

The fact they can't prove it's illegal, will not make it legal!

here in Romania we have a saying that goes loosely like this "a thief that hasn't been caught is a honest business man"

Yeah, I was thinking that as well as I was posting it. Still, it is a potential solution that certainly is well within the spirit of the Quake source release.


It's too bad the big minefield of things that are techncally not legal, if one wants to follow "the book" exactly. Aerowalk has ID textures, for instance, even most maps that don't have (hardly any) ID textures -- like UltraV -- still use the ID teleporter texture or ID water texture or the stock ID sky texture.

Aerowalk and ultrav don't pretend to be GPLed.