reduce lightmaps

[2r]

Hi there, I made a topic once here, about MAX SHADERS HIT problem, and I do fully understand why they happand, so I didn't wanted to post this question there and make instead a different topic for people who may get this same issue as me find it easier

Well, Problem is, i'm making map for be full compatible with Q3 1.11/1.16n, since with 1.32 I have no issue at all, but as known, 1.16n has a limited number of max unique/shaders combinations, and I'm stil unknown wich is, and I think may be 512 to use on a map, but not sure

Anyways, my map is finished (full clipped, r_speeds under 4000 and just a huge room has 7300 but i stil can hint 2 spots for reduce it) and in good light

Only problem is, when I'm compiling, in nearly end of light stage I see the message of: "759 unique/shaders combinations" or something, and I know this is very high, because if i'm no wrong I can use up to 15 different models in map (i added different bots to test :P) and 15 work but 16 dont' work, and on 15 if i press ESC and go to "Player" or "System" menu it just give shader error and model icons dont' show up, so I MUST reduce the unique combinations

But, I searched on web and the sollution I found was, for reduce number of unique shaders/textures I use, well I'm only using like 10 or 12 textures I think and counting with common it may be around 18 or 19, but stil, I also found I could try use gridsize of 128 128 256 (my map default automaticly is set for 64 64 128), and I also saw for try use the -approx 50 switch on light stage, wich apparently would force some places wich has not much shadow or so to be forced be vertex light, so would reduce lightmap number (wich i'm pretty sure would reduce a LOT!)

And I did this all, but grid 128 128 256 made no visible difference in the number of unique/shader combinations, and the "-approx 50" switch at light, when I added it, just frozen my compiler ..., it just stay frozen at the "subsampling, collapsing, assorting" thing on light stage and It stays there for over an hour then I gave up, when i tried again stayed around same thing ..., it just freeze at that stage

So I'm wondering
> is there any way for make -approx 50 (or betetr value if u know) for dont' stay frozen or is this normal?
> How else can I reduce the unique/shader combinations?, I heard about we could make some floors and not much detail objects to be vertex light, so how can I do this? because I have a small trim around whole map (wich look cool :P) and I think is very useless this use lightmap

I'm sorry if I made post to big, but I wanted explain everything, thanks in advance

[Black_Dog]

Q3 lightmaps are limited to 128*128, which means that a large or densely lightmapped level is going to have quite a few. That leads to the sort of problems you are having, as well as being bad for performance. There's not all that much you can do other than to minimise texture variety and lightmap use, or resort to vertex lit shaders.

To force a texture to be vertex lit, simply create a shader for it without a lightmap stage and using rgbGen vertex.

textures/example/vertexlit
{
qer_editorimage textures/example/foo.tga
{
map textures/example/foo.tga
rgbGen vertex
}
}

Ideally there'd be a nice way to get q3 to use external lightmap images, since that would pretty much solve this kind of thing. Maybe with compiler support...

[obsidian]

What compiler are you using?

If Q3Map2, you can use external lightmaps or scale the lightmap resolution. If you have very large brushes, you may want to chop them up into smaller chunks.

[2r]

i ddid as you suggested, increase the lightmap scale, I never thought lightmap scale work as it actually does ..., I applied _lightmapscale 1.5 and reduced shader combos to around 450+ made _lightmapscale 2 and reduced to 322 and I can load 24 different models (12 models red + blue) access to all menus, and everything without have any shader hit issue, and map light itself, didnt' noticed any real difference ..., I also removed the -tresh 0.1 i was using (i saw on web for we use it) and compiler won a boost ... I used compile light in around 15 mins now it take under 3 with bounce 3 it take around 8-9 mins ...

I thougt lightmapscale do as it says "scale" so would make lightmaps much buggers and cause unproper lighting situations but just make map look a little better in some places ...

need improve a little better stil, I think but is already playable

but I came up to a different problem, I used to see some 3-4 red dots in entire map (randomly in each map compilation) now I see several of them ..., is there any way for make those red dots disapear?!?, if need I can take screenshot and show them

and an out subject issue, is there any reason why bots dont' move in 1.16n while at 1.32 they move around for kill each others? in 1.16n all they do (in my map) is stay in same spot and only move when a enemie very close of them ..., this is not important for now I relay just want focus on light for now

thanks

[Black_Dog]

If Q3Map2, you can use external lightmaps

