Shedding light on Quake I and II lightmapping 

You made me laugh.

@@hylianbran7273 good to see i, brightned someones day

you must feel enlightened after watching this video, don't you?

Same. I made a few Q1 levels using TheForge/WorldCraft back in the day although I was a teenager and was just messing around, never made anything that I released to anyone else. I remember when the Tenebrae engine released, and was able to make some interesting levels by playing around with the updated lighting and bump mapping effects even if the game was basically a glorified slideshow for me.

Half life's lightmapping system is exactly the same as Quake's but with color support. You can trivially modify GLQuake to support half life's lightmaps. Internally they used quake 2 style radiance when compiling

Yes, I left that one out for brevity but I agree it adds a lot. In short each face can have up to 4 separate lightmaps, one for the base light and one for each animated light that is near it. At runtime the individual lightmaps are scaled and added together.

A way to think of it is that instead of a single lightmap, it calculates three lightmaps. Each lightmap is made the same way as you'd make regular lightmaps, but instead of using the surface normal you use a normal that is calculated from the surface normal rotated a bit to look at some other direction - and when you look at all three normals (that is the normals used for each lightmap) they are all perpendicular with each other. Then when you're rendering you just mix the three lightmap values based on the normalmap's normal. Valve published a paper back then that mentions exactly how they calculated these normals (you could use any three normals as long as they look away from the surface and are perpendicular with each other but Valve already did that part so no reason to not use theirs :-P). I implemented this some years ago in an older engine of mine (if you check my channel you can find a video with it titled "Directional lightmaps" from 7 years ago), it works remarkably well (the video has zero dynamic lights, even the specular is precalculated by averaging the light directions and storing the XYZ values of the direction normal it in the alpha channel of each lightmap - this was a hack though and could certainly do a better job with it, like ignoring lights that do not contribute much and taking into account the surface color).

Current Q3 map compilers support it. Shortcut name 'deluxemaps'. Games like Warsow or Nexuiz make use of them, but Q3 itself doesn't support rendering them so they aren't of much use there.

You're welcome. Play it immediately, then play Arcane Dimensions, a true masterpiece by fans.

Fun fact: GoldSrc was based on the Quake 1 engine - id Software effectively gave them the source of Quake 1, without having penned down a contract or anything - simply based on the faith they had in Gaben & Co.

​@@NostraDavid2 I knew that years ago.

Quake 3 had higher quality lightmaps, i think it is 128x128 by default. Also, it has overbrightbits, which kind of simulates HDR Lightmaps, but it's not as pretty. Years later Half Life 2 used real HDR lightmaps, which are much nicer looking. Fun fact: you can actually inrease the lightmap detail in quake 3 using q3map2, and converting with external lightmaps. This makes some nice sharp edgees on shadows.

Well, he is better than decino. Decino doesn't try to explain Doom technical side, or explains it rarely (kudos for him fixing Serious Sam notorious bug).

From what I know, all Quake store their surface not as polygons, but as surfaces. The surface equation is A*x + B*y + C*z + D, where A, B, C are coordinates of orthogonal vector to the surface, x, y, z are coordinates of any point on surface, and D is coefficient, determining the offset of surface in 3D space. All surfaces with equal normal vectors (A, B, C) are parallel each to other. For surface storage in .map file you need only 4 numbers (A, B, C, D), so you can create later polygons in map compiling stage to .bsp file.

Valve VRAD is the derivative of Quake 2 lightmapper. It strongly differs from it, because it calculates indirect lighting and stores that information in so-called "ambient cubes" (simplified kind of spherical harmonics). These cubes allow to shade dynamic objects. Unlike Quake 3 light grid, these cubes are distributed not on 32 * 32 * 64 units grid, but on visleafs edges.

The 3d texture part is the lightgrid, which coincidentally was also added in the Q2 Remaster. Maybe we'll get another chapter explaining what changed with Q3 on that front - the Q3/idtech3 at large modding community also introduced some interesting light compiler development which surely must have influenced ericwtools we use today for Q1/2. I'm thinking of q3map2 with some work by ydnar et al. introducing phong, refining bounces and filtering options, etc.

It would be a hell to debug such engine. That's why engines are designed with customization in mind. E.g. Open 3D Engine Atom renderer allows you to implement custom render passes.

Well spotted! The exact algorithm for shifting the hidden points is here: github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L270 . It looks like it shifts 8 units in the vertical axis first, then 8 units in the horizontal if the shifted point is still not visible. If after that it is still not visible then repeat the whole thing, for up to 6 iterations. I never got to the bottom of why this exact behavior was selected.

@@MattsRamblings I see, that sounds very arbitrary but if it works most of the time and performs well I guess it makes sense. Thanks!

​@@meanmole3212 @MattsRamblings i think the same is done when there is a light grid system that uses probes( cube-maps ) in order no to have proves within wall or in the wall edge ( which would contaminate the final light calculations with wrong data ), the proves are moved within the correct space for the rendering and as well as for their final position, being kept out of the gird, and if their position needs to be corrected a lot, I think they are discarded

