Help: Custom SP Map shows random texture instead of muzzle flash

W0lfMan · 2012-12-07 00:04:04 UTC

Yes, I plan on sending around a beta version for testing before the map gets hosted on the web for download.

SSF-Sage · 2012-12-07 10:53:33 UTC

Indeed the shader overflow can be very annoying. Over the past years I’ve been sturggling with it every quite often as I tend always to push everything to the max and beyond. However! I only lately made a great realisation after many many hours of research on the subject. Something that ruled my world on the subject.

IF you have any new shaders that can be visually afforded to be vertex lit, please do so. BUT that’s just the normal thing to do. HOWEVER for every vertex lit shader you create, you must specify surfaceparm nolightmap!!! Otherwise the lightmap will get created for some reason, even tho it will never be used, and while the useless lightmap is created it contributes to the shader overflow. Also it will increase your BSP/Pk3 size and memory usage etc…

Do note. This might not totally fix your problem. But the more shaders you turn vertex lit the lesser the shader overflow. For me adding that surfaceparm nolightmap in each of my vertex lit shader has decreased the unique combos (shader overflow bug) by about 10-25%. So it is a major factor.

Don’t go editing exist shaders. Only edit the ones you created yourself.


simple example:

textures/capuzzo/detail1
{
	surfaceparm nolightmap

	{
		map textures/capuzzo/detail1.tga
		rgbGen vertex
	}
}

@Ronboy:

I’m glad you enjoy using your Q3MAP. However. It’s like going back to your old reliable Lada when your new Ferrari does not start up. There is a reason we have and use Q3MAP2. It is superior in pretty much every way. You just have to know how to use it. It opens up windows that we could not have imagined of before. I don’t think I need to explain more, just google Q3MAP2.

ailmanki · 2012-12-07 12:21:09 UTC

[QUOTE=kat;81500]@ Hewster, lol… that put a smile on my face… :oD

@ DiaZ; yeh -nocollapse won’t work on a map that big, and you’ve got a big mac daddy of a map by the size of the combo count. Technically you can make a map as big and complex as you like and as you’ve found out q3map2 will compile it; it does’t care about ‘limits’ (“phaaa, what are those” it is often heard to recite), where it does count is ingame.

RtCW SP is the least tolerent of visual limits from the current crop of Quake 3 engined games (from what I understand about the comments ydnar has passed my way when I’ve had the opportunity to quize him on this particular bug/issue) so to make the map your developing run in RtCW means you’ve got a lot of work on your hands reducing the lightmap/shader combo amount… it must be around the 390 mark for that map to run ingame correctly (the limit is actually 392, go over that and you get the overflow bug). Reduce the number of surfaces you’ve got, convert finely detailed or fiddly brushwork to ase models and make sure they’re not lightmapped (shader), make sure anything transparent isn’t lightmapped, convert things like the weeds around that post in the shot to ase models, make sure thin cables are made from thin square brushes where possibly not cylinder meshes… there are a coupleof other you can use/try do optimise the map but I can’t think of them at the moment…![/QUOTE]

[QUOTE=ydnar;81508]-approx only works with ET. RTCW doesn’t have the necessary renderer changes to deal with vertex-lit lightmapped shaders.

RTCW’s shader overflow bug can be hit in stock maps–in fact it was in MP before it was fixed a couple years ago with a patch. Q3Map2 BSPs trade higher shader counts for fewer lightmaps and surfaces, which is why it’s easy to hit the bug limit there.

y[/QUOTE]

To bad, I remembered some ET maps use that approx - so I tried to find some info, and found that topic.
Not sure if I understand there much, but I think forcing the compiler to create bigger lightmaps could help. Since it will create less files, though the shader count might stay the same - so that might only work for terrain, where it should be possible to have one huge lightmap.

SSF-Sage · 2012-12-07 16:24:53 UTC

Yeah indeed. If you use approx all the affected surfaces will be turned 100% white. Even approx 1 will be VERY noticeable.

Indeed terrain can create lots of lightmap data if you have outdoor map and have not done the terrain properly. If you use the ancient ways of creating terrains that are vertex lit and don’t have world casting shadows on it etc you can pretty much overlook this. What you have to make sure is that you don’t use patches for terrain and you have every single terrain brush on the same func_group. Or you might multiply the data, depending a bit on the shaders. Also don’t just put random shader from the pak0, create your own ones and have as few of them as possible.

For my terrains I print the lightmaps externally, have whole terrain in 1 group and then I use q3map_lightmapmergeable and q3map_lightmapsize 512 512. That will force the whole terrain to be fitted to one lightmap page that is 512x512 .tga file (this makes the lightmap quality better but pk3 bit bigger, smaller maps will be fine with 256). It will create a new lightmap page for each terrain func_group, that is why have only 1 group. Also for some reason it seems to build a second .tga that is totally black, I don’t know why, but it’s not a big deal as pk3 compresses it to few bytes… “Downside” is that q3map2 will create a new shader for it that you need to add to the pk3. This will give you seamless shadows with better quality and lesser data.

ronboy · 2012-12-07 20:51:16 UTC

Since my 1st release (Hell Mappack), I’ve always used Q3map2 to compile. I changed over to Q3map for Greenbrier on the Rhine, and I’ve stuck with it since then. (I couldn’t seem to get the areaportals to work with Q3map2.)

By the way, great info Sage and ailmanki. I hope Wolfman finds it useful.

W0lfMan · 2012-12-19 19:36:24 UTC

I’m still working on the map, and I’ve made loads of progress in the past week. A lot of it is cleanup work, since this is my first map, I’m having to go back to areas that I made a month or two ago and make them better.

Some notes:

The shader limit appears to be 380 or less. That’s the lowest number I’ve seen recently, and that map with 380 shaders had the overflow bug. I tried compiling the escape2.map file and it had 280, so I think that I’m doing something wrong with my lighting.
I was using too many curved brushes for things such as overhead lighting supports and railings. BSPC told me I had over 2,000 curve brushes and it couldn’t make the .aas files. I removed many of these and got the curve brush count down to 1,400 where BSPC will reliably generate .aas files.

Removing curve patches also reduces the shader count. It was typically around 450, and now it is hovering around 390-410, even with -nocollapse. I still have many more curve brushes left to be removed. I noticed that the stock maps have very few curved brushes.

I have removed more textures, and that has gotten the shader count to go down as well.

Overall, I think now that I am not lighting the map correctly. I looked at the stock maps and they all use ambient light from between 10 to 12. Just a few days ago I turned on ambient light and I have it up to 4 now. My map seems to be using just as many, if not fewer textures than escape2.map, it also has fewer pointlights, and the raw .map file is smaller.

Secondly, I think that I am still using far too many curved brushes, and I will be eliminating as many of them as possible.

To repeat what I mentioned in a previous post, I am not using any new material for this map-- no new textures, no new shaders, no new sounds.

Also, my map is entirely indoors. There is no terrain. I am using a skybox for the last room, though, because the room has skylights.

W0lfMan · 2012-12-28 16:38:04 UTC

The lowest shader count I’ve seen so far is 369, and that .bsp file still had the shader problem, but not so bad. My guns worked, but the enemies’ did not.

I changed some enemy soldier skins which were previously the orange rocket base uniforms to be the same green like everyone else. That cleared up the problem so it’s mostly OK now. Not perfect, but very close.

With this problem nearly gone, and the bspc program making the .aas files, I decided to release the beta version of the map today. Read the other thread I posted. I will send the .pk3 file by email.