UFO:Alien Invasion
Archive => Bugs prior to release 2.3 => Topic started by: keybounce on May 28, 2009, 07:59:18 pm
-
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.)
-
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.
-
I test on Africa (assembled) and Wilderness (single). Both behave the same.
-
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
}
-
the lighting is not yet loaded serverside - only client side (see r_lightmap.c)
-
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?
-
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)
-
Well, duuh, where was that documented? :-).
Alright, thanks. Looking there...
-
What should I be looking at in the lighting data?
------- 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}
-
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).
-
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, ...)
-
those "invalid" warnings are wrong warnings - i will try to fix them.
-
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.)
-
http://ufoai.svn.sourceforge.net/viewvc/ufoai/ufoai/data_source/maps/
there are some small test maps and the tutorial maps.
-
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)
-
Bump
Again, if I'm looking for lighting issues, then what should I be looking for?
Where should I be checking for values calculated in the lighting calculations of ufo2map, versus the lighting calculations of "real time lighting + real time shaders" versus the read from the map data of non-real time lighting?
I'm out of my skill/knowledge trying to understand the code.
-
the lightmap is stored per surface as RGB data - the mBspSurface_t sample data
each sample pair contains two RGB samples - one for the lightmap, one for the deluxemap.
you can even store the lightmap to a raw image if you like - have a look at R_BuildLightmap
to find out more you can deactivate R_BuildLightmap and use R_BuildDefaultLightmap only - this should result in a white lightmap (so no shadows at all)
you can also play around with the cvars r_lightmap and r_deluxemap - if you do please post the screenshots of africa with one OR the other activated
bind n "r_lightmap 0; r_deluxemap 1;"
bind m "r_lightmap 1; r_deluxemap 0;"
-
Attempting to type stuff into the console during game play turns up two flaws:
1. The bottom of the console -- where I type -- is about 2 lines below the bottom of the screen.
2. Copy/paste does not work.
typing blind, but typing ...
Starting the game...
michael has joined team 0
(player 0) It's team 1's round
michael has taken control over team 1.
music change to PsymongR2 (from van_theme)
Retracing for model *1 in 0.0s
Retracing for model *2 in 0.0s
Retracing for model *3 in 0.0s
Retracing for model *4 in 0.0s
Retracing for model *5 in 0.0s
Retracing for model *6 in 1.0s
Retracing for model *7 in 0.0s
Retracing for model *8 in 0.0s
v
michael: v
v
michael: v
Menu 'radarmenu' is not on the active stack
bind n "r_lightmap 0; r_deluxemap 1"
Menu 'radarmenu' is not on the active stack
bind m "r_lightmap 1; r_deluxemap 0"
Alright, trying the "n" and "m" keys while in game play ...
michael: game_timeslow
michael: game_timefast
michael: game_timeslow
michael: game_timefast
Flood protection: You can't talk for 10 seconds.
You can't talk for 9 more seconds
Ok, what am I doing wrong?
-
seams like you (or me) have an old keys.cfg - you can bind other keys - just don't use n and m. you can also add that to the autoexec.cfg or default.cfg if you don't wanna type it to the console.
-
Shouldn't full screen setting solve it?
-
Shouldn't full screen setting solve it?
solve what?
-
1. The bottom of the console -- where I type -- is about 2 lines below the bottom of the screen.
-
Hi. I see that thing too.
IMO fullscreen or not will not change anything, but the ratio of the screen resolution used.
Maybe a job for me.
----
fixed in r24746