dynamic light problem

(SCDS_reyalP) #1

The lightgrid (which lights player models) is generated to q3map2 so this is a q3map question.

A smaller gridsize might help, but it looks like the the player really shouldn’t be that dark at that point, so it would be better to figure out what is wrong. I’m not sure how much impact it has on runtime peformance (likely some) but it can add a lot to bsp size, and if you have more than 8 megs of lightgrid data, the light compile will fail.

Some compile options also affect the lightgrid lighting, maybe playing with those will reduce this effect. Which version of q3map are you using ? and what options in the light compile ?

(cis) #2

thanks for the response.

its q3map2.5.15 and the light stage is -light -fast -patchshadows -gamma 2 -samples 3 -bounce 3 -nocollapse -lomem.

which switches r u refering to (affecting lightgrid?)

i found this thread where ydnar mentions a " common/lightgrid brush". this doesnt exist in sof2 tools shader. might that be of any use to me? could anyone post the shader for such a brush please? if i understand it right, then this will allow me to make the lightgrid more efficient. maybe it even makes it possible that the players go that dark in a completely dark spot, that would rock.

anyway, this black model on that “balkony” is still giving me a headache. it doesn’t seem to make any sense, as its only more less where the player can be seen in the screenshots. not more to the left or right, there everything is fine again. the only “relation” to anything i can see is that this spot is more less where the shadow from the lamp below (those 2 1024 scale .45 light ents) would be falling, if the balkony wouldnt block the light. u can see that on the last shot very well, how the shadow below “points” at the player.

(cis) #3

oh, and what i find irritating too is that the viewers position has such a strong impact on the player models lighting. except in the first shot, where the player is in a different position, the player remained in the same pos for all shots and only i moved making the screens.

(cis) #4

about the 8mb lightgrid data limit, might that be different for sof2? in that thread u say default is 128,128,256 for q3. in sof2 its 64,64,128 and i already made a quite big map with the default setting (way bigger then the one im working on now). i dont know where to see the mb, but the compile log from that map says

— SetupGrid —
Grid size = { 64, 64, 128 }
853936 grid points
— CreateLights —
1593 point lights
267 spotlights
844 diffuse (area) lights
0 sun/sky lights
— SetupEnvelopes (fast) —
2651 total lights
53 culled lights
— TraceGrid —
0…1…2…3…4…5…6…7…8…9… (778)
106 x 106 x 76 = 853936 grid
233207596 grid points envelope culled
76163 grid points bounds culled

is that below 8mb still?

(SCDS_reyalP) #5

If you are over the limit, it will say something like MAX_MAP_LIGHTGRID or something and quit. Actually, I remember now that recent versions of q2map2 just lower the resolution for you. In any case, the above shows around 800k grid points, which should be well under the limit. You could try going a bit smaller.

A lightgrid brush just lets you define what area of your map you want to have lightgrid in. If there are large areas that palyers will never reach, then you can save resources by not having lightgrid there. Be aware that the lightgrid is a simple rectangle, so using more than one lightgrid brush, or one which is a complex shape doesn’t make any sense.

-bouncegrid does radiosity for the lightgrid, that might soften up the dark spot. Again, thats more of a bandaid fix than actually solving the problem.

I seem to recall getting this kind of problem from bad brushwork, but I don’t remember the exact details. In my case, I think it was related to nasty vertex edited brushwork in the area, but I’m not positive. I tried to find the post, but I don’t even remember which forum it was on :confused: In any case, you might want to take a close look at the brushwork in that area.

(cis) #6

ok, then i will rebuild the balconies and the shadow casting wall of the subway entrance before next compile.

about the lightgrid brush, i do have quite a bit of sky that i could leave out of the lightgrid so i will try it. i found its shader in the q3map zip.

thanks

btw, how does the lightgrid work? is it simply a light/color value for each side of each part of the lightgrid (eg 64,64,128)? so that it is basicaly like “a window that brightens rgbgen lightingdiffuse” surfaces when looking through?

(ydnar) #7

The lightgrid shader and image comes with Q3Map2. Look in the extras folder.

Simply copy to your common.shader (or tools.shader for SOF2) and place a box of it around the smallest playable area of your map. Then go in and set “gridsize” in worldspawn to “64 64 96”. That should cure what ails you.

Incidentally, do you have any ambient or minlight?

y

(cis) #8

thanks ydnar, i did that.

nope, i would never use _ambient or _minlight since there is -gamma and -bounce. on those mini screenshots the lighting just seems realy ugly, ingame it looks better. (here, under “map&mods/paranoia” are some better screens)

(cis) #9

i got one more question, don’t want to start another thread for it, would look like spamming :wink:

i got a cage made of brushes, the brushes overlap each other. the textures are aligned with each other though (only 1 texture used on the bars obviously) so normaly there wouldnt be any visible z-fighting.

its right below a styled light though, and there is z-fighting visible at the intersections. for now i will just thicken half of the bars, so the tex wont overlap, but is there a “real” way of fixing this (something in the shader or though) so styled lights dont make the z-fighting visible?

the shader used is just a simple lightmaped rust tex.