Yeah that bit sounded weird to me too. I also implemented lightmaps years ago in an older engine and this is something i faced. Personally i solved it in a different manner: when i take a sample i check if it is part of a polygon face (*any* polygon face, this is because two polygons might share an edge in world space but use different lightmaps and the sample might end up over another polygon) and the face has the same normal. The sample is ignored if there is no polygon for it (e.g. lies outside the world) or if there is a polygon face with a different normal (failed at corner or there is another polygon covering it - e.g. imagine a box on a floor, the floor samples below the box would also have the box's faces on them). For each lightmap i also keep track of a mask for the lumel that had no samples contributing to it - after all lumels with at least one sample have been calculated, i go through all lumels with no samples and calculate the average color of the lumels with at least one sample that surround them and set their mask as if they had a sample. This is repeated until all lumels are set. Making a lightmapper that looks ok is easy but fixing little issues like that is almost 90% of of the work. No surprise that many lightmappers even to this day have edge cases (though these days you can bruteforce your way by calculating something like 32 or 64 rays per lumel, which hides a ton of edge case issues). Unreal Engine 1 had these "black corners" which weren't solved until UE2 and i remember reading environment artist tips about cutting the bottom of models in UE3/UDK to avoid the black outlines in floor lightmaps. These days i'd probably look into voxelizing the world and calculating lighting from that instead of using the geometry directly.

You can precompute lightmaps with blender, if that helps.

Moving objects such as doors do not change lighting when they move; they'll look the same even when moving to an area with very different lighting. Flashing, flickering, pulsing, or otherwise changing lights are done with a "style" value that the mapper sets, each of which is essentially just a list of brightness values stored as a string of letters which are computed during compilation and cycled through at runtime (fun fact - Valve still uses these strings to this day, resulting in lights in Half-Life Alyx that flicker in exactly the same pattern as the ones in Quake). Lights that can be toggled on and off through ingame events work in a similar way. In order to reduce the amount of additional work the compiler has to do, there is a limit of 4 light styles (including toggled lights) per face, and ericw-tools also disables bounces on these lights by default. The Quake 1 and Quake 2 rereleases contain their own dynamic light system which is rendered separately and on top of the lightmap, which allows for crisper shadows that can move with things like doors and rotating objects.

​​@@henryambrose8607Easily explains why a door's edge is completely black when is opened! If the commenter meant "3D Model", I guess it uses basic vertex lighting.

@@henryambrose8607 Great answer. I was also actually talking about say monsters in the middle of the room. Now I know they won't have very fancy lights, but is the light at the center of the room precalculated in any way?

​@@aussieexpatwatches Things like monsters take a light value from the world geometry directly below their origin. This excludes things like doors and moving platforms. This value is then combined with the vertex normals to make it lighter on one side and darker on the other, so it looks like there's some directional lighting.

Vertex lighting. It's a very basic method. There is a lightgrid precomputed at map compile which subivides the space in in a 3d grid of points. Each point has a precomputed light direction. When lighting the model the light direction is calculated from the grid and applied to the model vertexes. It doesn't allow for 2 lights to be displayed on the model, just averages them. This works the same for Quake I, 2 and 3

It simply is tracing rays into a (simplified) scene. The only thing that matters is that you're doing it before shipping your game & the results won't change at runtime, so it's static. Something that only matters to dynamic objects that can move around and should therefore change the lighting.

It's not fully lambertian. The effect is actually scaled by a half - see the `scalecos` term here (which is fixed to 0.5): github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L410

It's proprietary and source-closed, it's not worth to work for free to Valve inc.

​@@CapewearerActually 🤓, Source Engine is technically open-source, you only pay if your mod is paid, if your mod if completely free then the source code is there, it's obviously not the complete code that Valve uses but it's has a lot of things. And yes, this type of lighting is already in Source, there are other compilers that improve VRAD such as Slammin' Source Tools, which adds Ambient Occlusion, support for more threads, improved Radiosity algorithm, faster lightmap compilation for static mesh models (displacement maps for example), and alpha textures shadows support.

@@gustavodutra3633 take a look for license, you'll never own this engine sources unless you pay a big money. It's not open-source, but source available, and you probably meant SDK (which is not the whole engine).

you're making some p. strong assumptions about how common and capable gpus were back in the 90s the original release of quake didn't even have gpu support; glquake was an update id released half a year after the fact

OK zoomer, great plan! Remind me again, which GPU should we be using...in 1995?

I'm not limiting myself to 95 cpu's, use silicon graphics workstations, or a cray super computer time, if you lack now or then, ID@@GarrettInShadows

why do you assume that the task would need to be completed with an 95's cpu or gpu, well you have those dual voodoo2 cards and nvidia's first cards are starting to pop-up, amd rage pro etc@@hi-i-am-atan

and intels cpu package for ray tracing supports which cpu's, there is something rotten here with the "needs to be this-and-this" attitude@@GarrettInShadows

It's proprietary.

how did you gather that?

@@averesenso all machine generated "press-release text" has a lot of similarities things like overuse of adjectives and descriptors, "passionate community" when speaking about literally any group, at least one bad corporate presentation pun and it always ends with some variation of it telling you to get ready for a journey into XYZ