I used a shader script with the q3map_normalimage key.
It looks good but the lightmap resolution an patches is higher then on brushes.
The worldspawn _lightmapscale is set to 0.1.
Is it possible to get these fine lightmap details on brushes?
It realy rocks! I wanna use it.
HOTHOTHOT
wannashowyoumythingswillshowitsoon...
I'm rusty on this but I think this is how it goes:
Quake 3 lightmap pages are 128 pixels square by default. You can think of these pages as a bunch of little bitmaps hidden in the BSP (because that's what they are). The lightmap UVs for a single drawsurf can't be split between two pages, just like in general 3D stuff texture UVs can't be split across two textures on a single triangle. If the area of space you ask the compiler for is too big, and it would require a bigger lightmap to fit it than it has available, it has to fit it in as well as it can in the space available.
For example, at normal lightmap density it takes a 16 by 16 luxel piece of lightmap to cover a 256 by 256 unit brush face. If you apply a 0.1 lightmap scale, you're asking for 10 times the luxel density, or 160 by 160 luxels. That won't fit on a page so it's squashed down to 128 square.
So what's happening in the picture is your patch's lightmap UVs fit into a page at the requested size, but the wall beside it doesn't, so is using much bigger luxels.
It is possible to tell the compiler to use bigger lightmap pages, however, I'm not sure if Quake 3 supports the use of these larger lightmaps (other games based on updated versions of the Quake 3 engine, e.g. Wolfenstein: Enemy Territory, do), perhaps someone can confirm/deny this?
There's a limit on the number of lightmap pages a BSP can contain as well. I can't remember what it is, but it's pretty low and if you try to use crazily high-res lightmaps like this everywhere it's pretty much guaranteed you're going to hit it. I'd suggest that you try to limit your use of the effect to the places where it will be most noticable.
Shallow wrote:I'm rusty on this but I think this is how it goes:
Quake 3 lightmap pages are 128 pixels square by default. You can think of these pages as a bunch of little bitmaps hidden in the BSP (because that's what they are). The lightmap UVs for a single drawsurf can't be split between two pages, just like in general 3D stuff texture UVs can't be split across two textures on a single triangle. If the area of space you ask the compiler for is too big, and it would require a bigger lightmap to fit it than it has available, it has to fit it in as well as it can in the space available.
For example, at normal lightmap density it takes a 16 by 16 luxel piece of lightmap to cover a 256 by 256 unit brush face. If you apply a 0.1 lightmap scale, you're asking for 10 times the luxel density, or 160 by 160 luxels. That won't fit on a page so it's squashed down to 128 square.
So what's happening in the picture is your patch's lightmap UVs fit into a page at the requested size, but the wall beside it doesn't, so is using much bigger luxels.
It is possible to tell the compiler to use bigger lightmap pages, however, I'm not sure if Quake 3 supports the use of these larger lightmaps (other games based on updated versions of the Quake 3 engine, e.g. Wolfenstein: Enemy Territory, do), perhaps someone can confirm/deny this?
There's a limit on the number of lightmap pages a BSP can contain as well. I can't remember what it is, but it's pretty low and if you try to use crazily high-res lightmaps like this everywhere it's pretty much guaranteed you're going to hit it. I'd suggest that you try to limit your use of the effect to the places where it will be most noticable.
Well said. And yes, -lightmapsize is not supported by vQ3, but only on ET and maybe a few other builds. Lightmaps take up video RAM as well, so you can expect some performance issues with heavy lightmap usage.
That patch does look good, but without dynamic lighting and specular effects, you are probably better off painting those details into the texture directly.
You guys really know everything.
I made a compile with -light export and the lightmap is....
huge.
That patch does look good, but without dynamic lighting and specular effects, you are probably better off painting those details into the texture directly.
...or bake it in an 3d app. I think this solution will need even more video memory.
Maybe i use func_group with individual _lightmapscale in some parts of my map.
One thing you might try is painting/baking multiple versions of a texture with different lighting, and place/blend those to fake surface shading (perhaps with highres lightmaps to take care of the tricky spots?). Of course, that would be technically difficult and a crapload of work, and lightmap shading might not blend as nicely as you'd like.
btw, if you badly want to use highres lightmaps on a large wall you should be able to allow multiple surfaces (and hence multiple lightmaps) by slicing it up.
