Seemingly random _lightmapscale behaviour (help!)

(Cardigan) #1

:banghead: :frowning:

I’m just finishing up my map and I’m trying to use func_groups (and also q3map_lightmapsamplesize in places) to scale my lightmaps according to the detail required in each area. So I tried making an area have a lightmapscale of 0.062 (eg samplesize 1) by making all the brushes in that area a func_group and adding the _lightmapscale key. However, when I compiled the map, only some of the surfaces had the correct lightmapscale. Others had a scale that looked like about 0.5.

After checking all the shaders to make sure I wasn’t overriding the scale set by the func_group, and checking the output from q3map2 for any warnings, I made a little test map to try and see what was going on. Here’s some screens to show the prob:

The area of floor at the left of this pic is a func_group with a lightmapscale of 0.062, which is working fine.

But when I extend that brush to twice its original width, the lightmap resolution seems to be automatically reduced:

In this pic, the block in the middle of the pic is a separate func_group with a lightmapscale of 0.062 as well. As you can see, the side of the block nearest the camera has the correct lightmapscale (as does the opposite side which you can’t see) but the rest of the block has a lower res lightmap.

what’s going on? please help, I think I’m going mad…

(Old_Fellow) #2

q3map_lightmapaxis ???

(r3tina) #3

I thought the lightmapscale gets increased if the area cannot be covered with one lightmap. Maybe that’s the case here?

(Cardigan) #4

hmm, possibly - but even if rather than stretching the brush in pic 1 to make the brush in pic 2, I copy it and paste it next to itself (so I have two func_groups sitting next to each other, each identical to the one that worked in pic 1) the lightmapscale is still increased… :frowning:

(Hewster) #5

mmm, thats odd…

I never use the _lightmapscale for lightmap density on func_groups,
I always use the shader command ‘q3map_lightmapscale’ to adjust the
lightmap density on surfaces…

Maybe doing it this way would cure your problem ?

example of shader:

textures/my_textures/atexture
{
qer_editorimage textures/my_textures/atexture_thumb.tga
q3map_lightmapsamplesize 6

{
map $lightmap
rgbGen identity
}
{
map textures/my_textures/atexture.tga
blendFunc filter
rgbGen identity
}
}

6 is a good mix between quality & speed, where 1 will give you the best.
overall map lightmap scale can still be adjusted with the _lightmapscale
key in the worldspawn.

Hewster

(ydnar) #6

Doing it per-shader forces you to have more unique shaders, slowing down rendering. Using _lightmapscale doesn’t bump up shader count while allowing for fine control.

The reason that large faces or adajacent faces in the same func_group have a lower sample size is because Q3Map2 tries to stretch the 128x128 pixel lightmap across it without using non-square pixels or using non integer sample sizes.

Lightmaps are never merged across func_group boundaries, so if you split your large contiguous floor into multiple func_groups, then you can have a smaller overall sample size at the expense of more lightmap data.

y

(Cardigan) #7

OK, I get the bit about the lightmap being stretched to fit the face, and I understand how to chop up the floor into separate func_groups to force q3map2 not to treat the surface as one face (well, two if we’re being picky about polygons being triangular ;))

but…

it doesn’t work!! :banghead:

witness the following screenshots:

Here we have three separate func_groups, each with a lightmap scale of 0.062. Everything is hunky dory as the func_groups do not touch one another:

but when we move the two func_groups on the right next to each other (they are still completely separate func_groups, they just touch along one edge) - the lightmap resolution is halved!:

Am I still missing something? Sorry to bang on, but I really want those hi-res lightmaps, they is just so damn sexeee! :banana:

edit: btw Hewster, thanks for the idea but using shaders makes no difference :frowning:

(U.S.S. Speed) #8

You can always try to compile your whole map with a better _lightmapscale …

It’s probably the fact that the compiler merge surface… I think you have a key to avoid that on the -bsp or -vis process…

Go in the worldspawn in the entities window and add

_lightmapscale
1

(Cardigan) #9

hehe, have you seen what happens if you do that (_lightmapscale 0.062 I assume you meant - eg samplesize 1) on a realistically sized map (ie not a test box)?

q3 goes apeshit and starts making the sky go crazy colours and all the models jet-black and all kinds of freaky stuff like that :smiley:

quite entertaining, but not what I’m looking for :slight_smile:

I think the switch you mean which merges surfaces is -meta - but apart from the fact that I need that switch turned on to do my lightmapped models / terrain etc, turning it off makes no difference to the _lightmapscale prob… :frowning:

(ydnar) #10

Hrm. The faces should not have been merged across func_group boundaries.

That’s a bug.

Dammit.

y

(Cardigan) #11

hehe :slight_smile:

well, that’s preferable to me being insane, at least from my perspective…

I might try giving them subtly differing _lightmapscales and see if I can fudge it like that…

(Cardigan) #12

Ah! The sweet smell of victory! The triumph of man over machine! :smiley:

If you use differing _lightmapscales and surface sizes (eg 0.062 on one func_group and 0.125 on another one which is say, half the width) you can fool the bug into not merging the lightmaps but also in actuality giving each group the same lightmapscale. It doesn’t work with all combinations on all sizes of face, so some trial and error is required, but it does work!

:banana:

edit: it works much better when you are trying to use the highest resolution lightmap you can get - with coarser lightmaps it’s more unpredictable, god knows why (or ydnar might :))…