Adding VertexArray[i].setTexture

[Bogdan]

It would be nice if you could set a different texture for every Vertex like you can already do with
color and texCoords.

Now you can only have one texture (repeating grass pattern....) for a whole VertexArray and that is sometimes not enough.

Imagine a map of >1000 province shapes made of VertexArray Triangles.
You have >100 nations, where each nation has a unique color.
Whenever a province is conquered, it changes the color to the new owner.
That is perfectly possible with the current "TriangleVertexArray[k].color = sf::Color......"

But what is if I want to change the texture to a texture specific for the new owner. Let's say owner 1 has a repeating texture of "sand" and owner 2 has a "mountain" texture and so on.
One texture (like in your tile map example) is not enough, because it has to be set to "repeated" and the textures can get pretty big (1-2k resolution).
And making a Vector of >1000 VertexArrays has a very bad performance, even with optimizations like a "culling check", so it is out of question.

How would you solve that problem. I need something like

Pseudo code: (normally a triangle would be the smallest area which makes sense)

if(condition_1)
"TriangleVertexArray[k].setTexture = groundtexture......"
else if(condition_2)
"TriangleVertexArray[k].setTexture = sandtexture......"

[fallahn]

I can think of a few solutions:

Maintain a vertex array for each different texture. Even if there are 10-20 different textures then drawing this many arrays is negligible. If a province needs to change texture, rebuild the array it was in, and the array it needs to be in, moving the province vertices from one to the other, and thus changing the texture.

Use some shader magic. This wiki page explains how multiple tiles can be drawn using a texture to look up tile indices:
https://github.com/SFML/SFML/wiki/Source%3A-ShaderTileMap
With some work, as long as you don't mind losing the ability to colour your vertices, it could be modified so that the vertex colour is used to select the correct tile, rather than using a lookup texture. Then at runtime changing the colour of the vertex would select the desired tile.

Use some shader and OpenGL magic. Probably over-engineering, but expanding on the previous suggestion you could use a texture array. Then, using the vertex colour property again, you could select the appropriate texture by indexing it via the colour value.

[kojack]

With some work, as long as you don't mind losing the ability to colour your vertices, it could be modified so that the vertex colour is used to select the correct tile, rather than using a lookup texture. Then at runtime changing the colour of the vertex would select the desired tile.

If there aren't too many tiles (less than 257) then the alpha channel could be used for selecting them, while RGB is used for colouring. (Assuming transparent vertices weren't required)

[Bogdan]

My provinces are triangulated irregular shapes saved in a continuous VertexArray, which is loaded once when the game is being started (heavy operation, which takes some seconds, because there are several thousands of triangles), so I can't change the order, because all the in-game calculations and "breaking points" depend on it.

Maybe an "std::vector<sf::Vertex> vertices"
is the solution instead of a VertexArray?
It seems to give more control over the used texture for every triangle and shouldn't be as heavy as a vector of vertex array.
What do you think?

[Bogdan]

It really seems to work with std::vector<sf::Vertex> because it gives you full control over the textures you want to draw. For example I can tell him to draw every second triangle in texture_2 and the other ones in texture_1 etc.

It works even in my "experimental real time HoI type strategy game prototype". No further tricks necessary!

[eXpl0it3r]

Glad you could find a solution.

Since this is in the "Feature request" category, I just wanted to give my view on this.
The vertex array is kind of a "primitive type" that defines a mesh for a single texture.
If you want to support multiple textures, you can do that, by defining separate "meshes" for each texture. But since this splitting can be done in thousands of different ways and purposes, it makes little sense to have SFML support this.
Case in point you managed to find a solution with the tools at hand.