player model lighting

(uugl) #1

greetings.

I map for q3 and I have a problem with the player model lighting in dark areas. there’s no brightbits on the lightmap, but the playermodel is still clearly lit when near a wall with lights on the other side. this used to be no problem with the ancient q3map.

here’s a few examples of what I’m talking about

http://kraft.xs.mw/disposal/q3map2_1.jpg - q3map2, standing in the dark
http://kraft.xs.mw/disposal/q3map2_2.jpg - q3map2, slightly to the left now - brightly lit
http://kraft.xs.mw/disposal/q3map1_1.jpg - q3map, in the dark again
http://kraft.xs.mw/disposal/q3map1_1.jpg - q3map, in the dark again - lit, but less intense

there was some light leaking on the floor brush (I’m using 16 units wide walls aligned to 16*16 grid - q3map2 seems to offset it sometimes) before so I had to set the lightmapscale to .5.

is there anyway to make this go away? shadows are a fun aspect of games that allow sneaky gameplay like truecombat does. it goes to waste when you’re walking around radiant like this.

(SCDS_reyalP) #2

Player lighting controlled by lightgrid. If your map is fairly small, you could increase the lightgrid resolution (= smaller values of gridsize). It is also possible that there is some error in the brushwork causing that part of the lightgrid to be extra bright. The same thing that was leaking through before you changed lightmapscale, perhaps.

Default gridsize is 128 128 256, the values should (must ?) be powers of 2. You are limited to a total of 8MB of lightgrid data.

(WolfWings) #3

To clarify the above… take the boundaries of your map, and figure out a power-of-2 combination that, when applied to your map, keeps it under 2,097,152 total, IIRC. Also, a lightgrid brush can be good to define the boundaries if your have, say, a large sky area that your players can’t actually get into, or similair ‘out of bounds’ areas that are still in view. This can DRASTICALLY cut down the physical size of the lightgrid, allowing for much higher resolutions.

As an example, say your map has a ‘playable’ area that is 3072x2048x384 in size. Big, broad, but not too tall. Let’s say there are (nominally) two floors, one at 0, and one at 192, with some ‘obstructions’ that can be climbed up on both floors. Taking that into account, you’ll want a lightgrid Z-value that will make sure there’s no “between floors” bleed-through, so take the largest power-of-2 you can, in this case 64, and use that for your Z value.

That means you have 6 ‘slices’ of the lightgrid vertically, so whatever factor you pick for the X and Y axis can’t (when multiplied together appropriately) be larger than 349525. Now it’s just “plug in the value and try it” time. X/Y of 32 would end up with (3072/32)x(2048/32)=96x64=6144, which is pretty damn high-resolution. In fact, that makes the lightgrid the same resolution as a player model. For even higher resolution, let’s try 16 in this case: (3072/16)x(2048/16)=192x128=24576, that’s pretty good. We’d end up with 147456 total lightgrid points, WAY under the 8MB limit (4 bytes per point, IIRC, ydnar will probably correct me now)

But, if we picked resolution 16 lightgrid for the X and Y axis, but 64 for the Z axis, players could jump up and down with little (if any) change to their lighting, by comparison to the detail granted to horizontal movement. So, we could halve (or even match) the X/Y resolution in this case. If we used a _lightgrid of “16 16 32” with a 3072x2048x384 map, we’d end up with 49152 lightgrid points. If we made it INCREDIBLY high-resolution by most standards, at “16 16 16”, we’d still only have 98304 lightgrid points. And, if you mapped to 16x16 grid throughout, you’d have a lightgrid of approximately the same resolution as your map. Just make sure you have the lightgrid OFFSET by 8 units, so the sampling points end up ‘inside’ your grid, instead of ‘on the boundaries’ of your grid, so to speak. I.E. Base the lightgrid brush at (-8,-8,-8) or multiples of 16-unit offsets from that point for a building grid of 16 units, for example.

(uugl) #4

thanks a lot for your reply WolfWings.

that seems like a very useful and doable thing. I kept my map quite small, to keep things simple. I haven’t experimented with gridsize before, but I will follow your guidelines to see if I can fix it like that.

I will play around with the lightmap brush first. I couldn’t find much info on that when I searched for it, but I figure if i can force all lightmaps to stick to the 1616 grid the problem would be solved for most part (q3map 1 lighting looks quite acceptable there, and I never experienced any light leaks when using the q3map when sticking to the 1616 grid). or the (-8 -8 0) you suggested, which seems logic, have see how that will turn out to look.

anyway, thanks again for the informative post.

(WolfWings) #5

The lightgrid brush has ZERO affect on the lightmaps.

It ONLY affects the lightgrid, which is what lights up the models when you’re moving around a level. The lightmaps ONLY affect the fixed world geometry lighting. =^.^=

But yeah, if you have a small enough level, and don’t mind a somewhat huge final .bsp file, you could end up with as low a _gridsize as “4 4 8” though I wouldn’t go below that, as you’re just wasting space at that point, for the most part. =^.^=

(ydnar) #6

Q3Map2 suppresses anything within the radius of the lightgrid size casting shadows. i.e. if both a light and a wall fall within the radius of the lightgrid, it won’t cast shadows on that lightgrid sample.

Use a common/lightgrid brush around the playable area of the map where you want the lightgrid defined.

The add a “gridsize” key to worldspawn with this value:

“48 48 128”

That should fix the problem.

y

(uugl) #7

that fixed it, another happy customer, thanks guys