| Type: | Bug | ||
| Reporter: | jonathan2520 | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 598 |
| Labels: | None | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Category: |
Rendering
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Mojang Priority: | Low | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Area: | Platform | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
| Comments |
| Comment by TheCatKing [ 15/May/24 ] |
|
When opening beta 1.7.3 my game would have this weird purple boarder for every single block(including liquid blocks like water, or lava) from a 7 block gap from my player. When first downloading I made sure to put it to have 3 GBs of ram allocated to Minecraft for that version. Once I was annoyed enough I switched it to 2gb, this has as of 5/14/2024 at 11:30PM EST fixed this problem. I experimented by putting it to 4gbs, and the problem wasn't present, I then switched it back to 3gbs, and the problem has just vanished.
my pc specs: I5-11400F RTX 2060(6gb, 2 fan, GIGABYTE model) 8gbx2 RAM with a B560M-A motherboard
I know that its a super old version, and you have probably alrighty known that this version had this bug, but I just wish to write it down as a possible fix to anyone experiencing this on that version. This could be a possible fix for other versions too so please give it a try. |
| Comment by Brevort [ 07/Jun/23 ] |
|
Affects 1.20. |
| Comment by Brevort [ 29/May/23 ] |
|
I have just experienced this issue between two blocks in 1.20 Pre-Release 6. I rarely experience this personally but I changed monitors and now I see it. I play with mipmaps off. |
| Comment by Brain81505 [ 11/Feb/23 ] |
|
Can confirm in 23w06a |
| Comment by Brain81505 [ 01/Feb/23 ] |
|
Can confirm in 23w05a |
| Comment by Brain81505 [ 25/Jan/23 ] |
|
Can confirm in 1.19.3 and 23w04a |
| Comment by Josh Birk [ 07/Dec/22 ] |
|
Can Confirm for 1.19.3 Release Candidate 3, appears to be related to ambient occlusion |
| Comment by Delfite [REDACTED] [ 22/Aug/22 ] |
|
I used to have a very similar issue to this one before I had updated my GPU drivers for my GTX 1660 SUPER, forgot what version of drivers this occurred on though :/ My current driver version is "512.15" if that helps at all. Yes, I know this report is talking about AMD Graphics, but the fact this happened on an NVidia GPU tells me this is a game-related issue in addition to it also POSSIBLY being a driver issue. |
| Comment by Choo [ 28/May/22 ] |
|
I have tried the steps here but the issue still persists. The issue was still happening before I had optiFine and seems to not go away no matter what version I play. Minimap levels are max. |
| Comment by Kirven Avion [ 30/Mar/22 ] |
|
Can confirm in 22w12a. |
| Comment by Eduardo Tenório Pereira de Oliveira [ 16/Nov/21 ] |
|
can confirm in 1.18-pre2 |
| Comment by [Mod] ampolive [ 27/Oct/21 ] |
|
Can confirm in 21w43a. |
| Comment by [Mod] ampolive [ 17/Oct/21 ] |
|
Jbabs_ Please do not add a comment to complain, only to add new info or affected versions. |
| Comment by Jbabs [ 17/Oct/21 ] |
|
It is amazing to me how this problem continues to stay the game, and some devs continue to claim it is solely a user-sided issue. There are multiple mods and resource packs that have figured out how to fix the bug, but the devs can't even just copy their homework? The so-called fixes do not work for many people, and reluctance to fix the problem is just annoying at this point. |
| Comment by [Mod] ampolive [ 14/Oct/21 ] |
|
Can confirm in 21w41a. |
| Comment by [Mod] ampolive [ 12/Oct/21 ] |
|
Can confirm in 21w40a. |
| Comment by [Mod] ampolive [ 04/Oct/21 ] |
|
Can confirm in 21w39a. |
| Comment by joppe bijlsma [ 14/Sep/21 ] |
|
I have an issue where I see these lines around my players arm and body in F5 mode...
I'm on a Macbook 2017 with an Intel i7 card. |
| Comment by Owen [ 27/Jul/21 ] |
|
It seems for me at least this starts appearing after 1.7.10 when they switch to the .JSON model format so i think its something to do with that i hope that if they fix the models it won't change their size / position |
| Comment by [Mod] ampolive [ 07/Jul/21 ] |
|
Can confirm in 1.17.1. |
| Comment by [Mod] ampolive [ 05/Jul/21 ] |
|
Can confirm in 1.17.1 Release Candidate 1. |
| Comment by Dylan Peterson [ 30/Jun/21 ] |
|
I hope this bug gets fixed sometime because I very commonly see the white lines especially in the clouds and it gets annoying. |
| Comment by [Mod] Pokechu22 [ 19/Jun/21 ] |
|
Note that there is a second ticket that tracks issues with held item models (though there is some overlap): MC-73186 |
| Comment by [Mod] ampolive [ 18/Jun/21 ] |
|
Can confirm in 1.17.1 Pre-release 1. |
| Comment by [Mod] ampolive [ 16/Jun/21 ] |
|
Vanilla Tweaks have a resource pack called "Item Stitching Fix" that is a workaround for this issue, but only for items such as tools and food, when held in the hand. |
| Comment by [Mod] ampolive [ 09/Jun/21 ] |
|
I have done everything in the mod notice but the issue persists. |
| Comment by Jelle Drouen [ 08/Jun/21 ] |
|
The same thing is happening to me in every install of the game. I have tried deleting and redownloading. For me the lines appear only about 10 blocks away from the player. And from about 50 blocks away it results in a kind of moiré-effect. I am using the newest AMD graphics-drivers. |
| Comment by MeeniMc [ 01/Jun/21 ] |
|
Still present in 1.17pre2 (clouds stitches on AMD hardware (event when disabling all anisotropic or other mipmap/post-processing options in driver) |
| Comment by [Mod] Avoma [ 30/Apr/21 ] |
|
Can confirm in 21w17a. |
| Comment by [Mod] Avoma [ 19/Apr/21 ] |
|
Can confirm in 21w15a. Thunderstorm11, yes, this seems like the same issue. |
| Comment by Brevort [ 19/Apr/21 ] |
|
I see white pixels in the corners of blocks, is this the same issue? |
| Comment by [Mod] Avoma [ 12/Apr/21 ] |
|
Can confirm in 21w14a. |
| Comment by [Mod] Avoma [ 25/Feb/21 ] |
|
Can confirm in 21w08b. |
| Comment by [Mod] Avoma [ 04/Feb/21 ] |
|
Can confirm in 21w05b. |
| Comment by [Mod] Avoma [ 03/Feb/21 ] |
|
Can confirm in 21w05a. |
| Comment by Ahmad S. [ 20/Jan/21 ] |
|
Can confirm in 1.4.1 |
| Comment by [Mod] Avoma [ 20/Jan/21 ] |
|
Can confirm in 21w03a. |
| Comment by [Mod] Avoma [ 21/Dec/20 ] |
|
Can confirm in 20w51a. |
| Comment by [Mod] Avoma [ 02/Dec/20 ] |
|
Can confirm in 20w49a. |
| Comment by Andrew [ 27/Nov/20 ] |
|
you can fix this in 1.16 if nvidia control panel does not work by going to vanilla tweaks and then selecting the item stitching fix and putting it as your resource pack |
| Comment by Heber Johnson [ 18/Oct/20 ] |
|
Great! This is going to be annoying having to switch my settings around every single time I want to play minecraft and not have a headache looking at all the lines! And to the times that I will forget to switch back my settings and wonder why my other games aren't optimized!! |
| Comment by [Mod] CubeTheThird [ 04/Sep/20 ] |
|
SleekGoose, as indicated, please take any further conversation about this report onto the mojira subreddit. |
| Comment by charles sphar [ 04/Sep/20 ] |
|
I understand that this bug will likely not get fixed. But the one thing I don't like is the mod notice on the post, they say this bug usually on the players side when from all the evidence I have seen it's probably not the case. No amount of editing and playing with graphics card settings, or optifine settings make this bug go away. I hope the mod notice clarify's that it is not the NVIDIA settings causing the problem |
| Comment by Fabian Röling [ 31/Aug/20 ] |
|
1.8 will never receive updates again, apart from 1.9 and above, which ARE the updates for it. |
| Comment by charles sphar [ 31/Aug/20 ] |
|
@Fabian Roling the minecraft pvp scene is all on 1.8.9 I simply cant update to the newer versions of the game because the combat in 1.9 and above was highly changed and the update made competitive PVP more slow and boring. I don't think that this should be some update that only works on 1.16 but I think we need an update to the entire minecraft graphics system. But that's likely out of the question and propably SUPER hard to pull of. |
| Comment by Fabian Röling [ 28/Aug/20 ] |
|
TLDR: Because it's hard. You can try it yourself, if you want. |
| Comment by charles sphar [ 28/Aug/20 ] |
|
@Matej Mraz the vanilla tweaks are nice, but the downside is that the texture pack only works for recent version an not 1.8.9 the version most people use for pvp. And the texture pack also can increase lag in the game since the entire inside of the sword if filled with black to cover the seams. The game has to render more which leads to more lag. I don't want this to be only solvable by a texture pack, why has minecraft not fixed this ? |
| Comment by Smajlo Slovakian [ 27/Aug/20 ] |
|
@charles sphar vanillatweaks.net - resource packs - fixes - item stiching... vanilla tweaks are series of tweaks from Xisumavoid's team and has all what you can find on his site, maybe you will download something else too |
| Comment by charles sphar [ 22/Aug/20 ] |
|
if anyone has a fix please tell me. the mods notice on the top of the post does not help at all
|
| Comment by charles sphar [ 01/Aug/20 ] |
|
FaRo1 this problem is not on all blocks but all held items. i have tried every fix I dont think my GPU is the problem |
| Comment by Fabian Röling [ 01/Aug/20 ] |
|
SleekGoose What issue is it for you? Is it like 2014-07-27_18.51.47.png |
| Comment by charles sphar [ 01/Aug/20 ] |
|
This has still been a problem for me. I have tried EVERYTHING PEOPLE ! changing graphic card settings, editing minecraft settings. optifine does not help at all either. The mod notice on the page says that this is mostly a graphics cards issue but I have had AMD and NVIDIA with the same problems ? none of the GPU settings fix this. |
| Comment by charles sphar [ 01/Aug/20 ] |
|
Parker it is true that this texture pack fixes the problem but it is only supported for more recent versions. Also it can cause more lag since the way he fixed it was by filling the entire words inside. Sadly this does not fix older versions such as 1.8 |
| Comment by parker [ 24/Jul/20 ] |
|
This guy fixed some of these issues in a resource pack https://www.planetminecraft.com/texture-pack/transparent-lines-on-edges-texture-stitching-fix/ I have the same problem on my computer with the built in Intel graphics It fixes the problems that exist right now with most tools |
| Comment by Ye Zhiyi [ 09/Jul/20 ] |
|
I tweaked the settings for my NVIDIA GeForce 940MX, but I still can't get the Obsidian Test absolutely correct. Did anyone manage to fix it? |
| Comment by charles sphar [ 08/Jul/20 ] |
|
is there a fix for AMD drivers ? I have been dealing with this for months now it gets on my nerves |
| Comment by jonathan2520 [ 07/Jul/20 ] |
|
Speaking as the person who has contributed a lot to this report in the past and is still the ‘reporter’, I believe this has been largely fixed for a long time. The remaining problems are nothing compared to the problems we used to have. The description and early screenshots and comments are mostly obsolete. Cases that reveal cracks are pretty contrived in 1.16.1, still on that GeForce GT 750M. (Haven’t tested others right now. It’s possible others still don’t get sufficient compensation for their imprecision.) Even things like snow layers join nicely now. You need a sub-block height difference (or some other imperfect alignment like a fencepost on grass) to get ill-defined geometry, but those differences aren’t all over your screen, and the seam is masked to a large extent by genuine geometry. Minor intra-block cracking still exists in complex blocks like hoppers and stairs. This is becoming technically harder to fix. If we didn’t have a precedent in this report making us look for cracks everywhere, I think few would report it or really notice at all. 3D extrusion of 2D cutouts (like a sword in your hand or on the ground) is still a big problem. That’s at the original level of this report. Fancy clouds are similar. Definitely worth keeping a report for those. Other than that, the main cause with the most severe presentation seems to be forcing something like multisampling or anisotropic filtering on Minecraft. There’s little Minecraft can do about that without changing to less flexible and/or efficient rendering. Multisampling can work if you also force centroid sampling. Supersampling should be fine. Post-processing techniques should be fine. I don’t know what Optifine does. It’s possible anisotropic filtering without mipmaps (as if that would look so great) works if it’s like the way Minecraft implemented anisotropic filtering before abandoning it. But none of this is Minecraft’s problem. What about this report? I guess I’m an expert but I’m not really involved anymore. It’s a mess with its long history of many incarnations of the problem as well as people overriding settings. To keep it manageable, at least mention your GPU and be specific about the problem when you say confirmed for xx. Don’t report if you’re using Optifine or graphical overrides, and the problem doesn’t also show up without those. |
| Comment by Trixciel [ 31/May/20 ] |
|
This bug occurs in 20w22a, i've tried every fix and it doesn't seem to be working |
| Comment by W_V [ 24/Mar/20 ] |
|
Confirmed for 20w12a |
| Comment by Emil S [ 15/Dec/19 ] |
|
you can fix this issue in the nvidia control panel |
| Comment by [Mod] Michael Wobst [ 24/Nov/19 ] |
|
We already have enough pictures demonstrating the issue. Usually one picture is already enough. Please stop attaching more pictures to this ticket. |
| Comment by RedCMD [ 14/Oct/19 ] |
|
There are a few fixes |
| Comment by Rowan Barnard [ 12/Oct/19 ] |
|
For 14.4 under video settings, set minmap levels to 0. This worked for me. |
| Comment by [Mod] violine1101 [ 29/Aug/19 ] |
|
Probably not, this issue is happening for a long time for a lot of people. It can often be solved by changing some graphics settings with the graphics card driver, though I'm not exactly sure which ones. |
| Comment by Pink [ 28/Aug/19 ] |
|
it might be happing because the switched to OpenGL 2.0 |
| Comment by Pink [ 28/Aug/19 ] |
|
this is happing on 19w35a. it only happens if you have mipmap on |
| Comment by Dylan [ 20/Jul/19 ] |
|
Can confirm this is occurring between chunk borders on 1.14.4. |
| Comment by Fabian Röling [ 19/Jul/19 ] |
|
Then it's probably a different bug. |
| Comment by 753980 Volts [ 19/Jul/19 ] |
|
This issue also exists in 1.14.4. It only seems to occur at chunk section borders. |
| Comment by 753980 Volts [ 18/Jul/19 ] |
|
This bug is evident at chunk section borders in dark areas in 1.14.3. |
| Comment by Braydon Ransom [ 26/Apr/19 ] |
|
This issue has popped up for me with the latest official update to 1.14. The stitching is only vertical, not horizontal. Radeon RX Vega 64, driver 19.4.1 Edit: Stitching is only horizontal on NSEW faces of blocks. The top and bottom of blocks are affected by stitching in both X&Z directions. |
| Comment by Fabian Röling [ 20/Jan/19 ] |
|
Here someone confirms this issue for the following graphics card: https://gaming.stackexchange.com/questions/345324 I have a "Schenker XMG A507-vsy" laptop with "NVIDIA GeForce GTX 1050" graphics card, Debian 9.6 installed. I am not affected by this issue. Can everyone please comment their graphics card and system info and whether they are affected by this bug in 1.13.2? Then this information can be collected into a proper list for the "environment" field. |
| Comment by Fabian Röling [ 29/Jun/18 ] |
|
No, then you would get overlaps. This is about single pixels, no matter the view distance or in-world size. This is not a simple case like MC-105732. |
| Comment by Play Dash Number f800f8 000000 [ 29/Jun/18 ] |
|
This can be made more hidden by making a texture bigger. |
| Comment by jonathan2520 [ 07/Mar/17 ] |
|
This image that tryashtar just uploaded is of a resource pack. Still, I think it's a fitting demonstration because Minecraft makes it difficult to model that sort of thing. You have to know what robust geometry entails and correct for the piston head problem to get good results. I happen to have done it 'right' for ladders once. At the time I didn't know the proper corrections to apply, but what I did was good enough to work out. Still, the edges of the ladder don't line up with the dirt texture behind it. One more thing that's made worse by Minecraft's correction, but is also very difficult to solve entirely:
I think we'll have to accept that these interactions won't be solved. But at least individual parts can be made to work. |
| Comment by Adam Reynolds [ 31/Dec/16 ] |
|
I can confirm this issue on a Titan X Pascal, with no mods and all settings on max, save mipmapping, which is off. |
| Comment by jonathan2520 [ 22/Oct/16 ] |
|
You can embed attached screenshots with the thumbnail option to maintain a reasonable size: !16w42aStandard.png|thumbnail! !16w42aLower.png|thumbnail!
I've had a closer look at that one. It should affect all systems. Ironically, it's caused by a texture coordinate transformation meant to prevent exactly that kind of problem. It works for faces covered by their entire texture, or at least containing the center. It absolutely kills the kind of geometry appearing in the piston head. In MCP, look for initSprite in net.minecraft.client.renderer.texture.TextureAtlasSprite. The offsets applied to minU and others are the cause. There is no trivial fix because those offsets are needed elsewhere. Even piston heads really need a different kind of offset. Doing it right would require a revamped rendering architecture not based on false assumptions. It's interesting that I have now found this, because issues with this (not all strictly Minecraft's fault) are at the root much of this report. Scaling the offsets by a factor of 4 (making them 0.04 texels) sidesteps the mipmap issues on my Intel Iris Pro as predicted, and presumably also on the Radeons. It also makes piston heads 4 times as bad and makes textures perhaps noticeably inaccurate overall. |
| Comment by Fabian Röling [ 21/Oct/16 ] |
|
Attached two screenshots, one with the standard resource pack (to prove that it isn't an issue with my resource pack, "16w42aStandard") and one with a resource pack with a lower resolution and less different colors that makes it more visible ("16w42aLower"). |
| Comment by jonathan2520 [ 21/Oct/16 ] |
|
That does look like MC-105732. I'd like it if people still experiencing this bug would step up. Provide some screenshots of recent versions in F3 mode. (F3 so it's easy to spot the version and GPU.) Maybe high-quality videos. State video settings, mipmap levels in particular. I 'own' this report yet I have no idea what it is exactly that people are still experiencing, beyond my stated observations. Did I personally see everything? Are people forcing multisampling or anisotropic filtering and blaming the result on Minecraft? For a while now this report has regularly been bumped to the current version, without affirming with screenshots or precise statements what exactly it is that's still present. For a bug report to go anywhere, it must be clear what it's about. |
| Comment by Fabian Röling [ 21/Oct/16 ] |
|
Well, it affects 16w42a, but I think your pictures are just a problem of the block model of lava: MC-105732 |
| Comment by AgentM [ 21/Oct/16 ] |
|
Confirmed for Mac OSX on 16w42a on lava |
| Comment by Fabian Röling [ 10/Aug/16 ] |
|
I think this bug needs a better "environment" field. I can't reproduce it, I'll insert my hardware here in a few minutes. |
| Comment by null (Inactive) [ 10/Aug/16 ] |
|
It is really easy to see this issue, just generate a new superflat world with whatever settings you want and look into the distance |
| Comment by jonathan2520 [ 16/Jul/16 ] |
|
I just tested 1.10.2 a variety of hardware again. There's an old Mac Pro with a Radeon 5870, still running OS X 10.10.5. I also have a MacBook Pro with a GeForce 750M as well as an Intel Iris Pro 5200 in it, running OS X 10.11.5. Normally Minecraft uses the GeForce, but I can force it to use the Iris. I could try the GeForce in Windows on the laptop, probably yielding the same results (likely with better performance, though). The obsidian test is similar on all hardware when mipmaps are disabled. Some speckles. I think the GeForce has fewer of them but it isn't night and day. With mipmaps things get exciting. The GeForce just doesn't care, yielding the same result but with mipmaps. When set to at least 3 levels, both the Iris and the Radeon start showing many speckles. Setting it to 4 worsens it. This only happens in places where those mipmaps are actually used, i.e. from sufficiently far away or from a sufficiently oblique angle. There doesn't appear to be any other directionality like there is for snow layers. This suggests rounding in the texture unit at the texel level is the worst factor. As smaller (higher-numbered) mipmaps are used, the texels get larger, as do the effects of rounding at that level. That must be what pushes it over the edge so it samples a part of the texture atlas that's outside the primitive. Snow layers are absolutely horrid on everything. Dark lines/dots galore, more so toward the south and east. Mipmaps still make it worse on the Radeon and Iris but it's so bad either way that you wouldn't notice by casually looking at it. Do you guys/gals have anything to add? Can you confirm or deny my observations? Have you noticed other factors? On which system? What does it look like? I've been meaning to update the description (the current one hasn't been applicable since 1.7 or so), and I want it to be inclusive of everyone's experience. |
| Comment by jonathan2520 [ 16/Jul/16 ] |
|
FaRoGaming: If you do have a preset (or can at least describe the blocks), please share it. Preferably without resource packs. If it hinges on resource packs, try to use as few as possible and specify exactly which ones are loaded in which order. Then it's easier to test, knowing that it would occur if it could. |
| Comment by Fabian Röling [ 16/Jul/16 ] |
|
jonathan2520 I definitely had this bug in 1.10.2, but not with one of your two presets. |
| Comment by null (Inactive) [ 23/Jun/16 ] |
|
Confirmed for 1.10.2. |
| Comment by null (Inactive) [ 22/Jun/16 ] |
|
Confirmed for 1.10.1. |
| Comment by Kumasasa [ 13/Jun/16 ] |
|
jonathan2520: I've made you the reporter of this ticket, feel free to edit the ticket's description appropriately. |
| Comment by jonathan2520 [ 12/Jun/16 ] |
|
FaRoGaming: A modernized incarnation:
I don't think it's that relevant anymore. The whole renderer has been replaced since then. It used to be that the sections didn't line up. The obsidian made that easy to see by being dark against a bright sky. That part has been fixed, however. On my NVIDIA I get one speckle per millions of pixel-frames. Might be worse on Intel and AMD which have been known to be more severely affected by this. One to test snow layers which are still absolutely horrible even on this machine:
I think this is caused by geometry overlapping very closely, driving the depth buffer beyond its limit. It only really appears in the distance where depth precision is worst. Unlike full blocks, snow layers always draw their side faces even when they're not visible due to an adjacent snow layer. Using a depth function of GL_LEQUAL, the top face of one snow layer might be drawn first. The dark side face of the snow layer behind it might be drawn after it. Because depth precision is so bad, they occasionally end up having the same quantized depth, allowing the dark side face to render over the bright top face. GL_LESS would be the same but with the opposite draw order. Not that different. Looking north and west, the dark speckles actually only appear in between sections, whereas looking south and east they're in between all blocks. This dependence on draw order supports my hypothesis. The best solution would be to get rid of all the geometry that isn't supposed to be visible. A general solution would be a huge pain to implement. Short of that, moving the near plane farther out can reduce the severity. Something like a reversed floating-point depth buffer would have precision inversely proportional to distance which is a whole lot better than inversely proportional to distance squared. To do this properly you need OpenGL 4.5 (glClipControl with GL_ZERO_TO_ONE) or trickery with certain extensions (I forgot which), ruling out OS X which is always way behind in this department. Edit: I think the extension was NV_depth_buffer_float with glDepthRangeNV(-1, 1). That should preserve precision. The NV extension is required because it's the lack of clamping we rely on to work around catastrophic cancellation. There's also the more recent ARB_clip_control which has the same functionality as OpenGL 4.5. None of this is present on OS X. Yay. (Yes, I'm the same guy who wrote the story that was eventually copied to the description of this bug.) |
| Comment by Fabian Röling [ 12/Jun/16 ] |
|
I can't confirm for 1.10 with the preset given in the description. The preset code also doesn't work the way it's given, but that's another bug. |
| Comment by null (Inactive) [ 08/Jun/16 ] |
|
Confirmed for 1.10. |
| Comment by null (Inactive) [ 07/Jun/16 ] |
|
Confirmed for 1.10-pre2. |
| Comment by null (Inactive) [ 03/Jun/16 ] |
|
Confirmed for 1.10-pre1. |
| Comment by null (Inactive) [ 26/May/16 ] |
|
Confirmed for 16w21b. |
| Comment by null (Inactive) [ 25/May/16 ] |
|
Confirmed for 16w21a. |
| Comment by null (Inactive) [ 18/May/16 ] |
|
Confirmed for 16w20a. |
| Comment by null (Inactive) [ 11/May/16 ] |
|
Confirmed for 1.9.4. |
| Comment by null (Inactive) [ 06/May/16 ] |
|
Confirmed for 1.9.3-pre3. |
| Comment by Tom Hansen [ 28/Apr/16 ] |
|
Thanks Kumasasa, forgot I hadn't updated yet. I upgraded to 1.9.3-pre2 and it's still confirmed. I have screenshots if needed. Seems to be mostly indoors, around torches, and on stone. |
| Comment by Kumasasa [ 27/Apr/16 ] |
|
hanyuning : 16w15b is outdated, please update to 1.9.3-pre2 |
| Comment by Tom Hansen [ 27/Apr/16 ] |
|
Still confirmed in 16w15b on MacOS. New install of MC, no mods. |
| Comment by James (inactive) [ 15/Mar/16 ] |
|
Confirmed for 1.9.1-pre3 with (fancy) clouds. |
| Comment by insomniac_lemon [ 01/Feb/16 ] |
|
I have the feeling that the example 'fix' code could also be applied to defining elements for custom models and it would fix MC-73186 as well. Although both are UV bleeding, just in different contexts. |
| Comment by Marcono1234 [ 01/Feb/16 ] |
|
redstonehelper could you please include a link to the source as well? |
| Comment by [Mod] Michael Wobst [ 31/Jan/16 ] |
|
Agreed. Except for heapload of pictures, MC-1794 is basically useless. I'd use |
| Comment by Marcono1234 [ 31/Jan/16 ] |
|
Please include the description of |
| Comment by Alawnely [ 01/Jan/16 ] |
|
It still happens when mipmaping is turned off but only on clouds (not inside). |
| Comment by Swekob [ 02/Nov/15 ] |
|
Confirmed for 15w44b. |
| Comment by jonathan2520 [ 21/Sep/15 ] |
|
I just tested it on a Mac desktop with AMD graphics and a Mac laptop that has both Intel and NVIDIA graphics. Things like white wool and the surface of the ocean are only problematic when mipmaps are enabled, on AMD as well as Intel. It looks like only minified pixels are susceptible: rounding at the texel level may be the culprit, necessitating texture coordinates with a larger inset. When mipmaps are disabled both are mostly fine. NVIDIA is totally flawless, with or without mipmaps. I cross-checked a lot between 1.8.8 and 15w39a but was unable to find a difference. Snow cover (a single snow layer or 1/8 of a block, but probably others as well) is universally horrible, however. Doesn't matter which version or GPU, or whether mipmaps are enabled. In fact, if you don't move and change the mipmap setting, the dots stay in the same positions. |
| Comment by ProfMobius (Thomas Guimbretiere) [ 21/Sep/15 ] |
|
Can you tell me if this issue persists with mipmaping turned off ? |
| Comment by Marcono1234 [ 13/Mar/15 ] |
|
What you are describing could be MC-73186 |
| Comment by insomniac_lemon [ 08/Mar/15 ] |
|
Related issue here in 1.8.3 is UV bleeding with custom models where the edges them take tiny bits of color from parts of their texture they aren't mapped to (either transparent or another color, which can be really bad when a neighboring texture is another color like red on a gray object). More related in 1.8.3 even on decent hardware is that random dots sometimes appear missing in the distance. Both of these issues are exaggerated by the 'art' and 'blobs2' shaders which process the missing/UV bled pixels differently. |
| Comment by Daniel Oakley [ 23/Dec/14 ] |
|
[FIXED] Nvidia uses need to open the Nvidia control Panel by going to Start -> Control Panel -> Nvidia Control Panel, Under 3D settings, click Set PhysX Configuration, Where it says "Select a PhysX processor" Select CPU, Launch Minecraft again, and it should be fine, Sometimes updating your graphics card driver might help. Nvidia Drivers: http://www.nvidia.com/Download/Scan.aspx?lang=en-us |
| Comment by yut951121 [ 21/Dec/14 ] |
|
Not sure if anyone said this before, but it is actually the background that lies behind blocks not just white(sky)/black(void) dots. |
| Comment by GrygrFlzr [ 10/Sep/14 ] |
|
This site is only for bug reports. For technical support please use the Mojang Support Center. |
| Comment by Bob Dobbs [ 10/Sep/14 ] |
|
turn off mipmapping in the minecraft video options. It is a workaround at least, though the only difference I've seen with mipmapping enabled is that you get these lines. |
| Comment by kingsomeguy [ 10/Sep/14 ] |
|
My driver overrides do absolutely nothing to minecraft. In my case, it seems minecraft ignores them and does its own thing, and therefore I have to rely on minecraft's own settings. |
| Comment by jonathan2520 [ 10/Sep/14 ] |
|
Can we limit discussion to the actual bug? It sure sucks when your driver overrides are causing trouble, but that isn't Minecraft's fault. Open your control panel and disable said overrides. Whatever is left after ruling those out may be Minecraft's doing. The problem will likely be much less significant or even absent (on NVIDIA, apparently). Still worth fixing, but the point is to fix your own problems and focus here on what Minecraft itself is doing to cause things. |
| Comment by Jerry Tom [ 10/Sep/14 ] |
|
yes, but only a little because my particlar case is VERY bad. 10 blocks away its visable. and beyond that its unagnorable. (if it was not that bad I just deal with it. but its just HORRABLE. |
| Comment by kingsomeguy [ 09/Sep/14 ] |
|
NOR3N: Did you try to set Mipmap levels to 0? It seems to help me in 1.8 |
| Comment by Alfred [ 09/Sep/14 ] |
|
I still have no idea how to solve this issue in 1.8 I do not understand how downloading the snapshot would help since I want to play in 1.8 HELP PLEASE D: |
| Comment by Jerry Tom [ 09/Sep/14 ] |
|
I suspected that. but I have not been able to figure out how to execess the menu that will allow me to change that. |
| Comment by jonathan2520 [ 08/Sep/14 ] |
|
Dragon352: Your driver is set to force anisotropic filtering. That's the culprit. Perhaps Minecraft should attempt to detect these problems and warn the user. That might reduce the false positives a little. |
| Comment by Jerry Tom [ 07/Sep/14 ] |
|
just another example of this bug in the 1.8 update. it could just be a problem with my graphics card settings. but I have tryed to change them. have been unable to find them in the first place |
| Comment by Marcono1234 [ 26/Aug/14 ] |
|
No, I meant there are some stripes in a cloud between each cloud segment (so it seems like a cloud consists out of segments), |
| Comment by jonathan2520 [ 25/Aug/14 ] |
|
marcono1234: Clouds are just the eternal |
| Comment by kingsomeguy [ 22/Aug/14 ] |
|
I still have the same problem in 14w34d. In 1.7.10, I was able to fix this by setting the ingame anisotropic filtering to 16 and keeping mipmap levels off. |
| Comment by a [ 13/Aug/14 ] |
|
I'm curious what the status of this ticket is from the perspective of Mojang. In any case, 14w33a can be added. I've not been able to see this problem at all with mipmaps turned off, but it's everywhere when it's on. |
| Comment by Marcono1234 [ 31/Jul/14 ] |
|
Maybe confirmed for
|
| Comment by jonathan2520 [ 27/Jul/14 ] |
|
necril: Don't force anisotropic filtering on Minecraft. |
| Comment by Vasil Bochev [ 27/Jul/14 ] |
|
Very clearly seen... They fade over in long distance. |
| Comment by Marcono1234 [ 20/Jul/14 ] |
|
It seems like it doesn't matter, I changed everything but the white stripes stayed They are now already really hard to detect as they only appear in a special angle and maybe also direction ? |
| Comment by NekoJonez [ 19/Jul/14 ] |
|
@Marcono1234 , what's are your video settings? |
| Comment by Marcono1234 [ 19/Jul/14 ] |
|
Confirmed for 14w29b |
| Comment by Zan Zurathi [ 17/Jul/14 ] |
|
If you have an Nvidia GPU, this can be caused by setting image settings to "Use advanced 3D image settings". To solve, go to your Nvidia Control Panel and go to 3D settings > Adjust image settings with preview and select "Let the 3D application decide". This will not solve issues on non-Nvidia graphics cards. |
| Comment by jonathan2520 [ 08/Jul/14 ] |
|
Anisotropic filtering was a strange beast that would sometimes help and sometimes break things. Just a little bit of AF could be beneficial because Minecraft would add significant leeway at the edges. Obey this inequality to avoid the worst problem where you'd be guaranteed to sample well into other textures at certain angles: AF * 2^mipmaps ≤ texsize. I can't guarantee that it'll be perfect because AF is very GPU-dependent and generally somewhat finicky. Actually mipmaps without AF seem to produce more random speckles than no mipmaps and no AF, I believe mostly on Radeons. Go figure. If there's one thing to learn from this, it's that sampling near discontinuities in a texture atlas is never a good idea. It'll always break one way or another if you do. Perhaps one day Minecraft will be able to utilize array textures or another clever solution. Shaders are being introduced to Minecraft already. I hope Mojang will realize they can't just be used for special effects, but also to tweak mundane parts of the pipeline. I have suggested this before, I think even on Get Satisfaction. |
| Comment by Licht [ 08/Jul/14 ] |
|
14w27b: You can see the plains through the black walls and the void is visible between the grass blocks. This doesn't appear near the player. It seems that Anisotropic Filtering >0 could fix that (in 1.7.*), but this isn't available in the snapshot. |
| Comment by user-c9795 (Inactive) [ 01/May/14 ] |
|
Confirmed on 14w18a - Java 8 Update 5, Radeon HD 6580 [13.12 WHQL], Windows 7 64bit |
| Comment by a [ 30/Apr/14 ] |
|
Similarly to the Intel HD 4000, my ATI Radeon HD 4670 256 MB has stitching, but if you turn on Anisotropic Filtering (it actually works on this card), the stitching is gone. Clouds still have it a little, but everything else is good. |
| Comment by Alex de la Cruz [ 30/Apr/14 ] |
|
I tried 14w17a (on my Mac) today and the clouds still have a bunch of lines constantly, it is really annoying. Should I post a pic of them? |
| Comment by a [ 30/Apr/14 ] |
|
Also 14w17a On my MacBook Air (Intel HD 4000), turning on Anisotropic Filtering beautifully eliminates these stitches. And by eliminates, I mean COMPLETELY eliminates (clouds, solid blocks, water blocks). However, the AF itself is not fully baked with the Intel HD 4000, so it causes blurred textures. (see |
| Comment by MisterSanderson [ 19/Apr/14 ] |
|
Still present in 1.7.9 clouds. |
| Comment by WolfieMario [ 15/Mar/14 ] |
|
Confirmed in 1.7.5 and 14w11b. Can the Affects Versions tags please be updated? |
| Comment by MisterSanderson [ 14/Mar/14 ] |
|
Still present in 1.7.5, on the clouds. |
| Comment by Anon Ymus [ 20/Feb/14 ] |
|
Yes, on MCPE. This tracker is for bugs in the PC version only. |
| Comment by PTR_91 [ 20/Feb/14 ] |
|
This also occurs in PE on an iOS 7.0.6 iPad 2 with 16GB of memory. Should I create a separate bug report for that? |
| Comment by Michael Farquhar [ 20/Feb/14 ] |
|
Not had this issue before but it's pretty bad in snapshot 14w08a. Tried turning off the Antialiasing in the Nvidea settings but to no effect. |
| Comment by PTR_91 [ 20/Feb/14 ] |
|
Still in 14w08a. I don't have the anti-alias shader or anti-aliasing on my graphics card. |
| Comment by Th3F4114n0n3 [ 04/Feb/14 ] |
|
Can confirm with water. This isn't my normal computer so I will open when I get home a confirm again. I attached some images |
| Comment by Dave Mills [ 03/Feb/14 ] |
|
I just built a new computer yesterday and have not run into the white stitching issue yet. I am running a GeForce GTX 770 OC edition graphics card, in case that information helps. In the event I do come across any white stitching I will update here with specifics and hopefully pictures. |
| Comment by PTR_91 [ 31/Jan/14 ] |
|
Occurs on held items. |
| Comment by CharlesC [ 23/Jan/14 ] |
|
For latest snapshots (at least last 2), the white dot is back when looking at the water (like seas) |
| Comment by Antti Harju [ 28/Nov/13 ] |
|
With NVIDIA graphic cards just return your setting to factory defaults from NVIDIA control panel, that fixed it for me. |
| Comment by mike [ 26/Nov/13 ] |
|
This bug is so bad, that when I look at a hill, almost every single block is affected. I'll upload a screenshot soon. |
| Comment by GoodKingFilms [ 26/Nov/13 ] |
|
When you are in 1.7 go to "Options" -> "Video Settings" -> scroll down ans set "Mipmap Levels" to "OFF". |
| Comment by matthew garcia [ 19/Nov/13 ] |
|
Anyone still having this problem in 1.7.2 :/ because my stupid gtx 670 likes to make white dots in minecraft HELP!!!! |
| Comment by yut951121 [ 16/Nov/13 ] |
|
Can confirm in 1.7.2 with hoppers |
| Comment by Dave Mills [ 28/Oct/13 ] |
|
thats what I assumed, as my girlfriend plays on her acer laptop that has built in graphics, and she gets the same thing. |
| Comment by Emoluvjd2 [ 28/Oct/13 ] |
|
Never mind that part in that case. The issue must be in Minecraft's rendering rather than hardware, then. |
| Comment by Dave Mills [ 27/Oct/13 ] |
|
Well I am using a Nvidia card and the same thing is still happening to me. |
| Comment by Emoluvjd2 [ 27/Oct/13 ] |
|
I think the issue might be caused by Radeon graphics cards, it also happens at the edges of clouds. (As in the edges where two clouds meet, since clouds are made up of individual squares.) My graphics card is a AMD Radeon HD 7560D. |
| Comment by Moo [ 26/Sep/13 ] |
|
I would say the new (mipmapping) issue should perhaps be a separate ticket from the old pixels in texture one. New one is apparent gaps between blocks in distance. |
| Comment by [Mod] Pokechu22 [ 24/Sep/13 ] |
|
Mipmap levels at 4 makes this realy bad. |
| Comment by jonathan2520 [ 19/Sep/13 ] |
|
Extreme manifestation of crazyman's problem:
Something about looking at surfaces edge-on goes awry. Snapshot 13w38a; Mac OS X 10.8.4 (about to update!); Radeon HD 5000 series. |
| Comment by jonathan2520 [ 19/Sep/13 ] |
|
There have definitely been some changes. As far as I can tell mipmaps are pretty harmless as they align perfectly and the kernel used to generate them has minimal support. YMMV depending on your textures. Anisotropic filtering will sample outside the intended part of the texture. It appears it wraps around into the same texture, but that doesn't always work well, especially if the texture doesn't wrap cleanly (e.g. side of grass). Both settings mess up transparency depending on the derivative of texture coordinates. Leaves are a prime suspect (with fancy graphics enabled, of course). Glass is another contender, but I find it's more benign in practice. Yeah, one advantage of not filtering at all is that stochastic behavior is invariant with respect to the function applied to the result, even if it's nonlinear. I'm glad that much of the aliasing has been killed, however. I'm not sure what else is going on, and don't feel like figuring it out at the moment. |
| Comment by crazyman [ 19/Sep/13 ] |
|
Also there is white lines when you look at anvil in your inventory |
| Comment by crazyman [ 19/Sep/13 ] |
|
Ok, this bug just went 200% worse in new snapshot! I tried every possible setting in video settings menu and now its really bad.
|
| Comment by Anton Malmgren [ 10/Aug/13 ] |
|
It seems like alot of people are affected by this at the moment, iMac (OS X) ver. 10.8 They all have the same problem with those stitches between blocks, all computers also have flickering if you're looking at for example leaves from a distance, walking into a forest and seeing all the flickering is really ugly and annoying, and it's ruining the game experience. Note - all blocks actually are flickering from a distance. Minecraft's graphical issues seems to be these at the moment, which I've noticed so far: I've tested with optifine and not optifine, no difference. Please fix this, I don't want to waste ANY more time to this, I've literally spent 20 hours + trying to find a fix, researching etc. |
| Comment by Diego Meneses [ 01/Aug/13 ] |
|
I think the solution is re-downloading Minecraft, I had this problem one hour ago and I re-downloaded it and now it's fine, I no longer have these strange lines. |
| Comment by Kumasasa [ 19/Jul/13 ] |
|
@Brian Roach: |
| Comment by Daniel "Glampkoo" [ 19/Jul/13 ] |
|
I have another laptop which is pretty good amd graphics with intel core i5 and these lines don't appear! |
| Comment by Brian Roach [ 19/Jul/13 ] |
|
Oh my god, bug or not I have this problem in such bad situations. I use AMD, does anyone else use AMD? |
| Comment by jonathan2520 [ 10/Jul/13 ] |
|
That is the bug. Well, the bug as it was before a separate 1.5 bug hijacked this thread, and after that was fixed. It is fixable, but as the fix makes things slightly more complicated they just don't bother. I'm not even sure if they're even qualified to do this, to be honest. Feel free to take that as a challenge, Mojangstas! |
| Comment by Brent Snyder [ 10/Jul/13 ] |
|
I have that too, but I don't think it's a bug. I think it's one of those "unfixable" things in the game. I don't know what "unfixable" means, but, meh. .3. |
| Comment by Byron [ 10/Jul/13 ] |
|
I've never witnessed that bug. The bug I've seen is a transparency issue where you can see in between what are normally opaque blocks at the edges. It's not as bad as it has been in the past, but it's still visible in small dark corridors at corners where blocks meet. |
| Comment by Anon Ymus [ 10/Jul/13 ] |
|
Are you sure you aren't seeing |
| Comment by Byron [ 10/Jul/13 ] |
|
This issue also affects version 1.6.2 |
| Comment by [Mod] Pokechu22 [ 25/Jun/13 ] |
|
@Manuel Since that issue is closed, your best option is to get optifine, which is not official, but may help you. |
| Comment by Manuel [ 25/Jun/13 ] |
|
you're right, thx for the info |
| Comment by Tails [ 25/Jun/13 ] |
|
@Manuel: Your issue is |
| Comment by Manuel [ 25/Jun/13 ] |
|
still there in 1.6 on my nvidia graphics card, but not on the intel one !? |
| Comment by Acrivec Cevirca [ 06/Jun/13 ] |
|
____________________________________________________________________ And I can't use that, because anisotropic filtering is bugging my shaders on snow biome, ehh. But hope it help you. |
| Comment by MegaScience [ 29/May/13 ] |
|
I was testing things in Snapshot 13w21b and noticed this still appears on the inner edges of hoppers. Not sure if 13w22a will fix it, but keep keen to that for tomorrow as well. |
| Comment by Christen Lofland [ 16/May/13 ] |
|
Here are the dots I see. |
| Comment by Dave Mills [ 14/May/13 ] |
|
Ive been having this same issue since before launch. It went away for a little while, but since 1.4.7 its back and even more noticeable. |
| Comment by jonathan2520 [ 06/May/13 ] |
|
What does it really accomplish in Minecraft, though? Anything a particular wrap mode might fix at the texture border won't mean a thing for most edges in the atlas. GL_CLAMP is also equivalent to GL_CLAMP_TO_BORDER using nearest filtering, and a really stupid blend using linear filtering. Better to be ignore GL_CLAMP and use either GL_CLAMP_TO_EDGE or GL_CLAMP_TO_BORDER as desired, but I don't see how it would fix much here. I'm not sure why you're concerned about borders. Minecraft doesn't use them, except by texture accesses accidentally straying over the edge as we've all seen here. And that applies to all edges in the atlas, not just the border of the entire texture. If you ever want to use linear filtering for some reason, switching to the right wrap mode is the least of your problems. I really hope you meant edge texels, by the way, because border texels are an ugly matter that I hope I shouldn't have to explain to those responsible for the game. In short: stay away from those. |
| Comment by [Mojang] Grum (Erik Broes) [ 06/May/13 ] |
|
@sam: you are right about the GL_CLAMP / GL_CLAMP_TO_EDGE. Changed it to GL_CLAMP_TO_EDGE now. I'm slightly worried for weird artifacts where we populate the outer border of pixels (or a texturepack does that). Not sure what the result will be when that happens. |
| Comment by sam [ 05/May/13 ] |
|
Also 2013-03-06_14.50.13.png looks like a separate issue to me, as the lines are not just at the edge. |
| Comment by sam [ 05/May/13 ] |
|
I have this issue with a nvidia card on linux. Assuming you have the nvidia drivers, this can be solved by opening up the nvidia control panel and ticking Use Conformant Texture Clamping under OpenGL settings. This "replaces GL_CLAMP with GL_CLAMP_TO_EDGE for border less 2d textures, eliminating seams seen at the edge of textures in older games such as quake3"(quoted from the control panel), I suppose this may be fixable in the code also (not just a graphics driver issue), if the call to GL_CLAMP was replaced with GL_CLAMP_TO_EDGE |
| Comment by Ivo Huigsloot [ 22/Apr/13 ] |
|
For Windows nVidia Video Cards: 1. Right-click on desktop and click NVIDIA Control Panel For Windows ATI Video Cards: 1. Right-click on desktop and click Catalyst Control Center It has help's my. hope it works for you. |
| Comment by Kumasasa [ 17/Apr/13 ] |
|
@Ben W: Your issue is |
| Comment by Ben W [ 17/Apr/13 ] |
|
For me, forcing anti-aliasing on my nVidia GeForce GT 555M causes this issue; however installing Optifine and enabling anisotropic filtering eliminates it. |
| Comment by Kumasasa [ 14/Apr/13 ] |
|
@Antti Harju: Your issue is |
| Comment by Antti Harju [ 14/Apr/13 ] |
|
Still having same problem with 1.5.1 |
| Comment by Alex de la Cruz [ 22/Mar/13 ] |
|
@Etan: of course this was reopened, the issue is not yet fully fixed |
| Comment by Ethan Shaughnessy [ 22/Mar/13 ] |
|
I'm just saying that there was NO point in reopening this since it says in the description: |
| Comment by Maarten Thijs [ 21/Mar/13 ] |
|
da's fijn merlijn |
| Comment by MtH [ 21/Mar/13 ] |
|
Fixed for me in 1.5.1, using ATI Radeon HD 4600 Series. |
| Comment by Freek Schoenmakers [ 19/Mar/13 ] |
|
This bug still persists in 1.5 pre-release. I guess the texture is being rendered smaller than the block is. |
| Comment by jonathan2520 [ 17/Mar/13 ] |
|
alexnder: Sometimes 'round enough' floats can be used to get an exact result. My proposed shader actually takes advantage of that to make vertices line up. All you need is very controlled conditions. Short version: it's not gonna fly. |
| Comment by Markku [ 17/Mar/13 ] |
|
Uh oh, that shown example for rounding isn't a very good one for floating-point math. And it is also a bit inefficient (using division); suitable IEEE-floating-point rounding can be made with a small number bit-operations and add/subs. I really recommend reading about technicalities of floating-point values... So many traps and pitfalls with them. Also, the texture coordinates are initially calculated "correctly", there is no need to round them or "snap to grid". |
| Comment by alexnder shapkin [ 17/Mar/13 ] |
|
@jonathan2520 and other developers if the geometry is correct, you can snap texture coordinates to the grid. they are usually not very large values. float f_round (float f) { float fsnap (float value, float cell) { it will reduce the accuracy of positioning the texture and probably will remove the computing error. /sorry for my bad english/ |
| Comment by [Mod] Pokechu22 [ 16/Mar/13 ] |
|
I'm happy so long as the random giant lines are gone. The small dots aren't so bad. |
| Comment by Nicolas [ 16/Mar/13 ] |
|
As said above, the bug is still occurring on the edges of chunks (which means that it has been divided by 16). |
| Comment by [Mojang] Grum (Erik Broes) [ 16/Mar/13 ] |
|
As Tenebrae said, please try with the latest snapshot: http://www.mojang.com/2013/03/minecraft-snapshot-13w11a/ |
| Comment by Tenebrae [ 16/Mar/13 ] |
|
This issue has been reduced by tons in 13w11a, sometimes you can still spot the occasional white dot while being in a cave while it's day, but it's not much of a nuisance anymore. |
| Comment by jonathan2520 [ 15/Mar/13 ] |
|
George: I agree with Markku on that. Markku: I think I'm starting to lose track of what's what exactly. Good thing I don't have much to add anymore. Intra-section geometry is mostly correct, yes. I wasn't too clear on that. The main issue is T-intersections between things like blocks of different height. But that isn't nearly as noticeable as the other stuff. You're never going to get the texture coordinates completely right. They can be perfect when you feed them to the rasterizer, at which point the rasterizer will destroy anything that may have been. There are going to be errors in the initial projection. There are going to be errors in interpolation. There are going to be errors in the edges of the polygons themselves. The best you can do is to clamp to the desired range afterwards. Of which extending tiles is one form, yes, which may be viable for some purposes. Need much of it to support AF, however (if that even works on all GPUs), and don't even think about mipmaps. |
| Comment by Markku [ 15/Mar/13 ] |
|
George: both the texture and chunk size adjustments are kludges. Having been done before, or even being common solutions does not make them any better, just maybe more acceptable. Also, both the texture and chunk size adjustments are still part of 1.5. (Do not know about the new snapshot). However, the chunk expansion is "too small" to be fully effective. I elaborated that one earlier among the tons of comments in this issue. |
| Comment by Markku [ 15/Mar/13 ] |
|
Jonathan: In short
Details: Before working on the texture expansion (and also after switching to next clean set of source files), I also tried things with AF off and just adjusting the 0.01-pixel tweak (adding it to both start and end edge, not just the end, and also increasing it to various amounts upto 0.5). That "fixed" (and still does) the block edges, but not chunk borders or non-full blocks or blocks with special rendering (geometry adjustments!), like cactus. In 1.5 test, I didn't expand textures, didn't adjust chunk expansion factor, and AF is still off. If I can not see any dots between other than chunk borders, and I have only adjusted that texture 0.01-thing, it could be reasonable to assume that the geometries are exactly correct inside chunks. Also, at the very begin, I did first assume geometry differences to be the reason for those block edges, too, but I tracked all coordinates in those and they were always exactly "correct" values (when being pushed to the call lists). That is, the same vertex was definitely calculated multiple times, but the end result was always the same. That was expected, as I only tested full blocks, and all calculations were like 'integer' + 'float with integer value'; those can be done exactly. This is not certain, but this is how I currently think it can happen for the block edges: The dots at block edges can also be created by similar floating-point errors at texture coordinates. And texture coordinates are not integers, or even nice multiples of 1/2^n - that 0.01F already breaks everything on exactly same values. Of course, for the same block type, the texture coordinates are exactly the same for each, but once the texture coordinates are combined with the block's (exactly correct) vertex coordinates, floating point accuracy will not be enough to handle the results exactly. As end result, textures will be drawn by occasionally slipping microscopically to the neighbor texture's side; sometimes wrong color pixel, sometimes transparent pixel. Well, whatever the reasons are, I've described changes that are visually undetectable changes and have fixed things for me and my setup. And the texture expansion-trick was, imho, best, as it handled two things at once (allowed AF and fixed block edge dots) and perfectly; every texture is drawn without any 0.01 adjustments, as accidental slip out of the texture's proper area will just hit the expanded pixel of the same texture instead of incorrect color of neighbor texture. Throw in the kludge of chunk expansion increase and I see no dots or lines anywhere (not even in distance, although due to other texturing artifacts in distance, they might be there and just too difficult to spot). Personally, the current "fixed" version looks good enough to me, but I wouldn't mind the easy changes to be implemented (while waiting for better solutions), unless someone can prove they can look worse on some other computer setups. |
| Comment by George Gates [ 15/Mar/13 ] |
|
I agree with Jonathan that many people who say this issue still happens either aren't in a fixed version or still have AA/AF settings, which would cause it on 1.4.x and earlier too. However I disagree that the texture stretch is a kludge, since it's what Minecraft used to do as well, right? And it just was not implemented when the texture format was changed because it has a new author (Dinnerbone) who did not know about the fix that had to be implemented by the old author (Notch, who no longer works on Minecraft). |
| Comment by jonathan2520 [ 15/Mar/13 ] |
|
Markku: But the texture problem you experienced in 1.4.7 was due to forcing AF on Minecraft, right? It would be nice if that didn't happen, but that isn't a bug. Also, textures don't care about section boundaries. The block boundaries that happen to run along them have no special status. Yet the cracks only appear along section boundaries. The thing about cracks is that they form whenever vertices don't line up exactly. It doesn't matter if they're very, very close. If they aren't exactly equal, cracks will form. Cracks magnify errors, really. If you've ever done OpenGL or the like, you'll know that they will form exactly as they do in Minecraft when you try to line things up using matrix transformations, exactly as Minecraft does. Increasing the expansion factor would only 'fix' the issue from certain perspectives. I would be okay with it as a temporary bandage, but it's not that hard to do right. I think texturing is pretty much okay now. The 0.01-pixel tweak is a kludge indeed, but it seems robust enough. It's hard to do much better with those über-finicky texture atlases. Array textures spring to mind, if you're willing to rely on that feature and make all tiles the same size again. You could also pass on some extra information to a complex pixel shader which would then try to sort it out. Without really helping texture filtering, I should add, unless you implement much or all of the texture filter in the shader. I suspect the people who still have problems either
Until someone shows competence and the ability to control those factors, and yet has the problem, I won't change my mind. It's the same reason astronomers rarely see UFOs, even though they look at the sky all the time; they know what they're looking at. If anyone wants to contest me, demonstrate that you know what you're looking at. |
| Comment by Markku [ 15/Mar/13 ] |
|
jonathan: Perhaps I should have been more detailed; I knew about the chunk border geometry inaccuracies, but overly simplified my response to alexnder, as he also oversimplified his claim of the reason being only geometry. Well, afterwards I can now see that he might have referred only to the remaining geometry issue. In 1.4.7, as far as I could notice, the major part of problems (ones between every block) was due to texture stuff, minor part (between chunk borders) was due to geometry and possibly combined with texture (since chunk borders are also block borders). And having 15x more non-chunk border block edges than chunk-border block edges, the block edges make bigger effect. That is, in 1.4.7, adjusting block vertex coordinates to match neighbors' vertices would not have made a big difference, as they were already (mostly) exactly the same. Otherwise my texture tweaks wouldn't have (mostly) fixed things. I just did the same test on 1.5 (not the new fixed version snapshot). The code is essentially the same as in 1.4.7 (for math), just a bit reorganized. And I got exactly the same results: increase texture margin and problems go away between blocks, but the minor problems between chunk borders remain (which was geometry related in 1.4.7, too). Thus, even with perfect geometry (vertex locations), but keeping texture handling as it was, there would still be issues. Both problems must be handled. Apparently, Mojang already adjusted the texture coordinate handling back to the 0.01 pixel "zoom in", which, while being a minor kludge just like the chunk geometry expansion factor, works well for that part. (Though it still leaves AF support on my setup useless. I have hopes for future support for AF even on my setup, as I already proved it is possible in practice.) And as I tested (in 1.4.7), increasing the chunk expansion factor a tiny bit (still well below noticeable to human) improves that just as easily and effectively, even if not perfect solution. It does not have to be the final solution, but it is something that can be done in two minutes, and would likely make a lot of people "happy enough". (As it seems that some people still have big problems even with the new "fixed" version, the changes so far discussed (except the fancy shader stuff) might not make everyone happy, but isn't an improvement for some (without bad side effects) better than have no improvement at all for a long time?) |
| Comment by Nicolas [ 15/Mar/13 ] |
|
@Alejandro |
| Comment by Alex de la Cruz [ 15/Mar/13 ] |
|
@Nicolas, thats why im saying it does not fix the bug, if it would then this bug report would not have been reopened. If you tell people that 13w11a fixes the bug, then people will come back here and complain when they see the bug is not fully fixed. and its not just lava, theres several other things that still show the bug, for example hoppers, trap doors.... |
| Comment by Nicolas [ 15/Mar/13 ] |
|
@Alejandro |
| Comment by jonathan2520 [ 15/Mar/13 ] |
|
Markku & alexnder: No. The issue is that each section is rendered using its own local coordinates, using a transformation matrix to move it in place. The math is sound as you can tell by sections being where they should be. But using this approach there will be rounding errors, so adjacent 16x16x16 sections (you can tell that's where the cracks are) won't line up exactly. They just won't, no matter how tiny you imagine the error to be. A possible fix would be to keep all vertices in one huge global coordinate system. But that causes single-precision floating point to run out of precision too quickly for a vast world like Minecraft's. Moving the origin once in a while—for every section at the same time—could fix that, but at the cost of a huge computational spike because all chunks have to be recomputed. It's possible to spread it out over time, at the cost of possibly lower performance for a minute, during which artifacts will momentarily appear. I had proposed a shader-based solution in We've had shaders for a while, you know. GPUs are pure shader processors nowadays. The fixed-function pipeline is implemented through shaders. It's more efficient to write a shader that does exactly what you want, skipping redundant fixed-function computations that couldn't be optimized away, and saving the driver the headache of creating optimized shaders for each state. You don't have to do it for teh shiny. All you'll lose is your retro OpenGL 1.2 or whatever it is nowadays, but the fact is that any computer that can reasonably run Minecraft has a much more modern feature set. |
| Comment by Alex de la Cruz [ 15/Mar/13 ] |
|
@Nicolas: you clearly have not read all the comments. If you would have you would know that 13w11a does not fix the problem, it only makes it less noticeable. |
| Comment by Nicolas [ 15/Mar/13 ] |
|
AGAIN, it has NOT been fixed in 1.5, the fix WILL COME IN A FUTURE UPDATE (probably 1.5.1 in a few days). |
| Comment by McMacker4 [ 15/Mar/13 ] |
|
Ok, everyone says it's fixed but not for me, I still get these spaces between textures and it's EXTREMELY annoying. I'm using 1.5 official release... |
| Comment by Markku [ 15/Mar/13 ] |
|
to Alexnder: at least in 1.4.7, the dots were caused by correctly (accurately) calculated texture coordinates slipping out of the texture (by drivers or something). Geometries (vertices) were all correct (at least inside each chunk). So trying to improve vertex coordinates would not have helped. Of course, 1.5 may now have different code. |
| Comment by alexnder shapkin [ 15/Mar/13 ] |
|
to Nathan Adams: |
| Comment by Emoluvjd2 [ 15/Mar/13 ] |
|
This bug was not present in 1.4. You might have an issue with your graphics card, Tavis. |
| Comment by Tavis [ 15/Mar/13 ] |
|
It seems to be about as common in 13w11a as it was in 1.4. |
| Comment by Jimmy Andrews [ 15/Mar/13 ] |
|
I never had this issue prior to 1.5. The current snapshot, 13w11a, resolved the issue for me. Win8 x64, using a legacied ATI card with the latest available drivers for it. |
| Comment by Rickard Åberg [ 14/Mar/13 ] |
|
Well, for me it's much better than 1.5 but not perfect, I still see the stitching in certain places. |
| Comment by Tails [ 14/Mar/13 ] |
|
Reopened. |
| Comment by Freek Schoenmakers [ 14/Mar/13 ] |
|
13w11a Did NOT fix this bug. It is still present, and it doesn't seem to have become less. Maybe slightly, but it is still there, just as notably as before (just visit a taiga biome, it's horrible). |
| Comment by Jeff Bowman [ 14/Mar/13 ] |
|
This bug still exists in 1.5. I'm using a Radeon 5770. Using antialiasing after installing Optifine helps a little but not entirely, and unfortunately Optifine introduces its own issues as well for the time being so I removed it. The speckles are so distracting that I'm back on 1.4.7 for now. |
| Comment by Alex de la Cruz [ 14/Mar/13 ] |
|
This bug still occurs in 13w11a, specially with diagonal columns of lava. If you place 3 columns of lava diagonally like this: http://i.imgur.com/AHobtjM.png (if you want to test this, make sure to dig a hole under each column so that the lava does not spread all over) |
| Comment by Antonio [ 14/Mar/13 ] |
|
Thank you! Still present in 13w11a but only while moving. As soon as the camera comes to a halt the dots disappear. |
| Comment by Anon Ymus [ 14/Mar/13 ] |
|
You can download 13w11a if you want it fixed. |
| Comment by Antonio [ 14/Mar/13 ] |
|
1.5 official release, no mods, default TP; |
| Comment by Ryan S [ 14/Mar/13 ] |
|
The second fix greatly improved the issue for me. While I did not notice this white stitching prior to 1.5 and its snapshots, I can confirm that this issue has been somewhat prevalent since Alpha. Perhaps I (and others) did not notice this before because I was not looking for it and its effects were minimal. It seems that hardware has nothing to do with this issue and the effect is not generated due to AA settings (although improper AA settings may worsen the appearance). Hopefully 1.5.1 (looking like it will be out within a week or so) will bring enough closure to this topic so that we can all get back to playing this great game without spending more time than we have to in the bug tracker! |
| Comment by Nicolas [ 13/Mar/13 ] |
|
It seems it has been fixed for me too. Good job |
| Comment by S van Cuijk [ 13/Mar/13 ] |
|
the fix works fine for me - Radeon HD 4200 |
| Comment by S van Cuijk [ 13/Mar/13 ] |
|
@CubeTheThird I dindn't see dinnerbone's comment with the fix, sorry |
| Comment by [Mod] CubeTheThird [ 13/Mar/13 ] |
|
@S van Cuijk, Åxçel Greer: do you mean to say that the pre-release has caused these results, or that they are present with the fix? |
| Comment by Åxçel Greer [ 13/Mar/13 ] |
|
1.5 Has made it worse for aswell, |
| Comment by George Gates [ 13/Mar/13 ] |
|
@Deadlock989: No Optifine, and you're sure that your CCC install isn't applying AA/AF, right? |
| Comment by Deadlock989 [ 13/Mar/13 ] |
|
minecraft_test_whiteline_2.jar does not work for me. The result is different than before but equally bad. Most blocks are edged with blue/transparent pixels; flowers all have a "garbage X" above them. The effect is much worse on distant terrain because the blocks are smaller and therefore "edges per square inch" is much higher. Windows 7 64-bit, Nvidia GeForce 9800GT. |
| Comment by Steve Dawson [ 12/Mar/13 ] |
|
Much better, but it still happens. http://i.imgur.com/uJKxWRN.png Windows 7, 64 bit, Radeon 4890 |
| Comment by Rickard Åberg [ 12/Mar/13 ] |
|
Works here as well, AMD Radeon HD 6970. Good, good. |
| Comment by Sir TLUL [ 12/Mar/13 ] |
|
Fixed for me, ATI Mobility Radeon HD 4670 on 64-bit Linux. |
| Comment by Kumasasa [ 12/Mar/13 ] |
|
Fixed. AMD Radeon 6700 |
| Comment by Kumasasa [ 12/Mar/13 ] |
|
@Alejandro de la Cruz: That a completely different issue: |
| Comment by Alex de la Cruz [ 12/Mar/13 ] |
|
Theres a pretty strange bug in this new minecraft_test_whiteline_2.jar. If you try to place a painting, it dissapears as soon as you place it. You can do this several times, and if you then break the block they were on, all the paintings will pop out. I tried to place several paintings in the minecraft_test_whiteline_2.jar and then i switched to the 1.5 pre-release .jar and to my surprise, all the paintings were on the wall. image: http://i.imgur.com/h3KowrR.png EDIT: The reason I thought this was a bug from the test build was that going back to 1.5 pre-release after trying to place some paintings made the ghost paintings appear, so I didnt think it was from 1.5 pre-release. |
| Comment by Callum Tennant [ 12/Mar/13 ] |
|
@Daniel The pre-release IS the actual release, just not OFFICIALLY released. The pre-release is the one everybody will receive when it is released. If Mojang want to add any other fixes, it will be in 5.1. |
| Comment by Daniel "Glampkoo" [ 12/Mar/13 ] |
|
@Jelmer Why it won't be fixed in 1.5? Why not? All of the bugs can be fixed in the official launch! (13/3/13) |
| Comment by Mark Hogben [ 12/Mar/13 ] |
|
Fixed for me with that version - cheers, man! EDIT: As some people have said, there are still a few points at the corners of some blocks, but not that noticeably. Still, a massive improvement |
| Comment by Callum Tennant [ 12/Mar/13 ] |
|
Not fixed for me. AMD Raden HD 6670. |
| Comment by Jelmer de Haan [ 12/Mar/13 ] |
|
Wait... This fix ISN'T going to be in 1.5!?! |
| Comment by Moff Kalast [ 12/Mar/13 ] |
|
Works great thanks |
| Comment by Maarten Thijs [ 12/Mar/13 ] |
|
It's 100% fixed for me. only redstone torches have a few dots in the corner but man! love you dinnerbone! |
| Comment by Alex de la Cruz [ 12/Mar/13 ] |
|
It is not entirely fixed for me, its a little bit better, but I still see this bug. heres a pic: http://i.imgur.com/itGqHgg.png |
| Comment by Anon Ymus [ 12/Mar/13 ] |
|
As far as I can tell, it's fixed for all blocks, but entities such as minecarts are still affected. |
| Comment by Ville Selkämaa [ 12/Mar/13 ] |
|
This is now 99% fixed.It still happens but if you don't pay attention you don't even see the bug.--->now there is no lines but in very dark places I can see little DOTS.But it doesn't matter |
| Comment by jonathan2520 [ 12/Mar/13 ] |
|
You're welcome. I wouldn't say it's entirely resolved, however, because the original bug (the reason this was originally reported for 1.4.1, and could've been reported much, much earlier) is still there. It's hard to capture a convincing still, but dots are still popping up willy-nilly along section boundaries. |
| Comment by [Mojang] Nathan Adams [ 12/Mar/13 ] |
|
The texture margin code from our last attempted fix was incorrect, we rewrote that part and it now correctly has a 0.01th of a pixel margin inside the texture when applying into the world. |
| Comment by Chloe Idun Anderson [ 12/Mar/13 ] |
|
Hooray! Now I won't get 12 emails a day from whiners carrying on about this bug! Any chance of telling us how you fixed it? |
| Comment by Daniel "Glampkoo" [ 12/Mar/13 ] |
|
Great job dinnerbone! You squashed this big bug! |
| Comment by Marek Štěpánek [ 12/Mar/13 ] |
|
@Dinnerbone I can confirm, can't see any white lines even in completely dark black wool room. Awesome, thank you very much! |
| Comment by George Gates [ 12/Mar/13 ] |
|
And success! Core 2 Quad Q8400, Radeon HD 5770. |
| Comment by Joseph Fowler [ 12/Mar/13 ] |
|
Dinnerbone, The build provided almost entirely eliminates the white lines and dots for me. I occasionally still see an isolated dot or two, but this is very rare and on the whole it looks a TON better. My specs are Intel i5-3330, Windows 7 (64) and ATI Radeon HD 5450. Great stuff! Thank you for continuing to work on this issue and I really hope this fix makes it in to 1.5! |
| Comment by [Mojang] Nathan Adams [ 12/Mar/13 ] |
|
Someone with this issue please try this build and let me know if it help at all. For record, this is the second test-fix build. |
| Comment by Mark Hogben [ 11/Mar/13 ] |
|
Asus 7970 HD DirectII Top card here. Tried all kinds of Catalyst settings, no luck so far. Just adding my two cents - appreciate any work done on this (it's really off-putting underground!!) |
| Comment by Will Jones [ 10/Mar/13 ] |
|
Glad to see dinnerbone at least is tring to work on it, i ranted about this for awhile honestly on a few threads and after the pissed off-ness wore off i simply decided if MC was worth another upgrade to a already new PC i bought FOR minecraft..... and well basically i did, went out bought a nvidia card (wich is worse actually than my ati about 25-30 FPS worse on max everything)and this issue is 100% totally gone, funny because when i bought this pc setup i did research on what "plays" minecraft the best processor and videocard wise and made sure i got it on my new pc..... now i can run minecraft again and optifine actually helps me to get back to where i was performance wise, unlike my ati card wich ran better without optifine... and now i get the infamous nvidia driver crash nonstop on windows 7....... heres to hoping this gets fixed either way because personally i hate nvidia they have known as well about these driver problems and alot of people are complaining still nothing LOL.... EDIT - one thing i forgot to say was i have no problem understanding that PC games have a broad range of problems from many many setups and i totally understand its not easy to make a game 100% perfect on every setup out there, so in that resepct im not hating on mojang, they after all made my most favorite game that makes me go out and spend all this money on it, they didnt ask me to i choose to because of my love for the game. in short i just really would have felt alot better giving the money i just wasted on a new videocard to mojang as my old card worked fine pre this update but since i cant "not" update (play online and cant go without my mods |
| Comment by Vlastimil Taborsky [ 10/Mar/13 ] |
|
In a dark place, the game almost unplayable. When movement is quickly flashed bright artifacts. |
| Comment by jonathan2520 [ 10/Mar/13 ] |
|
Markku: Heh. I don't think AF has such a limit. Normally, when it's used with mipmaps, the distance between samples shouldn't be much larger than a pixel at that particular mipmap level. But if there are no mipmaps, I can see many implementations sampling the same spots of a higher-resolution mipmap level. Whatever real implementations actually do, I don't think you should assume it works like that on every GPU. Interesting about the chunk expansion factor. I hadn't seen that bit before. Unfortunately it's just a bandage that has its own set of problems. There is a distance/angle where cracks ("dots") will appear again, even though you have grown the chunks so they 'should' overlap. It's still best to align chunks perfectly, but that requires some actual thought and understanding. I'm not sure I can expect that from someone who 'cleverly' uses 0x1p-149. I take back my judgment that torches act weirdly. It turns out they're drawn at full width, even though only a few pixels in the center are filled in. That explains the lines that cut across adjacent blocks. I'm now certain this problem, as it started to appear in the snapshots, is caused only by textures. |
| Comment by Markku [ 10/Mar/13 ] |
|
jonathan: Darned, I had all my settings as "off/low" as they can be.. but AF was not set to use application settings (the settings was 'off' The consequence then is that the change I made earlier allows using lowest setting of AF without artifacts, at least on my setup. Higher levels of AF still cause same problems, but they start further away. Increasing the pixel copying range on the textures to 2 pixels allowed AF 4X, 4 pixels range allowed 8X. Probably etc. for 16X. Also, now without the AF, I was able to get the nearby "dots" back on 1.4.7 - but only if I disabled the edge pixel expansion. So my change handles both on 1.4.7: the nearby dots/stitching, as well as the lowest level AF. (For these dots, copying range of 1 pixel is enough.) That only left a little bit of dots along chunk borders. I managed get rid of those by increasing the chunk expansion factor from its original 1.000001F (which is too much for single-precision, and is actually the "nearest possible" 1.00000095367431640625, or 1 / 2^20 or 0x1.00001p0F) to 8 times larger 0x1.00008p0F (or exactly 1 / 2^17). |
| Comment by Freek Schoenmakers [ 10/Mar/13 ] |
|
I checked the forums and it seems to happen to all kinds of video cards, including nVidia, GeForce, ATI, AMD, Catalyst, etc... @Dinnerbone, So for some reason this is happening on (and I checked) all versions since Beta 1.8. I haven't checked the versions before that version. |
| Comment by Jelmer de Haan [ 10/Mar/13 ] |
|
Mojang, fix this BUG!!!!!! |
| Comment by jonathan2520 [ 10/Mar/13 ] |
|
I just tried 1.4.7 again for comparison's sake and found that Markku's "lines" are even harder to reproduce than I remembered. I need to set up the camera in a very specific way to get a few small lines. That's probably the reason I hadn't thought of those "lines" for 1.4.7; they're not a problem for me. Double-check that you are not forcing AA or AF on Minecraft. I also investigated 1.5-pre's code. It's a pain to interpret decompiled code without MCP's help. I did find a new abstraction that handles tiles. 0.01 is gone, but it does subtract 2^-149 (the smallest positive float) somewhere around there in the replacement. Quite obviously someone doesn't understand floating point! I could only change the abstraction itself because the class using it wouldn't recompile cleanly, hampering experimentation. Tweaking the constant causes textures to shift, not grow, interestingly by a different amount on each axis. Edit: The constant is probably subtracted from normalized texture coordinates. Perhaps the texture isn't square. There seem to be many typo-like inconsistencies as well. I couldn't possibly investigate all of that, however, with this non-compiling behemoth of cryptic identifiers. I'm done for now. |
| Comment by Markku [ 09/Mar/13 ] |
|
I did a quick try on 1.4.7 with the "add extra pixel-ring around textures"-idea. I didn't change the terrain.png, but added a piece of code that manipulates the loaded full texture suitably when needed (doubled total dimensions, moved the individual pieces apart, and copied the edge pixels of each contained texture one step outward on all sides). Then I modified the RenderBlocks.renderXxxFace() methods to take the new format into account (easy: x -> x*2+1 and /256 -> /512, etc). The old one-sided(?) 0.01 pixel squeeze was removed (no longer needed). (Btw, that part took about 2 hours.) After those changes, no more either kind of visual issues in sight... except on e.g. cactus (it has transparent pixels on edges and some extra geometry stuff going on, so I didn't even expect that one to behave). Of course, messing with the texture that way affects more places. Similar code changes would need to be applied to more places: at least special block types, with X-rendering (instead of cube, like panes and flowers), beds, etc., and inventory representations are funky... Animated surfaces seem to have their own rendering, so that is another place to go for, too, or otherwise oceans will still have nice lines all over. So, assuming something similar (the texture calculation slipping from edge-pixels out of the texture, to neighbor texture or just "out") affects 1.5-pre, adapting this change could one viable fix. (Somewhat wide assumption, yeah...) That was pretty much all that my skills allowed (mostly due to completely lacking any opengl skills). So, I think I'll also leave things at that, at least until I can get my hands on 1.5's code. |
| Comment by Callum Tennant [ 09/Mar/13 ] |
|
Ah, so that's what a line is. |
| Comment by jonathan2520 [ 09/Mar/13 ] |
|
If you want to be truly correct, I'd guess the "lines" appear when the derivative (in terms of screen pixels) of texture coordinates is too large relative to the margin of error. In layman's terms, the texture is shrunk too much as it appears on screen. Both distance and angle can cause it without the other, but of course a combination of the two only makes it worse. "Dots" and "lines" are slightly different expressions of thin lines. Stray "dots" are simply an expression of thinner lines, while more solid "lines" are thicker or just happen to line up with pixels. I'd be very careful about postulating causes based on prior experience (such as assuming "dots" and "lines" are still the same thing), because the very nature has changed. I will now shut up until I perform a proper analysis, or even just play the game again. |
| Comment by Markku [ 09/Mar/13 ] |
|
As I saw it in 1.5-pre, the "lines" were looking about the same as in 1.4.7: only at relatively small angles against the surface (typically happens via larger distances), but their colors might be different in 1.5-pre. If only looking at the distant line patterns, I would not be able to tell is it 1.4.7 or 1.5-pre running. What has changed (to my eyes) is the "dots", which now have different visuals (or at least they are that much more frequent that I can see the differences), and appear a lot more, and thus can even form something that resemble lines. (On 1.4.7, I had to especially look for these dots to notice). |
| Comment by jonathan2520 [ 09/Mar/13 ] |
|
Markku understands the issue pretty well. Indeed 1.4.7 could also produce such lines, but at least they were rarer and didn't appear up close. The issue you see with AA or AF is basically the same thing, except those step over the edge deliberately, not due to lack of precision. The OpenGL wrap mode (such as clamp or repeat) applies to the entire texture, so it isn't of much use to an atlas. |
| Comment by Callum Tennant [ 09/Mar/13 ] |
|
Oh, I thought it was the time of day which determined what you see between the blocks. |
| Comment by Markku [ 09/Mar/13 ] |
|
Wall of text, sorry, but its the details that matter. In short: check carefully which particular visual nuisance (of many) you're talking about, there seems to be more than one under this one issue. – Just to hopefully clarify a little bit, since this issue has been going so long it covers actually multiple different issues and from different implementations. That is, it would be best if people could check which exact issue(s) they are commenting about, so that things don't get unnecessarily mixed up. I just goofed around with 1.4.7 on these visual things. At first I saw two separate issues: the "transparent moving dots" (very minor thing, seen in nearby block edges) and the varying "colored moving lines" (much more visible, seen especially at distance and/or low angles). I managed control the 'dots-issue' at one point ("now here, now gone"), but then I tried to see how it looks on 1.5-pre... after I returned to 1.4.7 (on MCP), I could no longer reproduce the dots, no matter what I did, including restoring fully "original" MCP decompilation source files. Still haven't seen them. This is a "WTF!?!" category thing for a developer. Anyway, it was a minor issue, and since I could not reproduce it anymore, I decided to leave that one. I moved on to the lines. Mapping the textures to the block surface with a (literally) little bit different way (a half texture pixel "zoom-in"), all the lines disappeared. (I did that first only on the top surface of blocks, so that it affected only horizontal flat ground). Obviously, geometry is perfect, but textures were handled "badly". While I'm indeed an openGL-noob, a bit of googling seems to indicate that when textures are mapped from an "atlas", the calculated texture pixel location can apparently slip on to the area of a neighbor texture-square. And maybe even the texture "clamp" or "repeat" modes don't do what is expected (as they are set at the whole texture file at loading/setup time), but that is well beyond my skills, might be totally misunderstanding things on that. (Apparently, this is sometimes solved by using the obvious texture mapping, but adding an extra pixel on each side of the texture to handle those "slips". Sounds a bit iffy, inelegant, messes up the nice 16x16=256 etc., but hey, if it works..) The half-a-pixel mapping zoom-in was enough to ensure the rounding differences etc. never reached the neighbor. (Note, 1/4-pixel adjustment was not enough). Unfortunately, this makes the texture to miss half a pixel width around the edges, so not immediately a fix. Just a confirmation for this particular issue to have been related to texture coordinates/mapping/handling/whatever. – The visit on 1.5-pre revealed that both visual problems remain, and the edge "dots" issue has become much more visible. Naturally, can not dive into the code on 1.5-pre yet, so, can not say if either or both issues are related to the findings from 1.4.7. The lines on the ground (at distance) look similar to 1.4.7 ones, but if the way it handles textures was changed, I dare not to say it would be the same reason. The dots at edges seem to now suffer from multiple different kinds of issues. Some blocks show transparent pixels, some apparently almost random colors (at least not the colors that are behind the block), and for some blocks it seems to even depend on the particular edge (some edges even seem to be ok). – There, sorry, no solutions or even reasons for 1.5, but at least a hint to keep a better eye for the exact issue when talking about them. Otherwise we will send the 'bughunters' in the wrong direction and end up delaying the fix that hopefully comes some day. |
| Comment by Callum Tennant [ 09/Mar/13 ] |
|
Yes, I know about X-ray texturepacks. The title of this bug report is 'White stitching on polygon edges / White lines or black dots between blocks'. It should be 'Transparent lines/dots between block textures'. (Also, this != xray texturepack :|) |
| Comment by Moff Kalast [ 09/Mar/13 ] |
|
Of course they are transparent. Ever had an x-ray texturepack? This is the same thing. Well the problems seems to be in texture placement. In one of the snapshots there was a fix for iron bars so they are now a bit inside a block(if a block is placed above or below)for a simmilar ammount of space as these fractures are, and might be fixable the same way. Look I'm no modder and I have no idea how the texture applying works, but it's an idea. |
| Comment by Callum Tennant [ 09/Mar/13 ] |
|
Well, the lines appear to be transparent, rather than white. |
| Comment by jonathan2520 [ 09/Mar/13 ] |
|
There have been varying causes. The original pre-1.5 bug was caused by misaligned geometry, leading to holes. I'm not sure I understand the 1.5 bug (I haven't even played in a while), but textures seem to play an important role. The contents of said textures can be anything, including empty/transparent. The reason it's usually called white is that artifacts like these are most apparent when they're brighter than their surroundings, and when they are they look whitish to us. |
| Comment by Fjodor Dostojewski [ 09/Mar/13 ] |
|
Those problems are not just "white or black lines". As I mentioned earlier it's like there are gaps between the textures. You can clearly see this in most of the pictures above. It appears as if you can see through the textures to the things that are behind. Are the textures not close enough together in some cases? Those gaps get bigger if you go near them. So it's not just lines. |
| Comment by Moff Kalast [ 08/Mar/13 ] |
|
Well sonce Mojang is out of the question, can't we message some modders to look into this? Is there someone here who has connections? |
| Comment by Roy Fisher [ 08/Mar/13 ] |
|
^ The way things are going, he'll learn the same way the impact of the random fire flickering hit the developers; the hard way. I'm surprised I was the only one who brought that up, since it did end up getting an update to squash that specific bug. I hope you guys are ready for another string of updates like 1.4 had for a while, because I'm getting a pretty big sense of deja vu. |
| Comment by Callum Tennant [ 08/Mar/13 ] |
|
@moffkalast Nathan's already failed to realize the impact of this bug. As you can see, he really can't be arsed "undoing all of the texture handling rewrite" to fix a bug in his game which millions of people are facing. Oh well. |
| Comment by Moff Kalast [ 08/Mar/13 ] |
|
We need to share this page so it gets more votes and a higher priority of fixing(i hope), and someone has to change the enviroment as this doesn't happen only on Windows 7 64x. I am running Windows Vista 32x for example. |
| Comment by Thomas Strelecky [ 08/Mar/13 ] |
|
I've been experiencing this ever since I upgraded to the 1.5 pre-release, I was fine in 1.4.7. I don't find it that annoying (although caves look like they are full of fireflies), but I hope they fix it in a small update after 1.5 if they can. I know red3yz has this exact same problem, but he is able to play fine, and I am too. Hope this helps! |
| Comment by Callum Tennant [ 08/Mar/13 ] |
|
Well, with any luck somebody out there will create a mod fixing this bug. |
| Comment by George Gates [ 08/Mar/13 ] |
I was talking about the players... |
| Comment by Maarten Thijs [ 08/Mar/13 ] |
|
@Moff Kalast. three words: official Curse client just trying to help you guys |
| Comment by Moff Kalast [ 08/Mar/13 ] |
|
@George Gates well that doesn't help me alot (like i don't do it all the freaking time for private stuff), because all the players on the server wont be able to play since THEY all have the new version and the server doesn't. Great. |
| Comment by [Mod] Pokechu22 [ 08/Mar/13 ] |
|
Sorry to double post, but I now have evidence that the white stitching is actually transparent. With stone, it usually is you seeing the void. But you can see the transparency in this image. And I remember somewhere hearing about people using the transparency during beta to check for lava, I think. (I still think it is a bug, though. It should be patched. People who want x-ray should use glowstone or tnt) |
| Comment by [Mod] Pokechu22 [ 07/Mar/13 ] |
|
I remember that in some early version, there was a semi-bug where the corners would not mesh. I think that is one of the 2 bugs on this page, the more annoying one is the random lines. The first one may be a issue with the way the boundaries of blocks are calculated. The second one may be a side effect of the opengl no texture icon, maybe? If there is a way to change that icon I might test that, but I have no idea how unfortunately. |
| Comment by Roy Fisher [ 07/Mar/13 ] |
|
For those who don't know yet, this bug is MUCH worse in motion than on stills. The stray pixels change just about every time you move, be it your head (the mouse) or your body (WASD). It's also very prevalent during the daytime in dark caverns, though not so much at night where it's tough to notice without a Potion of Night Vision or maybe another light source. Also, when looking down I can see them being blue or sometimes even red, which leads me to believe that these stray pixels are transparent rather than colored (kinda like the Glowstone "x-ray" trick). I've only been able to spot it on stone so far, but considering that cave exploring is a major part of Minecraft and Stone is the main block of the underground that alone seems to be a rather annoying bug; one that, if in the official release, will likely cause an even worse ruckus than above. If anyone here remembers the hooplah over the random torch/furnace fire particle bug way back when, you know what I'm talking about; and that one had a work-around unlike here. |
| Comment by George Gates [ 07/Mar/13 ] |
|
Yes, because it's completely impossible to downgrade your Minecraft version in order to play on servers using older software. We all know that it's a painful, 4-hour-long process, and nobody's ever made tools to do it for you. Wait... |
| Comment by Moff Kalast [ 07/Mar/13 ] |
|
@Maarten Yeah good job on fixing over 60 bugs and making another 80 new ones. I really do hope ths gets fixed. And for updates, nobody asked Mojang to make these updates. I just gives servers, plugin makers, modmakers, and well literally everyone A TON OF WORK. As a former server owner i can tell you i'ts a pain to have to replace every single one of your plugins for some stupid update. BUT you have to because ALL of the players have tthe new update. Some of the best mods have beed broken because of updates. So, um no Mojang isn't doing us a favour. Well maybe to some retarded "i can has gaming" 8 year olds who have no idea what they are doing and are ALL EXCITED about some new blocks. And btw leave Steve alone, he has a point. |
| Comment by Maarten Thijs [ 07/Mar/13 ] |
|
@Mustek you are completely right. guys, what do you expect dinnerbone to do in his situation. @Steve you are insulting dinnerbone because he releases stuff with bugs in it, yet I know for 100% shure that other people would be insulting him if they delayed the updated for another few weeks. so it's a no-win scenario arguing is not a solution. to all the people complaining, if you think you can do better then mojang, then do so. if you got a fix, post it, but wait.. you all don't. |
| Comment by Alex de la Cruz [ 07/Mar/13 ] |
|
Agreed, this is not the place to complain and rant. |
| Comment by Mustek [ 07/Mar/13 ] |
|
Guys, back it off. This is a place to report bugs, not to cause drama. If you don't like, fine, but don't vent it on this bugtracker. |
| Comment by Moff Kalast [ 07/Mar/13 ] |
|
I agree with Steve, this is getting stupid. And yes they did "throw in a bunch of features like a bunch of 12 year olds". I blame Notch for leaving Minecraft in the hands of these guys. Development used to be more focused on making things better, not worse. |
| Comment by Deadlock989 [ 07/Mar/13 ] |
|
Just downloaded the 1.5 pre-release and was immediately confronted by a checkerboard grid of snow blocks that are edged with garbage. Just over the next hill, left the tundra biome and found some grass and trees - each block edged with sparkling white pixels. Other blocks such as leaves seem unaffected. Windows 7 64-bit, Nvidia GeForce 9800GT. Game is unplayable in this state. |
| Comment by John Smith [ 07/Mar/13 ] |
|
Could you at least tell us which GPUs this DOESN'T effect? Because I was dead serious when I said I'd rather fork out for a new graphics card than have to suffer from this bug. For goodness sake Steve, lay off. I'm as pissed as you are but insults are not the answer. |
| Comment by Tenebrae [ 07/Mar/13 ] |
|
Could you guys add some kind of fall-back for it though? An option to toggle to the old texturing system? |
| Comment by [Mojang] Nathan Adams [ 07/Mar/13 ] |
|
Yes, we do version control. Undoing this means undoing all of the texture handling rewrite, which means undoing pretty much anything that affected anything. And so, we're back to indefinitely not releasing an update until it's fixed. I'm sorry, but I'm not arguing this further. If it affects you so much as to the point where you can't play, then don't use the update. We aren't releasing because of just new features, but also new bugfixes - do you consider this small visual issue more important than extremely common world corrupting crashes, people who can't play at all, etc? This is all I have to say on the matter. |
| Comment by John Smith [ 07/Mar/13 ] |
|
Sticking with the current release is not an option for SMP players. "We are under as much obligation to release something as you are to accept the release" Great! Then don't release. |
| Comment by [Mojang] Nathan Adams [ 07/Mar/13 ] |
|
We are under as much obligation to release something as you are to accept the release. If it is so bad for you that you cannot play, simply don't use this version when it politely asks if you want to use the new version or stick to your current one. This issue does suck, I am not disputing that, but we haven't been able to fix it yet and it is completely out of the question to indefinitely stop releasing any new content (or important bugfixes that actually do impact the game non-visually) until we one day do fix this. |
| Comment by John Smith [ 07/Mar/13 ] |
|
Weather or not it is game breaking is a matter of opinion. Personally I find it bad enough that if this update goes ahead I will be buying a new graphics card. Can anybody recommend a good graphics card that does not suffer from this issue? Release dates are arbitrary. The only reason you will be negatively effecting 9 million players is you saw fit to promise this release soon before addressing this issue. |
| Comment by Tenebrae [ 07/Mar/13 ] |
|
I agree, though I hope there will be a way to make it more or less like it was in 1.4.7, the issue didn't bother me there because it was pretty much invisible. |
| Comment by Alex de la Cruz [ 07/Mar/13 ] |
|
Nathan is right, just because some users are experiencing a non game breaking visual glitch does not mean they have to delay the update making people have to wait for the awesome new features in it |
| Comment by [Mojang] Nathan Adams [ 07/Mar/13 ] |
|
The root issue is a few years old. It was made worse in this update, yes. We can choose to delay the update indefinitely until we fix it, negatively effecting about 9 million players, or we can push it out and release a new version when it's fixed, negatively effecting much less than 9 million people. Also, this is not AMD specific. I happen to suffer this extremely lightly in specific scenarios on my nvidia card. Sorry! |
| Comment by John Smith [ 07/Mar/13 ] |
|
Dinnerbone, this issue is not a year old. It is similar and related to a year old issue, but the majority of people suffering do NOT experience this in 1.4.7. The fact that mojang is intending to push a release that you KNOW will negatively effect thousands, if not tens of thousands of AMD users is frankly outrageous. |
| Comment by [Mojang] Nathan Adams [ 07/Mar/13 ] |
|
Just because we haven't fixed something, doesn't mean:
As I said just a few comments ago, we have tried a few things to fix this and even released one as a test build in this very comment thread to see if it helped. We haven't been able to fix this few-year-old issue yet but we are always looking for ways to help it. |
| Comment by Moff Kalast [ 07/Mar/13 ] |
|
It might be fixed in 1.5. official update, but its not likely since they aren't working on fixing this. They probably all have Nvidia graphic cards and don't even care |
| Comment by Maarten Thijs [ 07/Mar/13 ] |
|
so it look like we will just have to wait untill hopefully 1.5.1 brings the fix |
| Comment by Callum Tennant [ 07/Mar/13 ] |
|
So it's not fixed in the Pre Release :|. |
| Comment by Clinton Savage [ 07/Mar/13 ] |
|
I don't know if it has been stated or not, but at least from my experience, the 'lines' are running East and West, but not North and South. Sounds like some copy-pasta work could possibly fix it. Edit: Never mind they do run North and South, the severity is just quite noticeably less for me. |
| Comment by [Mod] Pokechu22 [ 07/Mar/13 ] |
|
I included that map because the lines occurred for me there. |
| Comment by Alex de la Cruz [ 06/Mar/13 ] |
|
William, the lines are not part of the map. They deppend on the gfx card |
| Comment by [Mod] Pokechu22 [ 06/Mar/13 ] |
|
I have attached a world where there is a BIG line across the screen, it should appear. In case it doesn't, I also have a screenshot. (Please don't steal the device I included there, it is one I will make a video on sometime. It is really cool, and you can look at it if you want. ) |
| Comment by George Gates [ 06/Mar/13 ] |
|
Jonathan, they have not. Don't jump the gun. |
| Comment by Alex de la Cruz [ 06/Mar/13 ] |
|
give them a break guys! Im sure they are working really hard to fix this, so even if its not fixed in 1.5, im sure it wont take long for them to fix it. |
| Comment by Steve Dawson [ 06/Mar/13 ] |
|
All I know is that if 1.5 ships with this bug, I'll probably be done with Minecraft. |
| Comment by Robert Tulley [ 06/Mar/13 ] |
|
When I turn Advanced OpenGL to on, it reduces this, however, they still appear, just not as much. |
| Comment by jonathan2520 [ 06/Mar/13 ] |
|
George, do you realize they want to release 1.5 soon? Quite likely with this bug. Then it won't be just a dodgy snapshot, but a dodgy release. |
| Comment by George Gates [ 06/Mar/13 ] |
|
So in other words you're going to stop using snapshots? Because the point of snapshots is to be able to help test new features and find bugs to fix, which is why they're optional, and in fact you need to install them manually or with a third-party tool. |
| Comment by Moff Kalast [ 06/Mar/13 ] |
|
I never had this problem before the 13w10b snapshot and I'm on ATI radeon HD 4650. They messed up the game engine pretty badly lately. I am going to stay at 1.4.7. until Mojang stops adding useless stuff and destroying the game with bugs that accur when adding the useless stuff. |
| Comment by Dave Acker [ 06/Mar/13 ] |
|
I highly doubt that will be fixed because it seems to only affect players with AMD graphics cards. |
| Comment by Alex de la Cruz [ 06/Mar/13 ] |
|
the slanted line is infact from the torch |
| Comment by Rickard Åberg [ 06/Mar/13 ] |
|
True, my attempts to get you to see this bug before 1.5 was released was more recent tho', last week and today.
|
| Comment by [Mojang] Nathan Adams [ 06/Mar/13 ] |
|
Except for the response(s) above in the comments where we attempted to fix the bug and failed. |
| Comment by Rickard Åberg [ 06/Mar/13 ] |
|
Not fixed in snapshot 13w10b. |
| Comment by Joseph Fowler [ 06/Mar/13 ] |
|
I am becoming very concerned that this will not be fixed for 1.5. Like others here, I do not have this issue at all in 1.4.x. The static images do not do justice to how bad/annoying this issue is. Am I going to have to buy a nVidia graphics card when 1.5 ships? |
| Comment by Fjodor Dostojewski [ 05/Mar/13 ] |
|
I have this bug on a 32-bit Windows environment. Voted. It feels like there are gaps between textures of nearby blocks. If I come closer I can see through the texture to the scenery behind. See gap.jpg above. |
| Comment by domi1819 [ 05/Mar/13 ] |
|
voted. i'm having an amd graphics card and it's really annoying. these lines appear where two textures meet like here: _| i'm not a rendering expert, but it could be a z-fighting bug. i don't want to criticize mojang or dinnerbone - they are doing a great job - , but they shouldn't release minecraft 1.5 before they got this bug back to 1.4.7 severeness (or completely get rid of it) btw: anyone having this bug with 32-bit java on a 32-bit computer? |
| Comment by jonathan2520 [ 05/Mar/13 ] |
|
Mac OS X doesn't override anything in the first place. There was once this ATI Displays thing that would have to be downloaded and consciously activated, which is as bad as it gets. And once again, while AA and AF cause lines to appear, that's separate from the bug. |
| Comment by CharlesC [ 05/Mar/13 ] |
|
I confirm taht as my PC on Windows is quite old, no AA is activated and the lighting is in the most basic settings. |
| Comment by George Gates [ 05/Mar/13 ] |
|
It's due to the texture changes. AA will cause this problem on older versions, but recent versions cause it with no AA, so disabling the setting does not get rid of it on the snapshots. |
| Comment by Michael Eric Brown [ 05/Mar/13 ] |
|
Same as Nicolas Saulo above. No stitching in Minecraft 1.4.7, but there is in recent and current 1.5 snapshots. Related to lighting engine improvements? Or the new method for how texture packs are assembled? (Sadly, I could not fix the issue changing any graphical settings, including Smooth Lighting.) Problem is most noticeable around dark textured blocks, like Nether Brick, and Redstone Torches, especially when the latter is placed on the former. Happens in both fullscreen and windowed mode. I use a late 2009 iMac 27" with ATI Radeon HD 4850 512 MB card, running Mac OS X Mountain Lion (10.8). I have updated to the latest Java (64-bit) as provided by Apple through Software Update (effective March 04). Some have suggested that turning off anti-aliasing seems to alleviate the issue on Windows PCs, but my research has turned up no way to override that function on Mac OS X. -Tested with pre-release Sphax PureBDCraft texture pack for Minecraft 1.5. Problem still persists, though less noticeable than with vanilla textures. Also, I see the stitching on torches in my hand, especially when I swing it with the attack button. -[Other Updates] Modified my post to reflect correct OS and that I'm using 64-bit Java, and that the problem affects dark textured blocks, not just Nether Brick. |
| Comment by Zachary C. [ 05/Mar/13 ] |
|
@ Anon Ymus |
| Comment by Nicolas [ 04/Mar/13 ] |
|
This bug has appeared with the 1.5 snapshots, on 13w10a too. [EDIT : I'm on Mountain Lion] |
| Comment by Rickard Åberg [ 04/Mar/13 ] |
|
Maybe they're looking into it, I have files called debug.stitched_terrain.png and debug.stitched_items.png in my minecraft folder now. But it could be debug files for something entirely different too. |
| Comment by Maarten Thijs [ 04/Mar/13 ] |
|
this is fixed for me, but only for the sandstone blocks, all types and sandstone slabs and stairs, but man, stone and obsidian still look very ugly. so still in current snapshot! 13w10a |
| Comment by Anon Ymus [ 03/Mar/13 ] |
|
What version of Minecraft are you running? |
| Comment by Zachary C. [ 03/Mar/13 ] |
|
This doesn't happen to me. |
| Comment by FireHunterX [ 01/Mar/13 ] |
|
I get these random little rectangles in full screen. They usually appear in the inventory bar or the sky, and sometimes in the dark. |
| Comment by Sebastiano Carreiro [ 01/Mar/13 ] |
|
Same happens to me my card is amazing but it still happens. The worst is an enchanted object in an item frame on fancy, theirs white dots and lines EVERYWHERE! |
| Comment by Ville Selkämaa [ 01/Mar/13 ] |
|
Still not fixed in the 13w09c |
| Comment by Joseph Fowler [ 01/Mar/13 ] |
|
This still occurs for me in minecraft 13w09a. 1.4.7 is fine. Checked my videocard settings as suggested. |
| Comment by CharlesC [ 27/Feb/13 ] |
|
I have a ATI Mobility Radeon HD3650 (Windows Vista SP2) |
| Comment by Stefan Barry Matthews [ 27/Feb/13 ] |
|
Just to add a few notes that I don't think have been covered; I've noticed I've had a very minor form of this in the past, but it was easily ignorable. The problem has been exacerbated by the new texture system. If you look really closely sometimes, the line on the side of one block can match the start of the block it's next to in the stitches file. It's exceedingly difficult to spot this, especially in still pictures, but I'm certain I recall once the colours of the 'white lines' on one side of the black wool blocks including some yellow and red, matching with powered rails. In the stitches file, powered rails were right next to black wool, so the 'white lines' I think are the next block along bleeding into it. Hopefully that might help in some way, I don't recall seeing that mentioned above. Going back to 1.4.7, teh issue is still there, but hardly noticeable at all, just the odd white pixel here or there, often on player and mob models. However, on blocks that can be reoriented like sideways wood logs, the issue is just as bad as in the snapshots, likely due to being rendered in a similar fashion. Running OSX Snow Leopard, ATI Radeon HD 4670. To my knowledge, OSX has no option to mess with the anti-alialising or anisotropic setting of the GPU. |
| Comment by George Gates [ 27/Feb/13 ] |
|
The visual issue can be caused by AA/AF settings in the video card driver on any recent Minecraft version (at least 1.0 onwards). If you have AA/AF settings in your video card driver on anything but "nothing" when it relates to Java, then the issue will show up, snapshot or not, for Radeon cards. The bug being discussed here, however, is that the issue happens for a lot more people, regardless of their video driver settings, in the snapshots. |
| Comment by CharlesC [ 26/Feb/13 ] |
|
I have this bug too. |
| Comment by Alex de la Cruz [ 26/Feb/13 ] |
|
What I meant was that, for me, even if I go back to 1.4, the bug is still as bad as with the snapshots. Unlike other people who say that going back to 1.4 makes the problem "go away" |
| Comment by MtH [ 26/Feb/13 ] |
|
That's because the bug was always in the game. Though with the new texture pack format the problem is a LOT more severe. |
| Comment by Alex de la Cruz [ 26/Feb/13 ] |
|
I started seeing this bug in the new snapshots, however, if I now go back to the 1.4 jars, the bug is still visible. So it is not just a problem with the new texture pack format |
| Comment by George Gates [ 26/Feb/13 ] |
|
Steven, that's because relatively early in the snapshots, the texture pack format (and the way minecraft uses them) changed which caused this issue. A lot of the fixes given here are from people who don't know this and aren't using a Radeon card on the snapshots. There's likely to be no home-brewed fix (outside of modifying the .jar), this is considered a minecraft bug and needs to be fixed in the game. |
| Comment by Steven M [ 26/Feb/13 ] |
|
I have been suffering from this bug ever since I started playing with the snapshots related to Minecraft 1.5. If I use the current 1.4 version, the glitch goes away. I'm using a Radeon HD 4650 and tried many solutions presented in this thread. |
| Comment by Tenebrae [ 23/Feb/13 ] |
|
Can finally confirm this: Tried it on a Sapphire HD6870, all settings (an-isotropic filtering, anti-aliasing) set on application settings. I can see little white dots flickering right on the edges of blocks, especially easy to spot on darker blocks like pine wood, black wool, obsi, etc. This is on snapshot 13w07a. |
| Comment by MtH [ 23/Feb/13 ] |
|
Here you can clearly see the lines, especially on the black wool. |
| Comment by Bryce Browning [ 20/Feb/13 ] |
|
There are green lines on the wither as well! |
| Comment by Jesper the End [ 19/Feb/13 ] |
|
I don't have graphic card settings... I'm on a mac. Stupid macs |
| Comment by Rickard Åberg [ 19/Feb/13 ] |
|
It's like Jonathan said. |
| Comment by jonathan2520 [ 19/Feb/13 ] |
|
@Rafael: Those settings can certainly create a problem like this, or make an existing problem worse. Here is definitely an existing problem. It was relatively mild up to 1.4, to the point that many people haven't recognized it. In recent snapshots it or something like it has become much more severe, all still without any AA or AF. Similar symptoms, but critically a different cause. This report is about the bug that manifests itself without any 'help' from AA or AF. |
| Comment by Bart Sm. [ 19/Feb/13 ] |
|
@Rafael Caetano Holy shit! The lines are 95% smaller now. Thanks, this works on my Nvidia 520M |
| Comment by Donald Granger [ 19/Feb/13 ] |
|
@Rafael: |
| Comment by Alex de la Cruz [ 19/Feb/13 ] |
|
Can someone confirm or disprove this please? |
| Comment by Rafael Caetano [ 19/Feb/13 ] |
|
Sorry if someone posted a fix for this already, but here it is. This bug appears mostly if you have an AMD graphics card (never seen this on nVidia graphics card). Here is the solution:
Sorry not being able to give accurate indications. I'm not using an AMD card. This is what I remember from an old one. |
| Comment by Donald Granger [ 19/Feb/13 ] |
|
I can confirm it as well in 13w07a, using an AMD HD 5770 graphics card. From what I've seen of the comments, it affects AMD users the most. |
| Comment by Callum Evans [ 18/Feb/13 ] |
|
I can confirm in 13w07a. |
| Comment by Ano Nym [ 14/Feb/13 ] |
|
Very severe case. Especially in dark places. (added 2 screens) |
| Comment by Ville Selkämaa [ 14/Feb/13 ] |
|
Confirmed in 13w07a |
| Comment by 123456789 [ 13/Feb/13 ] |
|
|
| Comment by Maarten Thijs [ 11/Feb/13 ] |
|
don't wory, just keep voting, I'm shure they will fix this before the release of 1.5 |
| Comment by Dave Acker [ 08/Feb/13 ] |
|
Can also confirm for 13w06a, hopefully this will be fixed as its very annoying. |
| Comment by Jesper the End [ 07/Feb/13 ] |
|
Confirmed for 13w06a |
| Comment by Maarten Thijs [ 07/Feb/13 ] |
|
still in this snapshot, please update |
| Comment by Jesper the End [ 07/Feb/13 ] |
|
It didn't get worse for me normally they're just dots flickering very fast, bug on the side of a repeater it's actually a line, not just dots. Not sure if it changed since 13w15b though. |
| Comment by Anon Ymus [ 03/Feb/13 ] |
|
That is a different bug, seen here: |
| Comment by Matthew [ 03/Feb/13 ] |
|
I am also getting a grid over repeaters and comparators ill upload a screen shot of it |
| Comment by Bart Sm. [ 02/Feb/13 ] |
|
I'm getting really big ones. I posted a screenshot of it |
| Comment by Daniel [ 01/Feb/13 ] |
|
@Newton TELL US WHAT WILL BE IMPLEMENTED!!! |
| Comment by Maarten Thijs [ 01/Feb/13 ] |
|
@Daniel. he's from the future! great, now we know it will be there for over a year! |
| Comment by Daniel [ 01/Feb/13 ] |
|
14w04a? wtf? |
| Comment by jonathan2520 [ 01/Feb/13 ] |
|
Yup, Sir TLUL. I also hinted at that possibility in You also really shouldn't grow geometry. If you handle it a little more carefully, perfect geometry will be perfect. |
| Comment by Sir TLUL [ 01/Feb/13 ] |
|
It's worth noting that the artefacts observed prior to the texture pack update occurred only on chunk boundaries, whereas these effects now occur on every tile. Based on the fact that it's also adding lines around the edges of transparent textures, I'd hypothesize that the textures are being affected by floating-point rounding issues on getting the texture from the map. Proposed fix: increase size of drawn textures by half a percent (imperceptible, but sufficient to remove lines). Additionally, decrease size of texture rectangle grabbed from the map by the same amount. Expected performance impact: little to none. Potential issues: Z-fighting between adjacent blocks. |
| Comment by M Newton [ 01/Feb/13 ] |
|
Confirmed for 14w04a (vanilla) and 14w05b (vanilla) with AMD Radeon HD 6520G |
| Comment by Jesper the End [ 01/Feb/13 ] |
|
confirmed for 13w05b |
| Comment by Anon Ymus [ 31/Jan/13 ] |
|
Please do not attach any more images. We have plenty! |
| Comment by Alex de la Cruz [ 31/Jan/13 ] |
|
When I was on 1.4.6 this problem was not that bad as it is with the current snapshots, however, if I go back to 1.4.6 it is still as bad as with the snapshots. It does not go back to how it was on 1.4.6 |
| Comment by Steve Dawson [ 31/Jan/13 ] |
|
No change with latest snapshot. :/ |
| Comment by Rickard Åberg [ 31/Jan/13 ] |
|
It got worse for me when they made textures using individual files in one of the snapshots... |
| Comment by Ghostgunner [ 31/Jan/13 ] |
|
I have a GeForce GTX670M and the same problem. |
| Comment by Ghostgunner [ 31/Jan/13 ] |
|
Glad I'm not the only one who has this problem. |
| Comment by George Gates [ 31/Jan/13 ] |
|
No fix, Radeon HD 5770. |
| Comment by Callum Tennant [ 29/Jan/13 ] |
|
No difference (http://i.imgur.com/dllGg0e.png) for AMD Radeon HD 6670 and ATI Mobility Radeon HD 4500/5100 series. |
| Comment by Will [ 29/Jan/13 ] |
|
I have been noticing this in almost all of the new snapshots. |
| Comment by Kumasasa [ 28/Jan/13 ] |
|
Special build makes no difference for OpenGL: AMD Radeon HD 6700 Series GL version 4.2.12002 Compatibility Profile Context 9.12.0.0, ATI Technologies Inc. |
| Comment by Alex de la Cruz [ 28/Jan/13 ] |
|
I've got a ATI Radeon HD 5970, Windows 7 64 bit, Java 7 64bit |
| Comment by Sir TLUL [ 28/Jan/13 ] |
|
Confirmed on ATI Mobility Radeon HD 4670, Linux Mint 13 (base: Ubuntu 12.10), OpenJDK 7 64bit. Did not occur prior to the texture pack update. |
| Comment by jonathan2520 [ 28/Jan/13 ] |
|
I have just tried it on two machines: one Nvidia (9600M GT), the other ATI (5870), both running Mac OS X 10.8.2. On neither machine I could notice a difference between the experimental and normal snapshots. Indeed Nvidia is much more robust, but it still has at least several bad pixels poking through each frame. |
| Comment by Probably_Not_Notch [ 28/Jan/13 ] |
|
Confirmed. Bug non existing prior to the texture pack update. ATI Radeon 4660, Windows 8, Java 7 64Bit. |
| Comment by Maarten Thijs [ 28/Jan/13 ] |
|
no, sorry dinnerbone |
| Comment by Alex de la Cruz [ 28/Jan/13 ] |
|
I even noticed this bug in Xisumavoid's latest video |
| Comment by Chloe Idun Anderson [ 28/Jan/13 ] |
|
Same here, still happening for me as well. You should look at what this guys has to say on the matter: https://mojang.atlassian.net/browse/MC-7363 |
| Comment by Alex de la Cruz [ 28/Jan/13 ] |
|
Didn't seem to change anything for me: http://i.imgur.com/OWK4lIk.png |
| Comment by Steve Dawson [ 28/Jan/13 ] |
| Comment by [Mojang] Nathan Adams [ 28/Jan/13 ] |
|
Please try this not-too-very-but-still-kinda-slightly experimental build to see if it fixes things, and let me know. http://dinnerbone.com/media/uploads/2013-01/files/minecraft_potential_white_line_fix_13w04a.jar |
| Comment by Jesper the End [ 28/Jan/13 ] |
|
Weird, there seem to be people having this bug since 1.4.1 But I'm only having it since the new texturepack system. When I go back to 1.4.7 it works just fine. |
| Comment by Kate Richards [ 27/Jan/13 ] |
|
White lines between wool blocks. |
| Comment by Alex de la Cruz [ 27/Jan/13 ] |
|
This has been getting much worse in the 2013 snapshots. I don't remember it being this bad in 1.4.6 Samples from 13w04a: |
| Comment by Emanuel Lorbes [ 25/Jan/13 ] |
|
happens to me too. I don't have trouble in the other updates but 3a and 4a gives me this. |
| Comment by jonathan2520 [ 25/Jan/13 ] |
|
This screenshot (1.4.7.png) shows how bad it gets in 1.4.7, using the same test case that the snapshots: a "2;7,62x0,49;2" superflat world, viewing the obsidian from below. It's hard to light up more than the occasional pixel for a screenshot, although in motion they pop up all the time. Another screenshot (1.4.something more severe.png) shows a pre-snapshot version - probably 1.4.5 - being more pathological. It wasn't just a single-frame fluke either. Edit: confirmed it's the same in 1.4.7 (1.4.7 more severe.png). I don't use any filtering hacks. No FSAA, and Minecraft can just use its "nearest" texture filter. So, yes, older versions were affected. In fact, the issue has existed for a long time. It just wasn't nearly as bad as it is now. I should add that the problem can be more or less severe depending on the GPU. But if you use robust geometry, these cracks will never appear. And if you don't, you'll always be susceptible. |
| Comment by Anton Goretsky [ 24/Jan/13 ] |
|
This does not happen in any versions prior the snapshots. This does not affect any official releases of Minecraft. |
| Comment by Joss Eden [ 24/Jan/13 ] |
|
Still in 13w04a. Getting worried that this may not be fixed or at least looked at/commented on and once it is released into an official version, a lot of people with ATI/AMD are going to wonder what is going on and get confused. |
| Comment by Steve Dawson [ 24/Jan/13 ] |
|
Happens in 13w04a for me. I know I'm going to be mad if they make a release with this bug. |
| Comment by Maarten Thijs [ 24/Jan/13 ] |
|
still in 13w04a |
| Comment by Maarten Thijs [ 24/Jan/13 ] |
|
it didn't happen to me in 1.4.5 but it does happen in the snapshots for me |
| Comment by Will Jones [ 23/Jan/13 ] |
|
At least im not the only one with this bug... I just bought this PC "for" minecraft only... and now about 3 months later.... I really hope this gets resolved somehow no way im getting another card and spending even more money to play this... i love minecraft but seriously.... now i get hella FPS and terrible glitches... /sarcasm. we need to vote this up people!!! |
| Comment by Dusty Shouri [ 23/Jan/13 ] |
|
I already know graphics settings can cause such a thing. Specifically in the past enabling forced Anti-aliasing in your graphics settings could cause this sort of effect. However I have already double-checked and made sure all my graphics card settings were on "application decides." This does not occur in the last official update(1.4.7). ATI Radeon HD 4600 |
| Comment by Chloe Idun Anderson [ 23/Jan/13 ] |
|
This issue isn't impossible to produce on other graphics cards, but it happens by default on AMD/ATI cards. It's so old that I can remember it being talked about in at least August of 2011. Basically, all that tended to happen before was a few stray pixels, but now, due to some difference in the way ATI does things, the issue is really bad. The guy above me seems to know what he's talking about, click his link. |
| Comment by jonathan2520 [ 23/Jan/13 ] |
|
The issue did exist before, but it wasn't quite as severe. If you ever saw bright pixels in dark caves, along section boundaries, that is it. Probably because each section has its own coordinate system, and is transformed inexactly. Ever since one of the 1.5 snapshots something like it started to appear at every single edge, sometimes even across a face. I believe texturing is at least partially responsible, because the stray pixels often seem to come from an adjacent image in the texture atlas. My duplicate (I did search using a few technical terms, but apparently not what everyone else had used to describe it), |
| Comment by Norrius [ 23/Jan/13 ] |
|
I have never been experienced this before, but i always get this apperance since first 1.5 snapshot. So I guess it's not only hardware/driver issue, it also must be related to changes in render engine. |
| Comment by Will Jones [ 23/Jan/13 ] |
|
I been playing with my settings as well and its 100% worse if i turn my filtering off, not being a a#s but this cannot be a card problem NEVER, let me repeat NEVER had this issue before been playing since 1.8, and really sucks TBH this really sucks..... looks like ill be on 1.4.7 forever!!!! Since this "bug" has supposedly been around forever... |
| Comment by Kumasasa [ 22/Jan/13 ] |
|
Sure, but most of the reporters here have the lines with filtering off since 13w02a. |
| Comment by Poopfish [ 22/Jan/13 ] |
|
Pretty sure anisotropic filtering can cause those lines to be more pronounced. |
| Comment by Kumasasa [ 21/Jan/13 ] |
|
Thanks. |
| Comment by Ville Selkämaa [ 21/Jan/13 ] |
|
@Kumasasa Nevermind.It didn't actually help at all.I was looking at the blocks in specific angle so the white "lines" didnt't show up. |
| Comment by Kumasasa [ 19/Jan/13 ] |
|
@Ville, what helped you a bit ? |
| Comment by Ville Selkämaa [ 19/Jan/13 ] |
|
Hmm...Weird.It helped for me a little bit |
| Comment by Kumasasa [ 18/Jan/13 ] |
|
Just upgraded from AMD Catalyst 12.10 OpenGL: AMD Radeon HD 6700 Series GL version 4.2.11931 Compatibility Profile Context, ATI Technologies Inc. to AMD Catalyst 13.1 OpenGL: AMD Radeon HD 6700 Series GL version 4.2.12002 Compatibility Profile Context 9.12.0.0, ATI Technologies Inc. and do now have white lines between blocks of black wool (Didn't check if white lines before upgrade) |
| Comment by Rolf Campbell [ 18/Jan/13 ] |
|
I've tried every driver setting I can imagine, and can certainly make it WORSE, but I can't make it any better. Turning an anti-aliasing makes it MUCH worse. |
| Comment by Ville Selkämaa [ 18/Jan/13 ] |
|
Updated my drivers to the newest version(13.1)(Amd) |
| Comment by Rolf Campbell [ 18/Jan/13 ] |
|
I just tried out my wife's laptop: it's running an Intel embedded chipset and it did not exhibit the problem. This might be only a problem with ATI video cards. |
| Comment by Brian [ 18/Jan/13 ] |
|
Just noticed it with lava showing through lines inbetween Obsidian. It has to be realated to the new texture pack setup. Also, someone should remove the Creative only tag, as it appears in survival as well. |
| Comment by Callum Tennant [ 17/Jan/13 ] |
|
I'm getting this problem too. Using Windows 8, 16gb RAM, Java 7, AMD FX-4100 quad core 4.0ghz, ATI HD Radeon 6700 2gb graphics card. |
| Comment by Rolf Campbell [ 17/Jan/13 ] |
|
I'm running Java7 (32-bit) with an AMD Radeon HD 6450. Is this only a problem with ATI/AMD video cards? Has anyone observed this on an nVidia or other brand? |
| Comment by Steve Dawson [ 17/Jan/13 ] |
|
I, too, am running Java 7 64-bit and an ATI Radeon 4890 with 12.6 drivers. |
| Comment by Eric N [ 17/Jan/13 ] |
|
This bug is much more noticeable with the new texture pack change in the last two snapshots (13w02a+b, and 13w03a). I used to only notice it with horizontal logs, but since the change it's all block. I'm using java 7 64-bit and an ATI Radeon 4800HD with the latest drivers version 12.6. |
| Comment by Ville Selkämaa [ 17/Jan/13 ] |
|
This is alot worse in 13w02b.My textures are just being very weird.But if I use the 1.4.7 the problem is not so big |
| Comment by Rolf Campbell [ 16/Jan/13 ] |
|
Ok, I found http://www.minecraftwiki.net/wiki/Tutorials/Update_LWJGL I followed their instructions and was able to update LWJGL to 2.8.5, but that had no effect on this issue. I still see stitching errors on polygon edges. |
| Comment by Rolf Campbell [ 16/Jan/13 ] |
|
What is LWJGL? ... searching ... oh: LightWeight Java Game Library. How do I update it? I never installed this before. Is this shipped with Java or shipped as part of Minecraft? |
| Comment by Rolf Campbell [ 16/Jan/13 ] |
|
Here's a much better example. The lava is very visible between the edges of the Nether brick blocks. |
| Comment by Anon Ymus [ 16/Jan/13 ] |
|
Try updating your LWJGL to 2.8.4. That fixed a bunch of graphics problems for me. |
| Comment by Rolf Campbell [ 16/Jan/13 ] |
|
It's not just white stitching, here's an example of black (or at least dark) stitching. I used to experience this occasionally in previous versions, but now it happens to me constantly. I do not have AA enabled, and I'm running a recent video driver. |
| Comment by Niriel [ 15/Jan/13 ] |
|
I have the problem in Fast and Fancy. |
| Comment by TheCoryKid [ 14/Jan/13 ] |
|
I may be wrong, but I think this problem only occurs when Fast graphics is selected. Minecraft is an insane resource-hog so my computer can't play with Fancy graphics, but when I do use Fancy, I don't have this bug. |
| Comment by Niriel [ 14/Jan/13 ] |
|
I have the problem too, AA is turned off. It used to be extremely rare, but now all the blocks are affected all the time. I haven't touched my graphic cards drivers, just updated to a recent version of Minecraft; if I rollback to 1.4.5, the glitch goes away. |
| Comment by Pete Frisky [ 14/Jan/13 ] |
|
This graphic glitch is just more common and noticeable with the new texture pack stitching but still exists prior to the 13w02b snapshot for me too. |
| Comment by Joss Eden [ 14/Jan/13 ] |
|
I believe it is due to the new texture system, I too have this bug but it only happens in the latest snapshot, 13w02b. It will not occur on 1.4.7 or 13w01a/b. |
| Comment by Steve Dawson [ 12/Jan/13 ] |
|
I'm wondering that too, since I just started getting the problem when the new texture system was introduced. |
| Comment by Kumasasa [ 12/Jan/13 ] |
|
Is |
| Comment by [Mod] CubeTheThird [ 12/Jan/13 ] |
|
That would be because (based on my personal experience) this has actually worked. Unfortunately this does not fix the problem for everyone. |
| Comment by Steve Dawson [ 12/Jan/13 ] |
|
Turned off AA. Still persists. I hate how people tell me to do that when it doesn't fix anything. |
| Comment by Callum Tennant [ 11/Jan/13 ] |
|
I can confirm this issue. |
| Comment by Daniel [ 10/Jan/13 ] |
|
Confirmed bug. Note that on all PCs that doesn't happens. |
| Comment by Ville Selkämaa [ 20/Dec/12 ] |
|
Okay I installed Ati Tray Tools to turn off the antialiasing and anisotropic filtering but the problem still exists... |
| Comment by default [ 25/Nov/12 ] |
|
I've seen this occasionally when underground, since version 1.2.1. Not enough to be annoying - there's much worse bugs that are currently spoiling the gameplay for me. |
| Comment by Tom Mate [ 21/Nov/12 ] |
|
confirm. a bit annoying but there are worse bugs |
| Comment by Treydun [ 18/Nov/12 ] |
|
I had this problem when I attempted to change my Nvidia card to use anti-aliasing as well. Application controlled was the only setting I could use where this didnt happen. |
| Comment by MisterSanderson [ 14/Nov/12 ] |
|
Jacob, my Anti-Aliasing is off, but the problem exist. |
| Comment by Jacob Navel [ 13/Nov/12 ] |
|
just turn off Anti-Aliasing. have fun guys! |
| Comment by MisterSanderson [ 13/Nov/12 ] |
|
I saw this problem in my game today. |
| Comment by [Mod] CubeTheThird [ 04/Nov/12 ] |
|
I used to have this issue, and to fix it, I reset several of my graphics settings to defaults, or "use application settings" options. I've found that anti-aliasing and anisotropic filtering have had influence on this. |
| Comment by Sergio Carlos Roman Lopez Jr [ 04/Nov/12 ] |
|
Does anyone know how to fix this problem. I tried changing graphics settings and not happened its still the same. |
| Comment by Ville Selkämaa [ 03/Nov/12 ] |
|
I have this problem too.I have tried changing my GPU settings but no luck so far...I am using Amd HD6850 |
| Comment by [Mod] CubeTheThird [ 02/Nov/12 ] |
|
This is strictly a graphics card/driver issue. Try changing your graphics settings to correct this. This can also be influenced by optifine, should you have it installed |