Tint room floors with the owning seat's colour

[Upabjojr]

Addresses the concern raised on #35: "one cannot visually estimate which room belongs to whom when playing game". This makes room ownership readable at a glance, per square — which matters already today (enemy rooms seen through vision all look alike) and becomes essential if rooms ever change hands square by square.

How: the engine already has the machinery — claimed ground gets a per-seat material clone whose seatColor uniform tints the cross pattern. This PR extends it to room floors:

• Room.frag (the shader behind every room floor material) gains a seatColor uniform and blends the floor texture halfway towards the owner's colour. The stock material never sets it — OpenGL zero-initialises uniforms at link time, so alpha 0 keeps the tint off — while the per-seat clone from colourizeMaterial sets it, exactly like the claimed-ground path.
• Tile::shouldColorTileMesh() now lists the room visuals so those clones get made for room floors.
• colourizeMaterial checks that a material's fragment program actually takes a seatColor before setting it, so any floor material that hasn't been taught the tint renders untinted instead of raising an Ogre exception.
• Treasury.material (also the dungeon temple's floor) was the one floor still on the fixed-function RTSS path with nowhere to put a tint — it moves onto the shared Room.vert/Room.frag like every other room floor.

Verified on the two-keeper ForgottenTreasures2 level (the one from #34): in the editor, seat 1's temple + treasury floors shade red where seat 2's shade green; in a skirmish the local keeper's floors carry their colour under normal lighting and fog, and the log shows no material errors.

Seat 1 (red)	Seat 2 (green)	In-game

The 0.5 blend weight is one knob to taste — lower keeps more of the original texture, higher shouts the owner louder. Happy to tune it (or switch to the claimed-style cross-pattern overlay instead of a whole-floor tint) if you prefer another look.

🤖 Generated with Claude Code

https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU

[tomluchowski]

I will merge this PR only if I have no results of my own. The problem such tainting looks cheap and makes the whole texture look dirty. What I am aiming at is to have several white elements in the room , which would be coloured by the players/seats color. Exactly as in the case of training room, where you have those white shields and later on they become red , green or blue or other seat's colour.

[Upabjojr]

I will merge this PR only if I have no results of my own. The problem such tainting looks cheap and makes the whole texture look dirty. What I am aiming at is to have several white elements in the room , which would be coloured by the players/seats color. Exactly as in the case of training room, where you have those white shields and later on they become red , green or blue or other seat's colour.

I can feed this report to Claude.

If you want, you can also give me a longer description of what the game should look like or behave... I can just copy-paste it to Claude and see what gets implemented.

[Upabjojr]

Fair enough — the whole-floor tint is gone. #45 does it the way you describe: white elements in a mask texture that the shader multiplies by the seat colour, exactly the ClaimedMask.png mechanism the claimed ground already uses, so the floor texture itself is never touched. Unowned they stay white; owned they turn the seat's red, green, blue.

The elements themselves are just PNGs (materials/textures/RoomSeat.png, plus the two dormitory edge masks that colour the white scrollwork the carpet already has), so if you have your own art in progress it drops straight in — paint the white elements into the mask and point the room's material at it. The shader and material plumbing in #45 is what you would need either way.

I'll leave this one open for you to close in favour of #45, or close it myself if you prefer.