Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
illwieckz opened this issue Apr 21, 2020 · 6 comments
Open

Comments

@illwieckz
Copy link
Member

illwieckz commented Apr 21, 2020

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:

metro lantern

metro lantern

metro lantern

metro lantern

And how they look in Tremulous:

metro lantern

metro lantern

metro lantern

metro lantern

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):

metro lantern

metro lantern

metro lantern

metro lantern

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:

metro lantern

metro lantern

metro lantern

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
Copy link

ghost commented Dec 31, 2021

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

@slipher
Copy link
Member

slipher commented Dec 7, 2023

Related: #730

@illwieckz
Copy link
Member Author

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

unvanquished_2023-12-15_024400_000

unvanquished_2023-12-15_024822_000

unvanquished_2023-12-15_024852_000

unvanquished_2023-12-15_024903_000

unvanquished_2023-12-15_024947_000

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

@illwieckz
Copy link
Member Author

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.

@illwieckz illwieckz reopened this Jan 8, 2024
@VReaperV
Copy link
Contributor

This is fixed now by the autosprite stuff.

@slipher
Copy link
Member

slipher commented Oct 31, 2024

Some of the unwanted surfaces are still there: #1406 (comment)

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

@slipher slipher reopened this Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants