2.5.13 lighting problem

(Sinni) #1

ever since i updated to build 13, i’ve been getting some weird lighting. It only happens on some brushes/patches. here’s an example of what i mean http://69.93.144.250/maps/lighting01.jpg here’s the command line i used for the compile this is straight out of the bat file i use

@set Q3MAP_PATH="F:/Quake3/tools/q3map2"
@set bspc_PATH="F:/Quake3/tools/bspc"
@set QUAKE_PATH="F:/Quake3"
@set MAP_PATH="F:/Quake3/tools/maps/%1.map"
@set BSP2_PATH="F:/Quake3/tools/maps/%1.bsp"
@set aas_PATH="F:/Quake3/tools/maps/%1.aas"
@set bsp_PATH="F:/Quake3/tools/bsp"
@set TEX_PATH="F:/Quake3/tools/maps/%1.doc"
@set GEN_OPTIONS=-v -fs_basepath %QUAKE_PATH%


%Q3MAP_PATH% %GEN_OPTIONS% %MAP_PATH%
%Q3MAP_PATH% -vis -saveprt %GEN_OPTIONS% %MAP_PATH%
%Q3MAP_PATH% -light -filter -patchshadows -export %GEN_OPTIONS% %MAP_PATH%
%bsp_PATH% -si %BSP2_PATH% %TEX_PATH%
%bspc_PATH% -bsp2aas %MAP_PATH%
%bspc_PATH% -reach %MAP_PATH%
%bspc_PATH% -cluster %aas_PATH%
%bspc_PATH% -aasopt %aas_PATH%

I don’t get it, werked fine on bulid 12, but now its messed up. Any ideas?

(ydnar) #2

Hm, looks like a bug in the solid lightmap code. I’ll investigate and post a development build you can test soon.

y

(pazur) #3

I have a similar problem when compiling with 2.5.13. An intersecting brush is lighted very strong. I could cut (clip) it into two pieces but i thought, that this may help to localize the bug Sinni described. Another place has one brush that is recieving light from a light ent. that is behind a misc_model surface (but i haven’t made a screenshot of it).

Here a screenshot of the intesecting brush that recieves too much light:

I have noticed that lightmaps created by .13 dropped dramatically wich is quite good i think. (on my map from 56 to 34…) Maybe this has something to do with this bug/effect?

(QESTUDENT) #4

>Sinni
Remove -export from your light switch.
Then have a look at the result.

Q :cool:

(ydnar) #5

-export does not affect the quality or number of lightmaps, it only exports them to TGA files.

Try downloading the development build of Q3Map2 here.

y

(Hewster) #6

Hi,

Yeah I have this problem too with 2.5.1.3…

The dev version has improved it somewhat, however there are still issues…

Here is a pic from the 2.5.1.2 compile:

This is from the 2.5.1.3 release:

and this is from the 2.5.1.4 dev version modified 08 March 2004, 19:03:18

The tunnel and tracks you can see are .ase models
the tracks are 1 model, not separate boxes.
all the lightling is from a sky shader

If you would like any other info / sample map / models just let me know Ydnar :slight_smile:

btw, I noted a reduction in the number of lightmaps used, from 18 with 2.5.12,
down to 12 with 2.5.13 & 2.5.14_dev… is this to be expected ?
Is this simply getter optimisation, or am I losing some lightmap detail ?

Hewster

(ydnar) #7

Cool, thanks for the shots. I’m working out why that happens, and will be releasing a fixed version (2.5.14) as soon as it’s sorted for everyone (including you).

When taking screenshots like this, set /r_draw2d 0 so the crosshair and other useless HUD info doesn’t get in the way of what you’re trying to show.

BTW, tray adding q3map_nonplanar and q3map_shadeAngle 120 to your rock shader(s) so they blend across that edge.

y

(Sine Nomen) #8

If it helps at all, I’ve been encountering strange fragments in my lightmaps as well:

"C:\Program Files\GtkRadiant-1.4\q3map2.exe" -v -game jk2 -fs_basepath "C:\Program Files\LucasArts\Star Wars JK II Jedi Outcast\GameData" -meta -patchmeta maps/ns_duel1

"C:\Program Files\GtkRadiant-1.4\q3map2.exe" -game jk2 -fs_basepath "C:\Program Files\LucasArts\Star Wars JK II Jedi Outcast\GameData" -vis maps/ns_duel1

"C:\Program Files\GtkRadiant-1.4\q3map2.exe" -v -game jk2 -fs_basepath "C:\Program Files\LucasArts\Star Wars JK II Jedi Outcast\GameData" -light -fast -patchshadows maps/ns_duel1
pause
(ratty redemption) #9

@Sine Nomen, nice looking map, but can you please link to pics above 800x600 rather then post them directly into the forum, as it`s too slow for us 56k users, and makes the pages too wide for some of us.

(ydnar) #10

Sine: Try the development build to see if it cures your problems.

y

(Hewster) #11

Cool, thanks for the shots. I’m working out why that happens, and will be releasing a
fixed version (2.5.14) as soon as it’s sorted for everyone (including you).

np & Thankyou :slight_smile:

When taking screenshots like this, set /r_draw2d 0 so the crosshair and other useless
HUD info doesn’t get in the way of what you’re trying to show.

Sorry, I did think that myself as I was adding the circles. (lazy Hewster !)

BTW, tray adding q3map_nonplanar and q3map_shadeAngle 120 to your rock shader(s)
so they blend across that edge.

I do have the above commands in my shader (copied from your dotdroduct2 example)
below is my shader:


textures/ww_mine/terrain_blendY
{
	qer_editorimage textures/ww_mine/terrain_sand1.tga
	q3map_lightImage textures/ww_mine/terrain_sand1.tga
	q3map_normalimage textures/ww_mine/terrain_rock3_bump.tga
	q3map_forceMeta
	q3map_nonplanar
	q3map_shadeAngle 179
//	q3map_lightmapAxis y
	q3map_tcMod rotate 100
	q3map_tcGen ivector ( 320 0 0 ) ( 0 320 0 )
	q3map_alphaMod dotproduct2 ( 0 0.9 0 )
	q3map_lightmapSampleSize 26
	q3map_lightmapSampleOffset 30
	q3map_splotchfix
	q3map_globalTexture
	surfaceparm gravelsteps
	{
		map textures/ww_mine/terrain_rock3.tga
		rgbGen identity
	}
	{
		map textures/ww_mine/terrain_sand1.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		alphaFunc GE128
		rgbGen identity
		alphaGen vertex
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
}

The shader is applied to the Y axis, I split the terrain model into 3 parts, and have applied
a shader for each axis, which works very well…
Originally I didn’t think q3map_lightmapAxis y was making any difference, thats why its commented out,
however, I just did another test compile using q3map_lightmapAxis y (2.5.1.2) and here is the result :slight_smile:

Hewster

EDIT: actually, comparing it to the first shot (using 2.5.1.2) there isn’t any difference ?
is this highlighting another issue with 2.5.1.3 ?

(pazur) #12

the “strong” light at the intersecting brushes is gone with the development version :slight_smile: (the bug from the previous screenshot) thnx ydnar :clap:

… but unfortunately another occurs: lightstyles (native JA) affect brushes that are far away

(Hewster) #13

Just to end this post, version 2.5.1.4 fixes this issue with my lightmaps :slight_smile:

Thankyou Ydnar

(and the latest development version fixes the dot-product2 issue that 2.5.1.4 introduced)

Hewster