Pros is code simplicity, everything goes through the one code path, fewer state changes; con is extra texture accesses.

Would the texture accesses problem be solved by making sure all 4 styles end up on the same texture atlas? Or is it just the literal lookup into 4 different pixel locations? And is that anywhere near the cost of uploading new textures? 

Or is it just the literal lookup into 4 different pixel locations? And is that anywhere near the cost of uploading new textures?

It's 4 different locations, one for each style.

It can be mitigated by replacing texcoords for unused styles in a surface with {0,0} (so that the lookup will be in the GPU's texture cache) or by using a 1x1 black texture for lightmaps of unused styles (same reason), but again we're getting into state change tradeoffs.

Comparison with cost of uploading new textures is an "it depends" answer. If you've a switchable lightstyle like the ramp in e1m1 then uploading is going to be faster. If you've a room with hundreds of surfaces each of which has multiple torch flicker animations on it, then uploading is going to be slower.

On balance I think that irrespective of which method you use to handle animation, it's the right kind of optimization. What's already fast either remains fast or drops a little, whereas performance of what's slow comes up and best case is levelled. 

I forgot to mention this.

Rather than using 4 textures, one for each style, with 3 of the RGBA channels used and the 4th unused, an alternative is to use 3 textures, one for each of R, G, B with the styles packed into the 4 channels. That both saves memory and reduces those 4 lookups to 3. 

Seeing as we're talking about lightstyles etc. right now I thought this would be a good time to ask: had there ever been an attempt to raise the number of lightmaps past 4?

I ask because as a mapper i've run into the issue a few times, and its pretty annoying when it crops up. i understand the need for such a low limit in the past, but is there any particular reason other than a desire for compatibility that we still have it? I can't imagine that there are many computers today that struggle to switch lightmaps frequently... 

It's not a problem for RT lights.

For lightmaps it would need BSP format changes as well as engine and tool changes. I don't know/can't remember why we didn't do it for BSP2. 

One thing that may help, in the next release I made light.exe not blow up when the "too many light styles on a face" warning happens. It will compute all the light styles and then save the brightest 4 per face. 

There'll still be a warning, right? Not knowing why you're not getting the desired results would be pretty frustrating and cause a lot of forum posts! 

Yep the warning is still there 

One of the quirks of Quake, in terms of engine, tools and formats, is that it's stuffed full of hard-coded magic numbers like this that can make extending limits while retaining compatibility sometimes impossible.

Unless you actually knew, you'd think that it would be reasonable to suppose that each face structure would have an int member indicating how many lightstyles it has. I know I'd think that. So you might be surprised to learn that it actually doesn't - instead there's a flat array of 4 styles and that's fixed by the BSP format.

What's even more fun is that the code is littered with cases where sometimes a #define is used but other times the number 4 is hard-coded. 

That does sound like great fun.

I like to daydream about one day just taking quake and gutting it and building something similar that's barely compatible but much more friendly and so on. Really just daydreams though, I don't know C. And I don't want to really deal with fun 

I've been wondering if I could use this feature to get smooth blends of textures for my map, i.e. a gravel path that fades smoothly into grass, but unfortunately all that _project_texture seems to do is basically tint the colour of the light a bit, with some textures that have significant colour differences producing multi-coloured lights

Part of me thinks that this is something that just can't be overcome; an issue with lightmap resolution, or something like that. But I feel like I should still ask; is it possible to get more fidelity out of this? If it's already possible, how do I do it?

It's hardly dealbreaking if it's infeasible, but it'd be nice to have... 

texture projections are still just a lightmap trick, so there's a resolution of 1/16th of your normal res. think of it as just a filter over the light, projected by a single side of a small cube around the light (you can distort the cube a bit by using the fov, the other 5 faces of the cube are black).
so yes, all it does is basically tint the colour of the light.

which means that if you make some white image and scale that up 16-fold, then you'll get the same lightmap res as the nearby textures without depending on engine extensions (lit2 would allow you to scale the lightmap per-func_detail without needing new textures).
But... you'll probably end up shining light on the neighbouring surfaces too, so it'll be a bit too hard to control.

it'd be nice to do some sort of alpha blending from one side of a face to another, for a nice blend, but politics and compat issues would make that an absolute nightmare.
If you really want that, q3bsp+terrain shaders is the only proper answer right now. 

The only portable (across engines) way to increase the lightmap resolution is kind of a hack, scale up a texture by 2x in the wad file (e.g. 64x64 to 128x128), and then use a texture scale of 0.5 in the map editor.

_project_texture only really works for stained-glass windows like spike's screenshot in post #558. Another point: the projected texture will look less like mush if it's projected over a larger area / further from the light source.

For texture blends the best bet is just make custom textures or use a wad with them. Even ignoring the resolution issue, the lightmaps are multiplied by the texture colors, so it would look like grass projected on top of rocks etc. 

I figured there would be issues like that. My gravel path shall continue to fail the existence test. Thanks for the explanation though, good to have my suspicions confirmed. 

I remember some fantastic-looking hi-res textures of earthy/rocky paths blending into the grass on the sides, made for Oblivion. They might not be exactly what you're looking for but they could be worth checking out for inspiration. 

It would be nice, and maybe i'll take a look in that direction, but i'm not too invested in this idea and frankly finding an appropriate wad or making one myself would take far too much effort for the results i'm looking to get.

You can see where the path would go here, on the grass with the two dogs. It's a pretty small area and so i'm just going to drop the issue now. 

Called quake texture tool.

Allows you to blend two textures together. I've tried it and it gives mixed results. Give it a whirl, you could probably get better results using other methods, but the tool is pretty quick.

https://www.quaddicted.com/files/tools/quake_texture_tool_v0_1_0.zip 

There's a nice one in : <a href="https://www.quaddicted.com/files/wads/ik2k.zip_ik2k.wad.jpg">9th row, on the right.. it looks better than that preview, i think it's 128x128 

preview image 

someone needs to come up with something cool with fence textures acting as decals. especially if they move... 

that does look nice (judging by the preview) but I'm not seeing any corner pieces; that's what's stopped me from using the hexen 2 textures too, since that's where my grass is from right now; it has a dirt path, but there's no texture for the inner corner so it's pretty useless. 

Can't you find a way to make a corner yourself with two 45-degree-cut brushes and play with texture alignment so the seam isn't too noticeable? 

Perhaps, but historically it hasn't worked very well. The hexen textures have a very nice blend into the dirt texture, with defined blades of grass that'd make it difficult to capture the same effect with brushwork (i'd say impossible).

Trying to make up for texture deficiencies with brushwork is normally a losing battle. Quake's gridsize only goes so small, after all. 

Just fire up Zendar and look at the ground in the opening valley. That sort of thing is the best way of doing it I think.

Quake's all a bit "squint your eyes and it kinda works". There's no point getting too perfectionist about this. 

Changelog & downloads
website