Quake3World

A while back when I was posting around the Splash Damage forums, I was told that you could force the resolution of lightmaps to be higher by entering "q3map_lightmapSize X" into your shaders by turning this:

textures/aecell_base/temp_floor_02
{
qer_editorimage textures/aecell_base/temp_floor_02.tga
{
map $lightmap
rgbGen identity
}
{
map textures/aecell_gray/temp_floor_02g.tga
blendFunc GL_DST_COLOR GL_ZERO
rgbGen const ( 0.8789062 0.500000 0.1328125 )
}
}

into this:


textures/aecell_base/temp_floor_02
{
q3map_lightmapSize 256
qer_editorimage textures/aecell_base/temp_floor_02.tga
{
map $lightmap
rgbGen identity
}
{
map textures/aecell_gray/temp_floor_02g.tga
blendFunc GL_DST_COLOR GL_ZERO
rgbGen const ( 0.8789062 0.500000 0.1328125 )
}
}

But when I try to compile, I get an error that says "Line 114 is incomplete" and I've tried putting in "q3map_lightmapSize 256 256" because I've seen a lot of conflicting use of this parameter online, but neither of them worked and both produced the same error message. What am I missing? Thanks.

q3map_lightmapSize width height

Specifies the size of the lightmap texture that surface lightmaps get packed on to. Used mainly in Enemy Territory for terrain lightmaps (512x512) in concert with the Q3Map2 switch -lightmapsize. Probably won't work for older id Tech 3 engine games.

In fact, by itself q3map_lightmapSize does not increase the resolution of the lightmap, just the dimensions of the lightmap pages to sizes other than 128x128 luxels. Q3 doesn't support internal lightmaps of anything other than 128x128, so you must use external lightmaps with q3map_lightmapSize.

You might be thinking of q3map_lightmapSampleSize which is used to actually scale lightmap resolutions. q3map_lightmapSize is often used in conjunction with q3map_lightmapSampleSize, but the two are different parameters.

but given this article you linked me to:

http://sgq3-mapping.blogspot.com/2009/0 ... htmap.html

it makes it sound like if you throw "q3map_lightmapSize 256" into the shader, q3map2 reads that, and automatically creates the external lightmaps and links the surface shader to that lightmap.....or is that just how it works with engines that are newer than quake 3?

*edit....tinkering with "q3map_lightmapSampleSize"

No, the point of the tutorial is to explain...

why adding a key _lightmapscale with the value of 0.25 or 0.125 to the worldspawn give pretty good result on some part of the map, while being extremely ugly and blurry on some other.

You scale lightmap resolution with either _lightmapscale or q3map_lightmapSampleSize. You create larger lightmap pages with q3map_lightmapSize. If you read the article again, you'll notice that the whole point is that when scaling a higher resolution lightmap page on a relatively large surface doesn't work because the page itself is being restricted to 128x128 luxels. It's a bit like trying to wrap a really large box with a tiny piece of wrapping paper, it just doesn't work and you have to "stretch" the paper to make it fit.

So far, I have successfully exported a light map, it was huge, and q3map2 filled it in correctly. I saw it, it did those things. Just....not in-game in quake 3.

