Rendering/Lighting between Quake 2 and Quake 3

[marscaleb]

I'm just feeling curious about some technical differences between the Quake 2 and Quake 3 engines.

Today I was looking at a Quake 3 map that was styled to look pretty close to a Quake 2 map.  I don't know exactly what the difference is, but it showed that the way things were rendered in Q3 were profoundly different than Q2.  It wasn't just the color depth of the textures, but it was something else.  Maybe it was the lighting, but I'm not entirely sure how.  I mean, strictly speaking the lighting is calculated through a secondary program, so theoretically couldn't you have some highly realistic lighting computed for the game's lightmaps?  But yet everything in Quake 2 looks so much grittier and darker than Quake 3.  Would it be possible to bake the lightmaps in Quake 3 to Quake 2's standards, and give it that same gritty look?  Or is there more at play that has changed the rendering between the two engines?

[knightmare]

I believe the lightmaps in Q3 are higher-res than those in Q2. Q3's default texture stretch is 0.5, where Quake2's is 1.0. In Q2 at least, smaller scaled textures (i.e. shrunk) also have more detailed lightmaps (1/16th texture resolution).

Also, the curve patches in Q3 are not lightmapped, but use vertex lights instead. You can see something similar with warp surfaces (water, slime, etc) in KMQuake2 that are vertex-lit, but they use runtime-generated light sampling, not light values baked into the BSP like Q3. This is because warp surfaces in Q2 don't have any lightmaps, and are rendered as fullbright (no lighting) in vanilla Q2. Some licensed Q2 engine games such as Daikatana add lighting to warp surfaces as well.

[marscaleb]

Hmm, so do you think Quake 3 would look the same as Quake 2 if you just reduced the light map resolution and didn't use curve patches?

Also, am I right in my assumptions about how the lighting works? I have very little experience making Quake maps. When I tried to get into Quake mapping the other year, I noticed that the lighting was calculated through a secondary application, so it seems to me that you could just grab whatever program you want (that exists) and so I'd imagine the lighting calculations would be the same between the two games if you used the same program. Is this correct, or do you actually need different programs to generate lighting for the different engines? Do the light entities and lightmap calculations actually work differently between the two games?

[knightmare]

Possibly if the same textures were used. Q3 also ditches Q2's lightstyles and switchable lights due to network traffic issues (which were already disabled in DM).

Q2 and Q3 have different BSP formats, so yes, they have to use different utilities for lighting (qrad3 and q3map, respectively). They're not interchangeable, and neither could you use the HL2 light util (vrad) for Q2 or Q3 maps. Daikatana and Sin even have their own set of map utils for their altered BSP formats.

[marscaleb]

I get that the BSP formats would be different, and thus they would need different code insofar as compiling the data is concerned. But prior to compiling the final file, I would imagine these should all be interchangeable. I mean, most of the level editors explicitly work with a number of different games because they save the map data in their own proprietary formats, and those map files are just the data for the brushes/shapes and then compile and bake all the data into the formats needed for the games. Thus you could build level geometry for the original Quake but later decide to change it to Quake 3 without having to rebuild everything from scratch; one would only need to handle any items that are outright not compatible with another version.

And I'm thinking that the lighting should be basically the same. With all the light sources saved in the map, one could theoretically build the lighting to any number of different models. From simple linear casting to multi-level ray-tracing that calculates bounce lighting with added color to match textures. After that it just becomes a matter of then saving that calculated lighting into the format needed for the game. So if I used a lighting program that tried to calculate bounce light color, it would have little impact in a Quake 1 map since the lightmaps don't have color data. If I make highly detailed lighting calculations and then try to save it in a game with low-resolution lightmaps, well then I just wasted that effort. Hence why these older games use much simpler lighting calculations. (That and the build times.) But theoretically it would be possible to do so.

Or am I wrong about that?
And if I am wrong about that, then what is so different about the lighting tools between these games?

[knightmare]

It's theoretically possible with a modified engine that reads an external lighting file corresponding with a bsp. Many Q1 engines support this via .lit files for colored light.

[marscaleb]

No I meant as just a different way to calculate the lighting, as in, a different way to generate the lightmaps that the engine uses, not how the engine uses those lightmaps.
Not that it really matters anyway; I'm just trying to understand how these things work, rather than design a new system.

Well, sort-of not interested in designing a new system.

I've got this desire to make a low-poly shooter. I don't think I'm going to work on it just yet, but I can't get it out of my head, so maybe after I finish this other project I've got going on.
And when I think of what I would like to make it with, well, there's something about the Quake 2 engine that just looks right. I don't know what it is, but it is something with its visuals that just feels right. Quake 1 and UT99 come close, but Quake 3+ and Unity and UE4 just don't quite capture the right feel, and I can't get them to look quite the same way that Quake 2 does.

So I lean heavily towards building this game from Quake 2. But that would bring a number of limitations with the net code. So the last day or two I've been curious if it would be possible to get Quake 3 to properly capture that "feel" that Quake 2 had. And I thought maybe it was in the lighting. Maybe if I could get Quake 3 to reproduce Quake 2's lighting, then I could build the game from Quake 3 so I could use its better net code.
But I guess the differences between the two engines is greater than I had anticipated.