lit water surfaces

[taniwha]

[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]