Tracking down lighting/shading issues

[keybounce]

Alright, I want to tackle this, and do not know where to start.

There appears to be a byte swap issue affecting PPC machines. On a G4 mac, if I have real time lighting and GLSL shaders turned on, then the graphics of the terrain are fine, but people are pure white; if I have either or both turned off, then people are fine but the ground has garbled colors.

I suspect that the lighting information stored in the map file is missing a byteswap somewhere, but I have no idea where to begin looking, or even how to learn where to begin looking.

So, some simple questions:
1. When a map is loaded, where is the lighting information loaded,
2. What are "normal" or "typical" values that should be expected?
3. Since this appears to be a function of both lighting and shading, what else is in the map file that I need to look at?
4. What would cause people to go pure white when the extra calculations are done at run time?

The only time I see a slowdown in frame rate is when both are turned on, indicating that the full calculations are being done locally (and slowly); if either is off, then the frame rate is fast, and (I assume) everything is coming from the map file.

(I managed to track down another byteswap issue once I found out the expected number of sides and brushes, and checked those on loading. I'm expecting something similar here.)

[Mattn]

it would be interesting to know whether you get this on static maps, too - or only on random map assemblies (those with a + in front of their names)

the tracing in rma maps is a little bit broken - see R_LightPoint (or whatever the function name was) - it works e.g. in the bunker map (entering dark corners of a map will make the playermodel darker), but it doesn't work for rma maps.

maybe it's related.

[keybounce]

I test on Africa (assembled) and Wilderness (single). Both behave the same.

[keybounce]

Can someone please explain what's going on with the lighting?

/**
 * @brief Loads the lightmap for server side visibility lookup
 * @todo Implement this
 */
static void CMod_LoadLighting (const lump_t * l)
{
#if 0
        curTile->lightdata = Mem_PoolAlloc(l->filelen, com_cmodelSysPool, 0);
        memcpy(curTile->lightdata, cModelBase + l->fileofs, l->filelen);
#endif
}

[Mattn]

the lighting is not yet loaded serverside - only client side (see r_lightmap.c)

[keybounce]

Where is the lighting information read from the map file, and what are expected/typical values of the data read in?

EDIT: Let me try asking that a little differently.

    /* load the file */
    Com_sprintf(filename, MAX_QPATH, "maps/%s.bsp", name);
    length = FS_LoadFile(filename, &buf);
    if (!buf)
        Com_Error(ERR_DROP, "Couldn't load %s", filename);

This is where the file is loaded into memory.
This is then followed by calls for

...
    CMod_LoadBrushes(&header.lumps[LUMP_BRUSHES], shift);
    CMod_LoadBrushSides(&header.lumps[LUMP_BRUSHSIDES], shift);
    CMod_LoadSubmodels(&header.lumps[LUMP_MODELS], shift);
    CMod_LoadNodes(&header.lumps[LUMP_NODES], shift);
    CMod_LoadEntityString(&header.lumps[LUMP_ENTITIES], shift);
    if (day)
        CMod_LoadLighting(&header.lumps[LUMP_LIGHTING_DAY]);
    else
        CMod_LoadLighting(&header.lumps[LUMP_LIGHTING_NIGHT]);

These calls do all the reading/processing of data out of the file buffer.

But the LoadLighting calls here are no-ops.

So where is the lighting data read out of the file buffer and put into the structures used in r_lightmap.c?

[Mattn]

you are looking at the server side map loading - you should look into the client side map loading (in src/client/renderer/r_model_brush.c)

[keybounce]

Well, duuh, where was that documented? :-).

Alright, thanks. Looking there...

[keybounce]

What should I be looking at in the lighting data?

Code: [Select]

------- Loading game.dylib -------
Reading symbols for shared libraries . done
LoadLibrary (./base/game.dylib)
==== InitGame ====
Map:wilderness  Offset:(0, 0, 0)
wpMins:(128, 118, 0) wpMaxs:(193, 197, 7)
Shifted wpMins:(128, 118, 0) wpMaxs:(193, 197, 7)
Tile bounds: (128, 118, 0) to (193, 197, 7)
Source bounds: (128, 118, 0) to (193, 197, 7)
Done copying data.
Loaded routing for tile wilderness in   2.0s
checksum for the map 'wilderness': 1823298575
ufo script checksum 1428115824
Created AI player (team 7)
-------------------------------------
Connecting to localhost...
load material file: 'materials/wilderness.mat'

