Bizarre texture problems in RTCW using q3map2

(DiaZ) #1

You can jugde for yourself:

And this was supposed to be grass, but it looks like the texture was “replaced” on the compiling process, because the grass was made to be vertex lit, and this is lightmapped:

(sorry if the images take a long time to load, my hosting service is crap)

The map was compiled with -meta -patchmeta on bsp stage, -fast vis and -fast -super 2 on lighting stage. Almost every texture has got a 2x2 lightmap samplesize for huge detail (could this be the problem)?

Well, I don’t know what’s going on… :eek: thanks if you can help me out.

(DiaZ) #2

More weird stuff: I’ve made the lightmap samplesize of the textures bigger (8x8, as I was using with Q3Map 1) and most of the artifacts are gone; but the character shadows look all messed up (instead of the shadow texture there’s a concrete texture :eek: ) and a NPC I’ve put on the map is wearing sunglasses (he did not wear them using q3map 1, now this is funny). :???: :???:

(kat) #3

That looks like the shader overflow bug. What happens when you fire a weapon? Do you get a wierd texture instead of the weapons flash?

Try using -nocollapse in the light stage to force the use of unique lightmap/shader combos.

Also next time you do a full compile check how many of those are being generated, there should be an entry near the end of the output log saying something along the lines of “number of uniques shader/lightmap combinations ‘xxxx’” - if ‘xxxx’ is more than 390 then you have a problem that can’t be fixed directly using q3map2, you’ll have to go back thru the map and reduce the amount of shader use/ brushes used/wierd clipped angle/change things into ASE models…

(Hewster) #4

I think your right Kat (not that I’ve played with SP) but I’ve read several posts about this problem…

I was going to try and answer Diaz’s post last night, but I knew the SP guru would be along with
the explanation :slight_smile:

Hewster

(DiaZ) #5

Well, I guess I’m gonna have to live without the 2x2 lightmaps - a pity, because they looked so sharp and nice. The amount of unique shader/lightmap combinations is 1311. Wow. And -nocollapse didn’t work. This map is just HUGE. Way too big for such a small samplesize. I was trying to see how far would I be able to go with the Q3 engine, and this is the result :smiley:

Anyways, I guess the simulated specular highlights effect I’m using on interiors (which does look like bumpmapping at times, it’s quite nice) makes up for the lack of shadow detail… can’t have everything… hehe.

(kat) #6

I was going to try and answer Diaz’s post last night, but I knew the SP guru would be along with
the explanation

@ 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…!

(WolfWings) #7

Another trick that might help…

-approx 8 (for 15bpp-equivilant matching)
-approx 50 (If you care more about the reduction that possibly losing a little lighting quality.)

Just in case you don’t want to look up the switch in the manual: They go on the lighting stage, and will check each tri to see if the lightmap can be approximated with vertex lighting, and if so automatically replace that bit with vertex-lit stuff. The number indicates the quality, roughly, how ‘wrong’ can the vertex approximation be before it’s rejected, and the lightmap kept, on the usual 0-256 scale when dealing with 8-bits-per-channel colour data. So, 8 means 8/256ths accuracy, which reduces to 1/32nd accuracy, which is equivilant to 15bpp quality. And, some lightmaps converted to vertex shading = lower lightmap/shader combos = less chance of that stupid overflow bug. :slight_smile:

Though just FYI, -approx 50 usually still looks pretty damn good most of the time. I pretty much have all my compiles with -approx 8 though, as there’s no readilly discernable quality loss better than 90-percent of the time.

(DiaZ) #8

I’ll try to find some balance point - for example, those buildings you can see on the first screenshoot would look good with a vertex-lit shader, and I would save lightmaps. The cables are patch meshes because they are quite easier to manipulate, but I can try replacing them with brushes, or just make them use another vertex lit shader (they’re so thin no one would ever notice). I could also try using a lightmap sample size of 4x4, which looks good enough. Anyways - I wonder what the heck’s going wrong with the samplesize, because I’m compiling the map right now with q3map1 and shaders that use mostly 8x8 and 14x14 samplesizes, and it works fine - yeah, such a HUGE map works fine :smiley: …but if I compile with q3map2, I’ll get the overflow bug, and the grass will look all messed up (it’s an autosprite shader) :S And that’s using same settings, and same shaders. Weird.

(DiaZ) #9

Okay, I’ve tried to compile the map with -approx 25 and the number of combos has come down to a nice less-than-200 (using the 8x8 and 14x14 lightmap samplesize shaders that is). Which means at least I SHOULD be able to compile it with q3map2 now. And I say Should, because the autosprite grass is still looking messed up, and using approx, every surface that is not vertex lit is being rendered fullbright, with no lightmaps at all :eek:

(kat) #10

, because I’m compiling the map right now with q3map1 and shaders that use mostly 8x8 and 14x14 samplesizes, and it works fine - yeah, such a HUGE map works fine …but if I compile with q3map2, I’ll get the overflow bug,

Yup yup, that’s exactly what I’d expect. Ydnar did relate some time ago that the overflow bug is casued as an (indirect) result of the way he rejiged the lighting code in q3map2, it uses or organises the data slightly differently to q3map. I’m not sure how correct a statment that is now as this was some time ago and me old noggin has recal problems these days…!

(ydnar) #11

-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

(DiaZ) #12

Then I guess I’ll have to go with q3map1, as my map seems to need it, no prob… “you can’t always get what you want” :smiley: The only bad thing is compile times will be looooooooong, specially for the final compile ( -bounce 8 )

Anyways, I wonder why the overflow bug was fixed in MP and not in SP :frowning:

(kat) #13

Anyways, I wonder why the overflow bug was fixed in MP and not in SP

I think purely becasue there was more interest (and still is) in MP. It may have been fixed had the SP part of Enemy Territory been published… we’ll never know now though… :o(

(WolfWings) #14

Different-but-related question… is there any other engine -approx works for? I.E. What about the other engines q3map2 supports, do any others have problems with -approx, or can what you said be taken literally, that it only works with ET?

(Gringo Starr) #15

I tried it in my RTCW MP map about a week ago. I tried all different #'s ranging from 8 - 1024, and the brushes were either lightmapped or vertex lit. In theory, you shouldn’t see much of a difference, but mine looked like crap. Luckily I read this thread, cause I may have tried messing with it again.