Bake accuracy

RED+ bakes with RED's own lighting commands and corrects the places where RED's lighting comes out wrong. Every correction on this page is on by default and needs no setting. Most take effect at the next Level›, Calculate Lighting. One, faces that share a lightmap, takes effect only when lightmaps are laid out again, with Level›, Calculate Maps and Light.

To compare with RED's own result, Command-line switches lists the switches that turn these corrections off.

Light through thin walls

RED lights a face that points away from a point, spot or tube light with part of that light. RED+ traces a shadow ray for that part too, and anything in the way blocks it, including the far side of the wall the face belongs to.

• Light from the far side of a thin wall or board does not reach its back face, and an object behind the wall does not cast its shadow there.
• The back faces of thin walls and boards lit from the other side come out darker than in RED.

Takes effect: Calculate Lighting.

Shadows across corners and gentle bends

Where two faces meet at an angle of up to 45 degrees, RED works out each face's shadows at its own texels, a little way in from the edge. The two faces then disagree near the edge, and a shadow crossing the corner can stop in a straight line.

• RED+ gives the texels in a band along such an edge the shadow found at the edge itself, the same for both faces.
• The band is 1.75 texels wide, or 0.25 m where that is wider (at High and above).
• Each face keeps its own brightness from the way it faces the light. Only the shadow is shared.
• Where something covers the edge, or lies flush against one face and not the other, each face keeps its own shadow.
• This applies to point, spot and tube lights.

Takes effect: Calculate Lighting.

Texels on smoothed surfaces

On a surface where any face has a smoothing group (Smoothing Groups in Face Properties), RED works out each texel's position and direction from the faces around it. Next to very thin faces that can go wrong, and some texels come out far too bright (up to white) or too dark, in hard-edged patches that move whenever the geometry is rebuilt.

• RED+ checks each such texel against the face it lies on.
• A texel whose position is more than 2 texels from its face, or whose direction is broken or more than 60 degrees from the face's, takes the face's own position or direction instead.
• Every other texel is lit as RED lights it.

Takes effect: Calculate Lighting. After a bake the log has a line containing [RF+ Lightmap] smoothed-path texels: that counts the surfaces corrected.

Faces that lie almost in one plane

RED gives faces one shared lightmap only when they lie exactly in one plane. Faces that sit flat against each other but very slightly bent, such as a brush face made of two slightly bent triangles, each get their own lightmap, and a shadow crossing the edge between them does not line up.

• RED+ also puts a face into its neighbour's lightmap when the two face the same way and every corner of the face lies within 0.01 m of the neighbour's plane.
• Emissive and Full Dark faces always keep a lightmap of their own.

Takes effect: when lightmaps are laid out, with Calculate Maps and Light. Level›, Calculate Lightmaps (L) lays them out too, without lighting them. Calculate Lighting alone keeps the current layout. After a layout the log has a line containing [RF+ Lightmap] near-coplanar faces:.

Shadow slices along shared edges

Two faces in the same plane can still have separate lightmaps. RED lights each one on its own, and along the edge they share the two can disagree, which shows as a slice of shadow or light along the edge.

• At the end of each bake RED+ adjusts the texels next to such an edge, on both sides and as little as it can, until the two agree along the whole edge.
• Faces that are Full Bright, Full Dark or emissive keep their own edges.
• On a very large level, a group of edges too big to correct is left as it was. The log counts the groups it skipped in a line containing [RF+ Lightmap] shared-edge components:.

Takes effect: Calculate Lighting.

Keyframed movers

The brushes of a moving group, such as a keyframed door or panel, are not part of the compiled level, and RED lights them on their own.

• Their own shadows. A moving brush blocks light for its own faces, as RED does, whether or not Is Detail is ticked. A moving brush without Is Detail does not shadow the rest of the level, so a closed door leaves no shadow on its frame for when it opens.
• Their edges. At the end of a bake RED+ makes the lightmaps of touching faces agree along their shared edges. A moving brush is matched only with its own faces, never with the frame around it, so a door sitting just behind its frame does not take the frame's light along its edges, and a cut-out such as a porthole does not blotch.

Takes effect: Calculate Lighting.

Bounce on detail movers

A brush in a moving group with Is Detail ticked gets bounce light like the rest of the level, so a keyframed door does not bake darker than the wall around it.

Takes effect: Calculate Lighting, when bounce is on (Good and above, with Bounce % above 0). See Lighting settings in Level Properties.

Lightmaps as the game shows them

RED raises every lightmap texel to a minimum brightness when it opens a level, but not after a bake, and Alpine Faction does not do this by default. Dark areas then look brighter after reopening a level than after baking it.

• RED+ shows lightmaps as they are saved, whether the level was just baked or just opened.
• RED+ shows textures and lightmaps in 32-bit colour, as the game does. RED shows lightmaps with 32 levels per channel, which breaks dark gradients into contour bands with green and purple tints. 16-bit textures keep their own format.
• Only the display changes. The lightmap data and the saved level are the same.
• The editor uses more memory for lightmaps and for 24-bit and 32-bit textures: twice as much for lightmaps.

Takes effect: at once, with nothing to rebake.

Bounce is never skipped silently

If the bounce stage of a bake fails, or finds nothing lit to gather light from, RED+ shows a message that begins "Bounce light was not applied to this bake", and the log has a line containing [RF+ Lightmap] BOUNCE NOT APPLIED:. The lightmaps then have direct light only. Run Calculate Lighting again.

Relight Changed Lights skips bounce on purpose and shows no such message.

Takes effect: every bake.

Good to know

• The corrections that take effect at Calculate Lighting also apply to the surfaces that Relight Changed Lights relights. A relight has no bounce, so the bounce on detail movers waits for the next full Calculate Lighting.
• For what a bake does as a whole, see How RED+ bakes lighting.