lit water surfaces

[taniwha]

I'm in the process of adding support for lightmaps on water surfaces to qfbsp and QF's gl (maybe) and glsl renderers (sw? aiee!) and while adding --waterlightmap to qfbsp I realized it would be all or nothing. I can't imagine lightmaps being desirable for teleporters or laval.

While I could add support for texture name filtering (ick, but not too bad: just pass in a file with texture names), I realized a mapper might want even more control. qfbsp already supports detail brushes* (from openquartz) by appending "detail" after the texture info on any face in the brush. I thought maybe a "lightmap" flag would be good for marking surfaces that should force lightmap generation. eg:

Code: Select all

( -424 1112 -176 ) ( -424 1112 -192 ) ( -448 1136 -192 ) *teleport 0 0 0 1 1 lightmap


(yeah yeah, I just said lightmaps probably wouldn't be desirable for teleporters, but I swiped the line from coag3_negke.map and added lightmap)

What do others think of this suggestion? Better name? Better mechanism? The actual implementation would be just to make FindTexture not or in TEX_SPECIAL if the tag is seen. Heck, could even add a nolight (fullbright?) flag to force TEX_SPECIAL and thus have fullbright surfaces (eg, video screens).

* Just substitute "detail" for "light" in the above line for how detail brushes are marked. It seems that if any face of the brush is detail, the brush itself becomes detail (don't need the flag on all faces). Detail brushes in qfbsp/qfvis are implemented by grouping all nodes within a detail brush in a single cluster, the bounds of which are that detail brush. Nodes not in a detail brush go into single-node clusters. qfvis then vises clusters rather than nodes, then expands the clusters into nodes for filling in the vis info.

[leileilol]

SW's wouldn't be too hard, although you'd have to ditch the turbulence for the regular spans and/or make new translucent spans.

[Spike]

doesn't matter whether the compiler accepts it or not when the mapping tool doesn't know to generate it.

[taniwha]

The point of the post was to come to agreement on the feature's implementation and establish a "standard" so map tools can be appropriately modified.

If no-one has any input, I'll just go ahead and do as I see fit (of course, adding the necessary features to my blender map-edit addon once I get it to a usable state).

[Spike]

okay then, how does this work with shaders?
shaders that don't specify a lightmap texture will never be lightmapped, while shaders that do will always be lightmapped.
that, combined with editor support, is why I'd prefer qbsp to do it all on the name (either directly or by parsing shader files like q3map2 already does).
that said, forcing .alpha stuff is already annoying enough.

[taniwha]

My intention is only to control the state of TEX_SPECIAL. light uses TEX_SPECIAL to disable lightmap generation. The engine's only use of TEX_SPECIAL is to disable the bad extents check. Lightmap availability is determined by the value of dface->lightofs (-1 -> NULL, else lightdata + lightofs). With lightmap data available, the shader would be free to choose whether to render with lightmaps or without. !lightmap == !choice.

So, how it affects shaders: it gives shaders the choice of whether or not a surface should be lit, at the penalty of restricting the size of the surface. Strategic bsp cuts should take care of that, though.

[mankrip]

It seems this wasn't implemented, at least on the light tool.

The better way would be to implement it in the light compiler, and not in the BSP compiler, so we could easily recompile the lights of already-compiled maps.

I'm going through the in-engine compiler route. The engine will compile the lightmaps of the turbulent surfaces only, so it should take a fraction of the time that a full recompile would take.

Most of the work has been done yesterday. The only part of the light compiler code left to port to the engine is the trace.c file.

An interesting side effect of this in-engine approach is that it will leave the rest of the lightmaps intact, so the rest of the map's surfaces will not be affected.

[rebb]

Would it be worth wrapping this in an additional file, akin to the concept of LIT files, but containing lightmapping data and information about which surfaces the data belongs to ?

That way it wouldn't be necessary to compile it into the BSP file, avoiding the danger of non-supporting engines possibly choking on "special-lit" maps.
Instead engines with support could simply check if a "special-lit" file exists of the same name when loading the map and apply the data accordingly.

It would also allow adding such "special-lit" files to existing maps without touching the rest of the lighting ( -onlyspecial switch in light compilers ? ).

[mankrip]

Cascading LIT files, you mean.

I don't think that's necessary. The vanilla software renderer ignores the lightmap data on such surfaces, and I bet the GL renderer does the same, so there's no risk.

My approach doesn't modify the BSP files — the compiled lightmaps are stored directly in the RAM, so they're compiled every time the map is loaded, and they're never exported.

It wouldn't be hard to combine them with the rest of the lightmaps and export everything into a new LIT file, but I think the correct approach would be to modify the light compiler tools instead.

[rebb]

Very similar to LIT files, but additionally it would contain information about which face(s) the lightmaps belong to etc.

Afaik, LIT files only contain raw lightmap colors without any information about which surface the data belongs to, but since it has the same basic layout as the non-RGB lightmap data in the BSP, the engines can just bend some pointers and read it correctly from LIT.

All that would have to be done in whatever compiles the lightmaps of course.

Just food for thought anyway, looking forward to what you are cooking up !

[mankrip]

It's being harder than expected. It causes stack overflows if run right after the BSP model has been loaded, and the differences in data structures from the light compiler to the engine renderer makes the porting work quite messy. And tracing the distances in 3D space is a mess of its own — SV_RecursiveHullCheck can't be used so early, and the trace.c code makes the stack overflow even earlier.

This needs to be severely optimized.

[mankrip]

Integrating the light compiler isn't enough. The faces generated by the BSP compiler are invalid for turbulent textures:

Code: Select all

void SubdivideFace (face_t *f, face_t **prevptr)
{
[...]
// special (non-surface cached) faces don't need subdivision
    tex = &texinfo[f->texturenum];

    if ( tex->flags & TEX_SPECIAL)
        return;

So now I also need to figure out how the BSP compiler works in order to subdivide the faces with turbulent textures and recalculate the relevant related data in the rest of the map.