Broken lantern/candle in metro map, light emitting shader is displayed

[illwieckz]

I've noticed this issue a long time ago, but #301 seems to also trigger it in Terminus. It may be time to look at it…

Look at those candles and lanterns, how they look in Unvanquished:

And how they look in Tremulous:

Along with the flame, you'll notice those square textures in NetRadiant (those things are misc_model entities so they are meant to be baked in BSP):

Those squares textures are in fact… light emitting shaders, that's a clever hack to ship an md3 model with built-in lighting (with light orientation etc.). We see how those light emitting shaders are set:

The one floating above or in front of the lantern is meant to use the back splash feature of the light emitting shader to lit the ground or the wall.

This is the code for the square light emitting shader:

//lanterne1.md3 self lightning
models/mapobjects/kosad/lanterne/lumieresoft
{
    qer_editorimage models/mapobjects/kosad/lanterne/lumieresoft
    qer_trans .2

    q3map_surfacelight 5000
    q3map_lightrgb 1 .8 .4
    q3map_backsplash 30 4

    {
        map $lightmap
        blendfunc filter
    }
}

What's weird is that this lightmap is not meant to be displayed at all so I don't know why there is a lightmap stage, maybe to be sure the compiler will not ignore the shader and the light will be emitted.

The blendFunc filter operation is the default operation to blend a lightmap over a diffuseMap. What's weird is that if we don't take in account this material is not meant to be rendered, this is a lightmap blended with nothing. This is like undefined behaviour.

Then, if we look at the code of the candle flame shader:

textures/metro/kosad_flammebougie
{
    qer_editorimage textures/metro/kosad_flammebougie1

    surfaceparm nolightmap
    surfaceparm nomarks
    surfaceparm trans

    cull disable
    deformvertexes autosprite2

    {
        animmap 50 textures/metro/kosad_flammebougie1 textures/metro/kosad_flammebougie2 textures/metro/kosad_flammebougie3 textures/metro/kosad_flammebougie4 textures/metro/kosad_flammebougie5 textures/metro/kosad_flammebougie6 textures/metro/kosad_flammebougie7 textures/metro/kosad_flammebougie8
        blendfunc add
    }
}

It's an animMap blended with add operation (like glow maps), added over… nothing.

Note that those pictures are jpeg with black bacground, the right operation may be alphaFunc GT0 or alphaFunc GE128.

The blendFunc are usually used to blend multiple stage within shaders, that's not the same purpose.

This time, the material must be displayed, but not the way it is.

[ghost]

Is there is a way to get the map uploaded to the issue? I can't find any "metro" map.

[slipher]

Related: https://github.com/DaemonEngine/Daemon/issues/730

[illwieckz]

It looks like the “light emitting shader is displayed” issue is fixed:

So it remains the issue about the missing flame/fire sprite effect, let track this in a dedicated thread:

• https://github.com/DaemonEngine/Daemon/issues/997

[illwieckz]

It's not fixed. I assume the above screenshots were mistakenly done with a branch I forgot about that would fix them in sources. Using the tremulous build it's still broken.

[VReaperV]

This is fixed now by the autosprite stuff.

[slipher]

Some of the unwanted surfaces are still there: https://github.com/DaemonEngine/Daemon/pull/1406#issuecomment-2448990540

Just the ones that were part of the flames were fixed.

[illwieckz]

As a remind, I never seen those textures working on Unvanquished in the past (maybe with the legacy GL1 renderer, but never with the new one).

As said here in this comment: https://github.com/DaemonEngine/Daemon/pull/1406#issuecomment-2460415926

The metro visible “visible light emitting shader” is a tricky one.

As a remind, the lantern, the candle, etc. come with some shaders having a single stage like this:

  {
      map $lightmap
      blendfunc filter
  }

So we get floating lightmaps multiplied over whatever is behind.

I even don't know why it worked on Tremulous…

Maybe we can just strip them out…

It's probably better to just skip them. They could only work if the lightmap was exactly 1, as it would be like not applying any lightmap.

If Tremulous worked, it's either because of a bug, or because the engine skipped them in some ways…

[illwieckz]

Actually, maybe overbright and clamping turned those lightmaps into 1, so maybe it was just luck.

[VReaperV]

I wonder why those were even there if they're invisible. Is it maybe some weird netradiant output or something?

[illwieckz]

Nothing to do with NetRadiant, and NetRadiant doesn't have tools to write light emitting shaders.

As seen in that comment: https://github.com/DaemonEngine/Daemon/issues/322#issue-604204529

Here is the kind of model that is used in the metro map, as seen in the editor:

One can clearly see the floating light emitting shader. That surface is part of the model.

Using an extra surface that is part of the model and this extra surface using a light emitting shader is a trick to permanently attach a light to a model, so importing a model always imports the light.

To turn the shader into a light emitting shader, one should not need a lightmap stage, but some q3map_ keywords like q3map_surfacelight 5000.

But, for some reasons people creating those assets added a real lightmap stage. I don't know why. Maybe as a workaround for something, or because of some cargo cult.

[slipher]

Maybe we can delete any lightmap with a multiplicative (blendfunc filter) blend as a first stage? That is, shaders which blend a lightmap with the background. The Procyon starchart issues are also caused by a pointless lightmap initial stage.

[illwieckz]

Maybe we can delete any lightmap with a multiplicative (blendfunc filter) blend as a first stage? That is, shaders which blend a lightmap with the background. The Procyon starchart issues are also caused by a pointless lightmap initial stage.

Maybe having a lightmap with a multiplicative blend as a first stage is correct if after that you multiply with a color map? As ( background * lightmap ) * colormap == background * ( colormap * lightmap ) . I may have faced some of them because when I rewrote the collapse code I wrote code to collapse the first one into the second one.