https://goo.gl/RBk0nn

I'd love to have an answer for you guys, but this issue is driving me crazy. It never does this for me, and if I can't reproduce it, I can't see what's wrong under the hood. And the fact that it keeps working fine for me (across all MC and Forge versions, in any modpack and with any resource pack) makes me think there's nothing wrong with my code per se, but it's something more esoteric (like OpenGL drivers, idk).

You might be able to help me narrow it down with a bit of Q&A (and testing).

• Do all logs look warped the exact same way? Vanilla and modded? Both endcaps?
• Do different log types have different "junk" on them, or are they the same?
• Does it happen consistently? With older MC and BF versions too?
• What kind of GPU do you have?

I'm still having this problem on 2.16.
MC: 1.12
Forge: 2397

It really would be an easy fix, so I hope it gets done soon. I know it's cosmetic, but cosmetics is what this mod is about. The log ends just need a texture adjustment and then this mod will be pretty much perfect

Thanks for the link, didn't occur to me to check MinGW. That saved me a lot of headache.

You don't have to hurry, I'll be unavailable for a couple of days anyway. When I get back, I'll try that binary first, and if it fails I can still spin up a VM and install Linux on that. I'll need the software renderer anyway to test this, and that won't care about virtualization.

Let's science the shit out of this :)

I can always reproduce.
This issue happens depending on the mipmapping setting:
mipmapping=off-3:
western side:

all other sides:

mipmapping=4:
western side:

all other sides:

It also does happen differently for different kinds of logs. The not bugged textures on the sides changes as it should, the bugged triangles seem to take textures from (seemingly) random places in the game, spruce wood has even two animated lava pixels and shows of the issue very well:
western side:

all other sides:

It does happen consistently in the same configuration, restarts do not affect the look, it does look a little bit different in different versions of minecraft.

with old versions this doesn't happen, the bug (texture wise) was introduced somewhere in between 1.8.9-2.0.2 and 1.10.2-2.0.13 (i can look for the exact version the bug appeared first and whether there is a version completely without the bug, if you want me to)
this is how it looks in 1.8.9-2.0.2:

about GPU and Driver:
GPU:
AMD RX 460
Driver:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: AMD POLARIS11 (DRM 3.9.0 / 4.10.0-26-generic, LLVM 4.0.1) (0x67ef)
    Version: 17.2.0
    Accelerated: yes
    Video memory: 2025MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: X.Org
OpenGL renderer string: AMD POLARIS11 (DRM 3.9.0 / 4.10.0-26-generic, LLVM 4.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0-devel
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.2.0-devel
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.2.0-devel
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

it does however also appear with the mesa software renderer, so that should be a way to reproduce the bug on all computers. (with the software renderer some of the triangles "flicker" between different textures)
It does not appear with the closed source nvidia drivers, however i think it is more likely a driver "feature" on nvidias side than a bug in all other drivers.
Can also test with the closed AMD drivers both on Linux and Windows and the open nvidia drivers, if you want me to.
System:
Lubuntu 17.04, 64 bit using Linux 4.10.0-26

Wow, okay, some very nice info there. Thanks for taking the time to do this @QuImUfu!

You're definitely on to something here, as I'm using Windows and the closed nVidia drivers.

Regarding your last screenshot, the "correct" one: that's wrong too. It's the exact same bug, except the trash bits come from the right parts of the same texture, so it's not as noticeable. And I actually remember seeing that happen... like 1-2 times, sometime last year. So driver version may well be a factor. And now I'm starting to wonder how many people on different hardware are impacted, just didn't report it since they didn't realize they're seeing a bug.

It should look like this BTW, see how nicely octagonal and grid-aligned the logs are:

I'd definitely like you to check the open nVidia drivers at least, possibly the others if you have time, it may shed light on some common theme.
The Mesa renderer is a very good idea, but since I can't find precompiled binaries anywhere, the process looks to be a PITA. Oh well...

jep, realized they are wrong later on as well, but only after testing with the closed nvidia drivers again, forgot to correct my post properly. :D
On windows the software renderer should be included in the libarys in this archive (7zip should be able to open it). Under most linux distros it is just a

LIBGL_ALWAYS_SOFTWARE=1 java -jar ./minecraft.jar

away. Should even work on a live system from DVD, without changing anything on the system. (at least on ubuntu, you may have to "sudo apt install openjdk-8-jre" before)

Will test on all systems/configurations i can. May take a while. :D

sooo, did some testing:

Does the bug appear:

I sadly have no PC running windows and having an Intel GPU and there are only open drivers for Intel gpus on linux.

Holy crap, strangest bug so far.

I managed to fire it up with the software renderer, and dug around a little. I found that the order I draw the vertices of the log endcaps matter.

If I draw them - like before - in the order (v1, v2, v3, v4) it looks good on nVidia, and broken on everything else.
If I shift them, and use the order (v2, v3, v4, v1), it looks broken on nVidia, and good on everything else.

Probably something to do with the way the GPU or the driver breaks up quads into triangles (they must use opposite diagonals for that), but I have no clue why that should matter, as all UV coordinates lie firmly inside the wood log texture.

Anyway, thanks again for your help @QuImUfu, couldn't have done it without you!

Someone with an affected GPU please check if the bug is resolved in 2.1.7. I don't want to close this until independent confirmation.

Just tested the newest version. The bug appears to be resolved. I tried every level of mipmapping. As well as all different vid settings just to make sure. My vid card is a Radeon R290x (just for the record).

Well done on the fix!

Resolved for all previously bugged configurations i can test.
Introduced the bug for the open nvidia driver, as nouveaus renderer info does not contain nvidia.

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: nouveau (0x10de)
    Device: NVD9 (0x1049)
    Version: 12.0.6
    Accelerated: yes
    Video memory: 1013MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVD9
OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.0.6
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 12.0.6
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 12.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

Okay, I'll leave the issue open then so I don't forget. I'll move it to a config option in the next release, which defaults to the current vendor-check.

Configurable in 2.1.8