Renderer: broken sprite code path

[slipher]

vboData_t::spriteOrientation is never set anywhere, and it was that way since the field was introduced in b10e8c2. I guess the "autosprite" thing (no idea what it is) has probably been broken at least since then.

illwieckz says:

note that we have some known bugs related to sprites. Some can be seen in metro map, in catacombs: missing fire sprites, distorted chain sprite…

[illwieckz]

It's possible that vboData_t::spriteOrientation is dead code.

Here are some materials from the metro map:

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
	}
}


textures/metro/kosad_chaine
{
	qer_editorimage textures/metro/kosad_chaine

	cull disable
	deformvertexes autosprite2

	{
		map textures/metro/kosad_chaine
		alphafunc ge128
		depthwrite
	}
	{
		map $lightmap
		blendfunc filter
		depthfunc equal
	}
}

First one is candle flame, next is a metal string, both use deformvertexes autosprite2.

Here is a scene with both of them. The metal string is incorrectly distorted, the lightmap is not applied, but the texture is rendered and is always facing the player, there is a candle on the left, without flame:

Now, if I swap the names:

textures/metro/kosad_chaine
//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
	}
}

textures/metro/kosad_flammebougie
//textures/metro/kosad_chaine
{
	qer_editorimage textures/metro/kosad_chaine

	cull disable
	deformvertexes autosprite2

	{
		map textures/metro/kosad_chaine
		alphafunc ge128
		depthwrite
	}
	{
		map $lightmap
		blendfunc filter
		depthfunc equal
	}
}

The string is rendered using the flame material (and is animated as expected !), and the candle doesn't have a string as flame:

So, it's like if the autosprite2 code works even if buggy, but only on some kind of surfaces. I guess the string comes from a BSP surface directly made with a brush in NetRadiant, while the candle is a baked model (though if baked, it should be a BSP surface too).

[illwieckz]

Something we know is that the flame doesn't have any lightmap, the surfaceparm nolightmap was read by the map compiler so the engine is not interpreting that part.

[slipher]

autosprite (without the 2) seems to be broken as well. station15 is supposed to have a sun. Its textures/station15_custom_src/sun_d shader uses the autosprite keyword. Here's what in looks like in Unvanquished 0.25.0:

@DolceTriade says that it works in 0.50 also, which is interesting since that is later than the commit I linked in the OP.

[slipher]

autosprite "one" probably actually works fine. I believe the sun was broken by some map update and autosprite was a red herring.

[slipher]

I made a tool to more easily look up which maps contain a given shader keyword such as autosprite2. https://users.unvanquished.net/~slipher/shader-keyword-directory.txt