-
Notifications
You must be signed in to change notification settings - Fork 10
Light baking (WIP)
Theres two types of maps you might want to light. Existing maps without source files or your own maps with source files. Working on your own maps is a little easier as you can skip preparing lightmap texture coordinates for a proper bake. If you are not familiar with the id Tech 3 lighting techniques, read the "Lighting overview" paragraphs down below. Always import your bsp files with the primitive packing setting for proper vertex color bakes.
This only requires one additional q3map2 compile flag. The "-nocollapse" light stage flag will make sure your surface lightmap texture coordinates won't be stacked on top of each other when lighting on surfaces is concidered equal. Stacking surfaces based on the q3map2 lighting algorithm will lead to incorrect light bakes in Blender because it won't match in Blender most of the time. This will create more lightmaps than without this flag, which might get you in trouble with the limit of 255 lightmaps per map. In order to work correctly you have to have some lights in your map before compile. They don't have to match your vision for the lighting as lighting will be completely redone in Blender. If you already have a proper light rig, you can import all lights later via the .map importer of the addon. Just use the "Only lights" setting.
Working on maps you can't simply recompile with q3map2 is a little more complicated. Using an addon for uv packing with UDIM support is recommended as doing this manually is a tedious task. A free addon you can use is UV-Packer. The main workflow for this looks like this:
- Open the "UV Editing" workspace
- Select the "LightmapUV" UV Map in the top right corner of the UV Editor window
- Repack only the surfaces where all vertices are part of the "Lightmapped" vertex group into UDIMs of the same dimension as the lightmap atlas
- Scale down the uvs into [0 - 1] range
Just do your thing. Just make sure to configure the viewport color management properly before working on lighting. id Tech 3 does not support HDR lighting so working in the correct exposure level is crutial for good results. For engines with mapoverbrightbits set to 2 exposure needs to be set to 2.0. Engines without overbrightbits need to be set to 0.0.
Once you have prepared eveything, open the Patch BSP Data panel under the "ID3 Editing" tab and follow the instructions.
id Tech 3 uses three different lighting techniques. Vertex colors, Lightmaps and a Lightgrid. Each of these techniques is used for different kind of surfaces. Theres two catergories of surfaces. Static and dynamic. Surfaces stored in the bsp files are considered static, even if they can be moved like doors or elevators. Players, NPCs and props like health pickups are dynamic surfaces. There are exceptions in some engines like in the Ravensoft fork (EF, SOF2, JO, JKA) with entities like misc_model_statics or misc_model_breakable. Those are also considered dynamic, even if used statically. All dynamic surfaces are lit via the lightgrid. The static surfaces are lit via vertex colors or lightmaps. Misc_models are converted on map compile to static surfaces. The static bsp surfaces are also categorized in different types. There's mainly planar surfaces, patch surfaces and triangle soups (mmmmh, yummi). Brushes are stored as planar surfaces, patches as patches and misc_models as triangles. Misc_models can be stored as planar surfaces with spawnflags 4. This can be a bottleneck though. Planar surfaces are limited to 64 vertices per surface while triangle soups to 999. This means that with spawnflags 4, misc_models are likely split into more surfaces than before. More surfaces means more drawcalls, which may degrade ingame performance.
Surface type | Subtype | Lighting type |
---|---|---|
Dynamic | Lightgrid | |
Static | planar | Vertex color or lightmap |
Static | patch | Vertex color or lightmap |
Static | triangle | Vertex color (or lightmap in some custom engines) |
So what is a lightgrid? You can think of it like a 3d grid. It splits your bsp world into evenly spaced chunks. Every chunk stores a minimum light value, a maximum light value and a direction where the maximum light value is coming from. So it stores light for every point of your map. The resolution of this grid is quite small because of size constraints. Most engines default to a step size of 64 units for the x and y axis between the chunks and a step size of 128 units on the z axis. Lighting on a dynamic model will be computed based on the 8 surrounding chunks of the models origin. Some entities allow for shifting the lightgrid lookup point on the z-axis with the "zoffset" key. A "zoffset" value of 64 will move the lookup point 65 units above the models origin. To use the lightgrid in id Tech 3 shader files, use rgbGen lightingDiffuse
Lightgrid samples visualized as little spheres in Blender on mp/duel8 from Jedi Academy
Vertex colors are just colored vertices. When rendering a model with vertex colors, the colors will be interpolated over the surface. To use the vertex colors in id Tech 3 shader files, use rgbGen vertex or rgbGen exactVertex. Consult the shader manual on usage.
Vertex colors visualized in Blender on mp/duel8 from Jedi Academy
Lightmaps are images. BSP surfaces that are lightmapped have additional texture coordinates for using the lightmaps like regular texures. Most id Tech 3 engines default to lightmaps of 128x128 pixels. Multiple lightmaps can be stored in a bsp file, so surfaces also store an index to the lightmap that corresponds to the correct surface. Lightmaps are images you can use with map $lightmap in the shader files.
Lightmaps visualized in Blender on mp/duel8 from Jedi Academy