Emissive textures on !water textures does not work

[0x4E69676874466F78]

!TOXICGRN and !TOXICGRN2 does not work (c0a0d)

[w23]

Btw, it does get loaded and assigned to a texture. Not sure why it is not applied. Are you sure that's the right texture?

[0x4E69676874466F78]

Are you sure that's the right texture?

Not sure why it is not applied.

Maybe parasitic polygons are interfering? z-fighting?
Look carefully there you can see the overlap of polygons.

I decompiled the map and there really is a different texture very close.

I finally got to grab the texture in the original map use bspguy (it was not easy).

[0x4E69676874466F78]

Although perhaps this block is not just stretched there and I should use CRETE4_FLR01 for emissive?
But then there would be no lighting inside right?

I will set the emissive to CRETE4_FLR01 later.

[0x4E69676874466F78]

With CRETE4_FLR01 has a similar result outside but not inside and !TOXICGRN still needs to be specified because there is only !TOXICGRN on the adjacent surface with a broken tank.
Brush with CRETE4_FLR01 is an error and it should not be there, moreover, in the game brush is somehow removed.

[0x4E69676874466F78]

Maybe it's because the textures which prefixed "!" automatically become a simplified water surface? (inside they work like water and there you can suffocate). Thus, the code associated with the water surface (it seems processed by different shader?) breaks the emissive logic.

[0x4E69676874466F78]

Для c0a0d !TOXICGRN текстуры можно не делать subdivide полигонов, у неё нет func_water тем более (взять WaveHeight неоткуда). Таким образом светящихся полигонов будет в разы меньше (при желании там можно ещё объединить что-то из 18 поверхностей снизу и 10 сверху, но там ещё остаются 18 поверхностей от отсровков, итого без оптимизации будет ~46, с нарезкой видимо там сильно больше). Но нужно при этом оставить искажающую текстуру анимацию.

[w23]

Polygon lights can be only loaded for surfaces which have loaded geometry. We only have geometry for BrushSurface_Regular and BrushSurface_Animated. Water surfaces do not load their geometry as other surfaces do. They are subdivided and loaded into special water models separately.

We still need to somehow load water surfaces geometry for this.

For performance reasons we might even have to join the bsp-split surfaces back into as large polygons as possible, and then do a lighting-aware triangulation.

[w23]

Disregard the geometry part, it is not true. For polygon lights we do load geometries by hand explicitly.

What's broken is emissive color tracking. It works through bmodel->surface_to_geometry_index, which is global per bmodel, not for individual submodels (regular-vs-water-vs-watersides).

The fix is about moving relevant parts to submodels, and collect emissive values for those.

[0x4E69676874466F78]

Светится почему-то только наружная сторона нормально, подводная светится плохо (если вообще светится).

Это реально актуально на c1a4g (там можно попасть под жижу):
GL:

VK rt:

[w23]

This is because polygon lights are one-sided. They only illuminate things in front of them, not in the back. This is a rather important optimization (at least now).

The workaround would be to add back-side polylights for water surfaces. However, that eats too much polylight budget, and makes the rest of the level look way worse due to missing lights (that didn't fit into a budget).

Another way to approach this would be to note the fact that physical reason for this emissive acid is not its surface being emissive, but the whole body of acid emitting lights. So probably we should do some kind of "participating medium" thing, similar to fog, etc. Which we need to do for underwater volumes eventually anyway.

Will do this later.

[w23]

There's also missing emissive water surfaces in e.g. test_brush2 and test_brush3 maps. This is seemingly due to emissive surfaces handler function not being called for some surfaces in some circumstances: e.g. water-only brush model will completely skip regular model loading, and thus will not encounter this function at all.

I tried experimentally addressing this issue here: 65f2403 but it solves only half of it, and also makes code way messier. I'm hesitant to accept it as a solution.

It does not address double-sided issue either.