-
Is there a way of forcing lightmap face allocation onto the actual lightmaps to remain constant between compiles? [EDIT] Appears q3map2 has -nocollapse parameter, which along with grouping shaders to use a specific lightmap may or may not do what I want here. [/EDIT]
-
Is there a way of assigning lightmap coordinates to a texture layer while specifying a custom texture map? [EDIT] tcgen lightmap to the rescue. Will have to test to see how fast / slow it is though. [/EDIT]
I’ll explain a bit more in depth.
The idea is to have two sets of lightmaps for a level or shader. Then with a shader be able to blend between them at runtime creating entirely different fading lights (eg night to day).
Psuedo shader code!
myshader/amazingeffect
{
{
map $lightmap
}
{
uselightmapUVs
map myshader/lightmapversion2
alphagen somethingthatfades
blendfunc blend
}
{
map standardshader
blendfunc multiply
}
}
Hopefully you can see where I’m going. The normal lightmap goes first, and the second lightmap (my specified texture) goes second, but naturally it needs to use the generated lightmap UV coordinates to match.
Then the standard texture comes last (unlike most shaders, but it’s the only way I could think of easily getting the two lightmaps to blend).
The idea is I create two versions of my map that differ only in lighting. I compile them both, using one set of lightmaps as the default, and using the second set as the ones to fade between. This requires both compiles to output the same face / lightmap allocation. While in theory this is easy to do, I think q3map2 does lots of nice optimisations like collapsing very similar lightmaps, which of course would differ between the two compiles since the lighting would be different.
Then, assuming part 1 above is possible (maybe a new q3map2 switch -nolightmapcollapse or something, if it’s not in there already!), the second part comes into play - getting at the darned lightmap UVs but being able to specify my own texture map for the layer.
Perhaps some q3map2 tcgen $lightmap or something?
I reckon it it should be simple to code in (hurrah, I’m guessing Ydnar’s workload again, bet he loves it when people do that!) if it can’t be done already, and it could provide for some rather stunning effects!
If people still aren’t clear what I’m going on about, I can knock up a quick working demo using a purely terrain map (since the lightmap output on that is guaranteed to remain the same and it’ll be easy enough for me to fudge the lightmap UV coordinate thingy with a standard coordinate generator function.