Breakpoint 1, debug () at src/client/renderer/r_model_brush.c:109
109 }
(gdb) bt
#0  debug () at src/client/renderer/r_model_brush.c:109
#1  0x001850d0 in R_ModLoadLighting (l=0x290fe074, day=qtrue) at src/client/renderer/r_model_brush.c:102
#2  0x00189d8c in R_ModAddMapTile (name=0xbfffefa0 "wilderness", day=qtrue, sX=0, sY=0, sZ=0) at src/client/renderer/r_model_brush.c:1102
#3  0x0018a1c4 in R_ModBeginLoading (tiles=0x28479ba "", day=qtrue, pos=0x28492b0 "", mapName=0x28469b0 "wilderness") at src/client/renderer/r_model_brush.c:1206
#4  0x0004c938 in V_LoadMedia () at src/client/cl_view.c:219
#5  0x00038684 in CL_RequestNextDownload () at src/client/cl_main.c:515
#6  0x00038830 in CL_Precache_f () at src/client/cl_main.c:547
#7  0x0011963c in Cmd_ExecuteString (text=0xbffff234 "precache 632867780") at src/common/cmd.c:911
#8  0x00117b30 in Cbuf_Execute () at src/common/cmd.c:228
#9  0x00039b04 in CL_SendCommand () at src/client/cl_main.c:897
#10 0x0003a330 in CL_Frame (now=210541, data=0x0) at src/client/cl_main.c:1047
#11 0x0012b144 in tick_timer (now=210541, data=0x1847dabc) at src/common/common.c:1038
#12 0x0012b568 in Qcommon_Frame () at src/common/common.c:1119
#13 0x0019f4ac in main (argc=1, argv=0xbffff8a4) at src/ports/macosx/osx_main.m:142
Current language:  auto; currently c
(gdb) up
#1  0x001850d0 in R_ModLoadLighting (l=0x290fe074, day=qtrue) at src/client/renderer/r_model_brush.c:102
102 debug();
(gdb) list
97 VectorScale(refdef.ambient_light, 1.25, refdef.ambient_light);
98
99 r_worldmodel->bsp.lightdata = Mem_PoolAlloc(l->filelen, vid_lightPool, 0);
100 r_worldmodel->bsp.lightquant = *(const byte *) (mod_base + l->fileofs);
101 memcpy(r_worldmodel->bsp.lightdata, mod_base + l->fileofs, l->filelen);
102 debug();
103 }
104
105 debug()
106 {
(gdb) p r_worldmodel->bsp.lightdata
$1 = (byte *) 0x2b6c902c "\004BBB?BBB?BBB?BBB?BBB?BBB?BBB?CCC?DDD?BBB?BBB?BBB?BBB?BBB?BBB?DDD?EEE?JJJ?kkk?BBB?BBB?BBB?___~?BBB?BBB?BBB?UUU~?BBB?BBB?BBB?BBB?BBB?BBB?B"...
(gdb) # Gee, no help.
(gdb) p refdef.ambient_light
$2 = {0.465661287, 0.465661287, 0.465661287}


[keybounce]

Alright, let me see if I can get some help with the other direction.

If I'm looking in ufo2map, where would I find lighting generation, and what should I be looking for? What should the data look like?

(If nothing else, I can print out some values during generation, and then print out those same values when loaded back in).

[keybounce]

Trying to use the built-in debugging:

Compiling maps with "-v 4" results in no new output.
Compiling with "-v 5" gives LOTS of output.

Most of the beginning stuff looks like this:

---- ChopBrushes ----
--- BrushBSP ---
   22 brushes
    0 visible faces
  132 nonvisible faces
    0 visible nodes
   96 nonvis nodes
   97 leafs
--- MarkVisibleSides ---
--- MakeFaces ---
  174 makefaces
   33 merged
    0 subdivided
---- snap verts ----
224 unique from 564
---- tjunc ----
    0 edges degenerated
    0 faces degenerated
   46 edges added by tjunctions
    0 faces added by tjunctions
  188 bad start verts
--- PruneNodes ---
    0 pruned nodes
--- WriteBSP ---
   91 nodes with faces
    5 nodes without faces
  141 faces

Then comes a big section that looks like:

142 153 4 0 (126, 126, 0) (218, 162, 4)
142 153 6 0 (126, 126, 0) (218, 162, 4)
142 154 0 0 (126, 126, 0) (218, 162, 4)
142 154 2 0 (126, 126, 0) (218, 162, 4)
142 154 4 0 (126, 126, 0) (218, 162, 4)
142 154 6 0 (126, 126, 0) (218, 162, 4)
142 155 0 0 (126, 126, 0) (218, 162, 4)
142 155 2 0 (126, 126, 0) (218, 162, 4)
142 155 4 0 (126, 126, 0) (218, 162, 4)
142 155 6 0 (126, 126, 0) (218, 162, 4)
142 156 0 0 (126, 126, 0) (218, 162, 4)
142 156 2 0 (126, 126, 0) (218, 162, 4)
142 156 4 0 (126, 126, 0) (218, 162, 4)
142 156 6 0 (126, 126, 0) (218, 162, 4)

I don't know what these mean. I'm assuming that the first numbers are locations -- X, Y, Z are the obvious items. The next two look like vectors of some kind.

But those do not change. EVER. EVER.

Finally, I see this:

--- WriteBSP ---
    5 nodes with faces
    1 nodes without faces
    5 faces
Writing maps/africa/af_main.bsp
   55 seconds elapsed
----- Lighting ----
Invalid saturation setting (0.000000) in worldspawn found
Invalid contrast setting (0.000000) in worldspawn found
Invalid quant setting (0) in worldspawn found
light settings:
 * intensity: 70
 * sun_angles: pitch -80.000000 yaw 220.000000
 * sun_color: 0.684211:0.789474:1.000000
 * sun_ambient_color: 0.070000:0.070000:0.080000
78 direct lights for night lightmap
FACELIGHTS: 0...1...2...3...4...5...6...7...8...9...^Z

Can someone who knows what these should be tell me if there is something obviously wrong at this point? (if it's in Radiant, writing out bad data to the .map file before it becomes a .bsp file, ...)

[Mattn]

those "invalid" warnings are wrong warnings - i will try to fix them.

[keybounce]

Can someone create a simple, tiny map that I could use to simply check the lighting values?

(Remember: When lighting/shading are calculated at run time, things look good. When they are calculated in the map, things look bad. 2.2.1 looked good.)

[Mattn]

http://ufoai.svn.sourceforge.net/viewvc/ufoai/ufoai/data_source/maps/

there are some small test maps and the tutorial maps.

[keybounce]

On those test maps: What should I be looking for / expect to see?
(In the data loaded in memory in-game, or in ufo2map's generation of the .bsp files)