Er, how exactly? You can certainly export external lightmaps, but I can't figure out how to actually use one in q3 (iirc these are useful for rtcw/wolf:et but not vq3).

[2r]

Well here is 3 screens showing the light bug I mentionated, but this small red light bugs show up randomlly after each compilation, well I use this compile options

BSP
-meta -samplesize 4 -v
VIS
-vis -saveprt -v
LIGHT
-light -fast -filter -nocollapse -samples 3 -patchshadows -bounce 6 -v
BSPC
-optimize -bsp2aas

heres the 3 screenshots
http://img120.imageshack.us/img120/358/shot0000oz7.jpg
http://img120.imageshack.us/img120/9169/shot0001dz8.jpg
http://img170.imageshack.us/img170/6143/shot0002qc1.jpg

thanks

[Shallow]

To force a texture to be vertex lit, simply create a shader for it without a lightmap stage and using rgbGen vertex.

You also need to tell the compiler to not generate a lightmap for the surface, otherwise it will still have one made, but not used in game.

Code: Select all

textures/example/vertexlit
{
	qer_editorimage textures/example/foo.tga
	surfaceparm nolightmap
	{
		map textures/example/foo.tga
		rgbGen vertex
	}	
}

Don't ask me why nolightmap is a surfaceparm, it should really be a q3map_ directive but I think that's how it is in the shader manual. It might work either way in q3map2.

[obsidian]

If Q3Map2, you can use external lightmaps

Er, how exactly? You can certainly export external lightmaps, but I can't figure out how to actually use one in q3 (iirc these are useful for rtcw/wolf:et but not vq3).

Limited to what you can do with them since Q3 is still limited to 128x128 lightmaps. But you can export and import them back in should you need to do any manual lightmap editing. Otherwise, if you use lightstyles, external lightmaps are generated.

[obsidian]

-samplesize 4

Herein lies the problem...

You have significantly increased (quadrupled) the entire map's lightmap resolution. The default value is 16 (1x1 luxel every 16x16 game units).

Before resorting to vertex lighting, I would recommend changing your samplesize value to something much more conservative, maybe even increase the value above the default. If on certain areas where you need higher or lower lightmap resolutions, you can change it either on a shader level (q3map_lightmapSampleSize) or per brush group using func_group key/value pairs.

[Black_Dog]

But you can export and import them back in should you need to do any manual lightmap editing.

I've done this a few times, and as you clearly know it's not useful for increasing lightmap size.

Otherwise, if you use lightstyles, external lightmaps are generated.

You know, I didn't think of that. I might be able to get external, static lightmaps to work by lightstyling the whole map and rewriting the resulting shaders.

Wouldn't that be a truly, truly horrific workflow? I'm gonna try it.

[2r]

" quote:
Originally posted by 2r:
-samplesize 4



Herein lies the problem...

You have significantly increased (quadrupled) the entire map's lightmap resolution. The default value is 16 (1x1 luxel every 16x16 game units). "


Hi , well Obsidian, i removed that code peace from my compiler, and even removed the _lightmapscale I was using on map itself (for try reducee max unique combos), and now i'm just amazed lol, with no samples, no _lightmapscale thing, i got a 197 unique combos instead old 752 ...., this 197 is full supported by game for sure :P

BUT, this did not helped the red random light spots, and it ownt' help I make a vertex shader for those areas because those small red dots show up randomly ..., they can show up on lower floor, or on top floor, or on both floors, in different rooms, don't matter, they just show up randomly ....

any idea?

[obsidian]

I remember seeing someone experience that error before, either here or possibly at SplashDamage, but can't recall what caused it.

Try removing nocollapse from your compile to see what happens. I don't think you need it anyway.

[2r]

Hi, sorry didn't replied earlier (stupid ISP ...), well, after I find a final samplesize to use on map, the "red light" bug became static, I mean, they always showed up on the same places, so I think it had to do with not enought light or lights not "crossing" so remain that small dots, so I did your suggestion, and made groups on some objects, and chanegd their _lightmapscale value, and now they all working, I stil have this issue in one place wich i may need think in a betetr way to fix it, but I understand how this works now, s this is no longer an issue

and after all this, I came to conclusion that, most of my map problems was, a BAD compile switchs set ... lol :P

