Terasology: Visual artifacts on crosshair

[Gizmordo]

What happened

Visual artifacts on crosshair

Game version

37

[Cervator]

Can confirm. May be a fairly easy fix if digging around in the engine for the asset / UI element leads to anything obvious. Also may want to try checking out some really old game versions to see if it was introduced around a given period of time, perhaps with some relevant sounding PRs having been merged around that time.

[aRealCyborg]

From what I can tell this bug has started in version 37 in my test.
Version 36, 35, 25 I remember didn't have them.

[jdrueckert]

Unable to reproduce on Linux in Terasology Nightly 1103 and latest iota from source.

[Cervator]

Took off a couple labels as this is likely to be GPU/OS/driver related - surprisingly enough. Had hoped it was just a quirky texture :-(

To summarize some more bits on chat

• Could reproduce on multiple Win10 systems with Nvidia cards (including with the same 1103 binary that didn't show it for Niru on Linux)
• Niru's system for the test was Radeon on Linux - did not show the issue
• @DarkWeird saw it on Linux + intel chip and might have a bit more insight - " i run git bash with nvidia and run ts from it.. and it is works! We have problem with hybrid graphics on windows"

[DarkWeird]

Nvidia window 10 - contains issue
Intel windows 10 - not contains issue.

[DarkWeird]

Another notebook:
Nvidia(proprietary driver) linux - contains issue.
Intel linux - not contains issue.

[DarkWeird]

I have idea about it issue.

I checked atlas with crosshair.

See at crosshair and texture on left from it.
Left texture have border with color equals to crosshair artifact color.

This is issue can be problem with math rounding or texture interolation at driver/gpu level.

Suggest to check Atlas offset calculation

[skaldarnar]

I did a brief round of investigation today:

• artifact is present with nvidia (linux/windows)
• everything is fine with Intel(R) HD Graphics 530 (macbook)

I suspected that the atlas format of that specific file was off (the tile size is 22x22, and we start with an offset that's not aligned with the tile size). For testing purposes, I moved the crosshair textures into another file and adjusted the atlas. With that, the default crosshair looks fine, but the charging crosshair shows a similar artifact (although less obvious).

The texture region calculation uses floats, but I don't know enough about gpus and drivers to figure out where the exact problem might be 🙈

[jdrueckert]

Alright so @skaldarnar found out the following today:
The issue is _not_ that rect to get the texture is of correct size but offset to the left.
The issue _is_ that the rect to get the texture is a pixel too big both in width and in height _and_ it is offset to the left and towards the bottom.

He also found the following spot that _might_ be related to or causing this: https://github.com/MovingBlocks/Terasology/blob/a3d99b4f794f509c7f197d3d7b2b2b0f60b9ac8f/engine/src/main/java/org/terasology/rendering/assets/texture/subtexture/Subtexture.java#L71-L86
However it's unclear whether the crosshair atlas loading actually uses that. Couldn't be confirmed yet during debugging. It _seems_ that the crosshair texture is loaded at the start of Terasology in comparison to the start of a game. Further debugging necessary.

[4Denthusiast]

The coordinates of each image within the atlas are passed to the GPU as floating point numbers for each vertex. The coordinates of the left corners of one image are the same as the coordinates of the right corners of the image next to it in the atlas, so depending on how the GPU does its rounding, it may be retrieving the colour from the same point in the atlas texture for multiple individual textures. This would only show up as a border at most a single screen-pixel across (as opposed to the pixels of the atlas, which are generally larger). The solution used in https://github.com/MovingBlocks/Terasology/blob/develop/engine/src/main/java/org/terasology/world/block/shapes/BlockMeshPart.java for this same issue is to make the region of the texture that's used slightly smaller than the actual size of each image within the atlas, by less than a pixel, but enough to unambiguously put the vertex on the correct side of the pixel boundary.