I've had mild success with external lightmaps, I've kinda...not really figured it out on my own. I've also discovered the -lightmapsize light phase switch that actually tells q3map2 to draw enough to fill up the big "pages" i've given it. (which it doesn't seem to do unless you use -lightmapsize) but now the problem is getting quake 3 to use those huge lightmaps in-game. It just doesn't.....there are no errors, no warnings, it just doesn't....load them....why? I'd post relevant information but..I'm not sure where to look for that in this case....

interestingly enough, when I compile the lightmaps, it says:

Writing
C:\quake3\baseq3\maps\..\scripts\q3map2\_boozeyjones.shader.

1 custom shaders emitted

but...there's no shader like that anywhere on my system, and it can't be a temp file, right? (it's not supposed to vanish after the compile?)

my hope is to get this to work so I can write a kind of guide about it for the benefit of anyone else trying to get this to work.

The shader file is temporary. That is, q3map2 writes it out, parses it, then deletes it again.

I think the file name is usually prefixed with q3map2_ but that might be version dependent.

Thanks for the tips so far, I think I've got just one more hurdle on this...

hmmm....I'm using NetRadiant 1.5, which I thought would support all of q3map2's functions correctly (they made a custom q3map2 2.5.17) but I could try again with q3map2 2.5.16 because I don't see what I'm doing wrong.

* I've set the _lightmapscale to 0.125
* I've added -export to the light phase
* I've set -lightmapsize to 1024 in the light phase
* additionally I have some shaders that specify q3map_lightmapSize and SampleSize

and this has produced really highres lightmaps in the folder q3map2 generates, but they don't show up in-game.

I've been loosely tracking NetRadiant's development. AFAICT, its q3map2 is a superset of 2.5.16. So anything the regular q3map2 can do, NetRadiant's can do too (and more! ponies!).

wow, I wish there were a -ponies switch in the bsp phase.

quake 3 could have so many more....ponies.

So am I missing anything with external lightmaps? I'm not seeing where my mistake is....unless there's some toggle in quake3 that needs to let it read huge lightmaps? Because it seems like everything is working right up until quake 3 loads them in-game. I am confused.

There should be a generated shader. It's what Q3Map2 uses to identify the lightmap. I don't know why it would be missing.

Interesting, I thought the shader was supposed to stick around. (sorry, I'm probably driving you nuts with this)

Misantropia, why did you think the shader is supposed to disappear?

(I wonder if this is some stupid windows 7 file system thing....it wouldn't be the first time windows 7 stopped q3map2 from working properly...but it can generate other files just fine....I ...have no idea what's going on)

Sorry, I was wrong. I thought q3map2 writes out a temp file but in the case of auto-generated shaders, the file should still exist after compilation.

I might try running it in XP just to see what happens....I don't trust windows 7.

Can either of you try my steps? (also, what OS are you running?)

Ubuntu 10.04 x86_64.

I'll give it a spin if I have some time to kill tonight. But I just became a dad so don't count too much on it.

Congrats on forming the babby, I'm truley happy for your famry!

Thats fantastic news! Good luck with everything...and if you don't have time to run through the q3map2 steps no worries, I'll be hacking away at it to and I'll just post what I find. :]

Thanks guys, I appreciate it!

The prefixed q3map2_*.shader is the shader-script q3map2 generates to do all sorts of nifty-hacked effects that stock quake3 can't do (including lightmaps larger then 128x128).

It regenerates any shaders that declare the q3map_lightMapSize as a parameter, renames them to a randomly generated hash (the .bsp links to this, rather then the original name) and replaces the '$lightmap' key with a path to the large, external .tga lightmap. Here's an example :

br_durango/9789D0B4D0C0F04D15549F0350493C21
{
q3map_lightmapSize 1024 1024
q3map_lightmapBrightness 2.0
qer_editorimage textures/sg_sand/sand_ground1b
q3map_nonplanar
q3map_shadeangle 60
q3map_lightmapMergable
{
map textures/sg_sand/sand_ground1b
rgbGen identity
}
{
tcgen lightmap
map maps/br_durango/lm_0000.tga
blendFunc filter
}
}

Also -

tcgen lightmap - THIS IS REQUIRED BY LAW, otherwise everything just hurrs and durrs because it is no longer implicit with an external texture.

q3map_lightmapMergable -This is nice. I'm not sure what rules it follows for merging external lightmaps... but I like it anyway.

stevec, with the assist

tcgen lightmap...

actually thinking about it now....I'm kinda annoyed with myself for not catching that.....I done derped.

*giving this a shot*

Are you suggesting that I change 'map $lightmap' to 'tcgen lightmap' in the shader before it's compiled, or does tcgen lightmap need to be put in the shader that's produced by q3map2...speaking of which, I got q3map2 to claim it's emitting a shader, but I have yet to find it anywhere....I sense windows 7 is fabricating read/write policies on folders...all of which I'm the admin of. I've seen it do worse. I might just have to ditch the NetRadiant version of q3map2 because I keep hearing how to do it for 2.5.16, which is different from NetRadiant's 2.5.17, while Misantropia correctly pointed out...2.5.17 is supposed to retain all previous functions, I saw some talk of changing how they work....so...I don't know what they did.

Add tcgen lightmap in the original shader that you have created, not replacing 'map $lightmap', this will then be copied over to the generated shader.

Netradiant's compiler handles the auto-generated shaders fine on XP/Linux, but I've got no experience with either mac or win7 (is it possible it's creating it in one of those various user-data folders?)...

I should patch NetRadiant to force the insertion of tcgen lightmap into the external lightmap generated shaders via a switch...

So I just throw it in?

causing this:

textures/aecell_base/temp_floor_02
{
q3map_lightmapSize 256
qer_editorimage textures/aecell_base/temp_floor_02.tga
{
map $lightmap
rgbGen identity
}
{
map textures/aecell_gray/temp_floor_02g.tga
blendFunc GL_DST_COLOR GL_ZERO
rgbGen const ( 0.8789062 0.500000 0.1328125 )
}
}

to become this:

textures/aecell_base/temp_floor_02
{
q3map_lightmapSize 256
qer_editorimage textures/aecell_base/temp_floor_02.tga

{
tcgen lightmap
map /maps/boozeyjones/lm_0000.tga
blendFunc filter
}
{
map $lightmap
rgbGen identity
}
{
map textures/aecell_gray/temp_floor_02g.tga
blendFunc GL_DST_COLOR GL_ZERO
rgbGen const ( 0.8789062 0.500000 0.1328125 )
}
}

and then q3map2 handles the internal updates? (sorry I'm asking a million questions, I have multiple broken environments and this is the first time I'm trying this)

Sorry, I was drinking at a friends when I wrote the previous post (I'm at home now, slightly more sober).

Unless you can solve the case of the missing 'q3map_mapname.shader' file, you could possibly attempt to edit the original shader yourself to emulate what should be happening inside the auto-generated file.

Modify this - Into this - HOWEVER...
This is an incredibly ugly hack that I'm not sure will even work.
Q3Map2 should be taking care of everything for you when it generates the q3map_mapname.shader file,
'maps/mapname/lm_0000.tga' might not even point to the correct lightmap page texture file.
What you should be doing is simply editing the original shader (using the example you provided) to look like this -

That's excellent! I generally get my drink on while mapping so it's perfectly fitting that the help be provided, drinks in hand. However, I'm apartment hunting today so I won't be able to mess with this until later unfortunately. I don't even know if I'm gounna be able to enter the 20 brush mapping contest...I've just got too much going on at the last minute between job....holidays...apartments...ugh. All I want to do is generate and use high-res lightmaps.....stupid...life things.

My plan for later is to boot into windows XP and try this in the most "default" environment I can muster....I REALLY don't trust OS X right now (I dynamically repartitioned the drive like it said I could...and that of course RUINED my boot drive, thanks Apple), and Windows 7 just...lies to me consistently.

Once I'm out of inconvenience and computer hell, I'm greatly looking forward to diving into this. Once I have this high-res lightmaping thing down, I'll be pretty much set with the fancy crap I wanna do with the only possible exception being making fog look nicer, or rendering small fogs inside a fog hull, if that's even possible. ANYWAY, that's neither here nor there...thanks for the help so far, everyone. What I'm hoping to do is understand this well enough that I can write a guide as clearly and succinctly as possible describing this in such a way that total newbies can do it as long as they follow the steps.