now only remain one bug at my map, the Bot support, my map compiled is around 6MB BSP file, and my aas is under 90KB ...., i use the bsp2aas and -optimize switch, bots do show up in game and attack when we NEAR them but otherwize they just keep stand ..., and i realy didnt' wanted to make another topic, since I hve a bad feeling this problem is some relay stupid thing i may done and got no idea lol

thx

[obsidian]

Sorry, didn't catch that earlier... should have. If using meta (and you almost always should) you also need to compile your AAS with -forcesidesvisible to prevent lobotomized bots.

[2r]

Hi, well about the -forcesidevisible, I nver could use it, because q3 1.16n crash when loading the map, with error of "quake3.exe found a error and need to shutdown, blabalblabla" debug, close and hwateva, u know the error, while if i play the same map in 1.32 (copy the .pk3 to 1.32 folder) it works fine ...

thats why I never used that -forceside command thingy, any ideas?!, and here is my BSPC log if you want to see http://www.2rstuff.com/bspc.log

I used this compile options:

-optimize -forcesidesvisible -bsp2aas "D:\Jogos\Quake 3\baseq3\maps\2rdm1.bsp"

[Shallow]

Sounds like there's basically an incompatibility between AAS files created from Q3map2-built BSPs using -forcesidesvisible and v1.16n. As far as I know no way to get Q3map2 to output a BSP file that can get a valid AAS without that BSPC switch. You have to use it or the AAS will be junk.

If I dredge into the dim recesses of my memory, I seem to remember reading that one of the changes in Q3map2 is that when it creates triangles from brush faces it combines them into larger groups with better triangle stripping and more shared vertices than the older q3map. I believe it does this by exploiting the metasurfaces stuff that was used for Team Arena terrains. That will be the bit that stops BSPC converting those triangles without -forcesidesvisible.

IIRC, the 1.16n version was before the Team Arena changes were introduced - and 1.11 certainly was. Post-TA release, all versions of Q3 contain TA's changes to various bits of the game, including bot code, and bumped max shaders, to cope with its huge maps.

All of which is a boring ramble that doesn't help you get the map working, and might even be entirely wrong.

If you really must have compatibility with such old versions of Q3 I can't see a solution that doesn't involve using the old compiler and using vertex lighting to reduce the number of unique shader/lightmap combinations. That really sucks, since Q3map2 is faster and better in pretty much every way, vertex lighting in the old Q3map looks entirely shite, and you'd probably have to redo your lighting (no radiosity in Q3map).

There's a lot of warnings in that BSPC log - nothing fatal, and many might be spurious (BSPC seems to invent things for itself to get upset about) but I would certainly recommend running brush cleanup if you haven't already, especially as it's a big map.

[2r]

i use brush cleanup quite often for be full sure have no "messed up" brush, specilay when i make the square ones into triangles manulay :P

but the ONLY error I have in th entire compile process, is the "entity leaked" about a candel model wich is in a structure wall, but this is nothign fatal .... i'm full sure of it ...

now i'm wondering, wich version was cpm maps made for on begin?, because all cpm maps i tested worked in 1.16n with bot support .... (cpm4 for exemple)

i'm using the q3map2.5.16 and the bspc 2.1h (i searched for new version but dind't found)

about 1.11 and 1.16n, both versions if i'm not wrong, are basicaly the same, only 1.16n add some custume models (id staff models), q3tourney6_ctf map, and fix the score tab for be able fit 16 or 18 players there (1.11 only can see 8 players on score tab), rest is pretty much the same

so anyone have any ideas?, or case is what you said about incompatibility betwen q3map2 and bspc, u have any clue wich q3map2 version have this issues?!?

thanks

[obsidian]

but the ONLY error I have in th entire compile process, is the "entity leaked" about a candel model wich is in a structure wall, but this is nothign fatal .... i'm full sure of it ...

Entities that have their origins within structural brushes will often result in phantom leaks. VERY possible that BSPC considers that entity to be a leak and then crashes the AAS compile. You may want to check that.

[2r]

well, if that was a real leak, and if aas compile get crash, the bto wouldnt' work in 1.32 neither, but bots work fine in 1.32, but in 1.16n map crash if i have the .aas file (need delete the .aas file in 1.16n for be able play map)

but stil, i think there is a switch for compile withotu entities, so i go compile map with that option + aas and check it out, then i'll edit this post sayign something:)

EDIT:

i removed EVERY leaked entity, and map stil crash when it loads the .aas file

and I already tried recompile the .aas with the old bspc 0.98 or whateva (the one from radiant 202 ...) and keep same thing