White stitching on polygon edges / White lines or black dots between blocks

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

I have this problem too.I have tried changing my GPU settings but no luck so far...I am using Amd HD6850

Does anyone know how to fix this problem. I tried changing graphics settings and not happened its still the same.

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.

I saw this problem in my game today.

just turn off Anti-Aliasing. have fun guys!

Jacob, my Anti-Aliasing is off, but the problem exist.

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.

confirm. a bit annoying but there are worse bugs 🙂

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.

Okay I installed Ati Tray Tools to turn off the antialiasing and anisotropic filtering but the problem still exists...

Confirmed bug. Note that on all PCs that doesn't happens.

I can confirm this issue.

Turned off AA. Still persists. I hate how people tell me to do that when it doesn't fix anything.

That would be because (based on my personal experience) this has actually worked. Unfortunately this does not fix the problem for everyone.

Is MC-7320 really a duplicate of this ticket or is it caused by the new texture system ?

I'm wondering that too, since I just started getting the problem when the new texture system was introduced.

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.

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.

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.

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.

I have the problem in Fast and Fancy.

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.

Try updating your LWJGL to 2.8.4. That fixed a bunch of graphics problems for me.

Here's a much better example. The lava is very visible between the edges of the Nether brick blocks.

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?

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.

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

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.

I, too, am running Java 7 64-bit and an ATI Radeon 4890 with 12.6 drivers.

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?

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.

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.

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.

Updated my drivers to the newest version(13.1)(Amd)
Bug still occurs but maybe not so badly.They have added some extra options.Guys go mess with the settings.Maybe it will help you a little bit

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.

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)
Same results as Rolf Campbell, playing around with the settings doesn't help.

Hmm...Weird.It helped for me a little bit

@Ville, what helped you a bit ?

@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.

Thanks.

Pretty sure anisotropic filtering can cause those lines to be more pronounced.
Having any kind of outside anisotropic filtering "on" will cause them.
Although at such a close distance from the player it is unlikely that that is the problem.

Sure, but most of the reporters here have the lines with filtering off since 13w02a.

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...

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.
I run Minecraft on Ubuntu Linux with ATI Radeon HD 4550.

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), MC-7363, contains some technical info that may be helpful.

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.

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

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!!!

it didn't happen to me in 1.4.5 but it does happen in the snapshots for me

still in 13w04a

Happens in 13w04a for me. I know I'm going to be mad if they make a release with this bug.

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.

This does not happen in any versions prior the snapshots. This does not affect any official releases of Minecraft.

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.

happens to me too. I don't have trouble in the other updates but 3a and 4a gives me this.

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:
http://i.imgur.com/NIyWBBc.png
http://i.imgur.com/toZJ58H.png
http://i.imgur.com/IHfos92.png

White lines between wool blocks.

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.

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

Nope. http://i.imgur.com/cJ6EP93.png

Didn't seem to change anything for me: http://i.imgur.com/OWK4lIk.png

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

I even noticed this bug in Xisumavoid's latest video

no, sorry dinnerbone 😞 still there, if you need crash reports, extra snooper data a complete empty world with just 2 block with with white stiches on them, just say it and we will get you one.

Confirmed. Bug non existing prior to the texture pack update. ATI Radeon 4660, Windows 8, Java 7 64Bit.

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.

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.

I've got a ATI Radeon HD 5970, Windows 7 64 bit, Java 7 64bit

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.

I have been noticing this in almost all of the new snapshots.

No difference (http://i.imgur.com/dllGg0e.png) for AMD Radeon HD 6670 and ATI Mobility Radeon HD 4500/5100 series.

No fix, Radeon HD 5770.

Glad I'm not the only one who has this problem.

I have a GeForce GTX670M and the same problem.

It got worse for me when they made textures using individual files in one of the snapshots...
Before that I only had minor issues, verified by going back from snapshot 13w05a to 1.4.7.

No change with latest snapshot. :/

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

Please do not attach any more images. We have plenty!

confirmed for 13w05b

Confirmed for 14w04a (vanilla) and 14w05b (vanilla) with AMD Radeon HD 6520G

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.

Yup, Sir TLUL. I also hinted at that possibility in MC-7363. I know at least previous versions used a slightly smaller region from the texture. I should note that neither of these things explains the whole story, though. Say, if you place a torch on a block, the face it's standing on will have cracks in it, and so will the air around the torch! I have no clue what it's smoking there, but it isn't your standard geometry or texture issue.

You also really shouldn't grow geometry. If you handle it a little more carefully, perfect geometry will be perfect.

14w04a? wtf?

@Daniel. he's from the future! great, now we know it will be there for over a year!

@Newton TELL US WHAT WILL BE IMPLEMENTED!!!

I'm getting really big ones. I posted a screenshot of it

I am also getting a grid over repeaters and comparators ill upload a screen shot of it

That is a different bug, seen here: MC-5178.

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.

still in this snapshot, please update

Confirmed for 13w06a

Can also confirm for 13w06a, hopefully this will be fixed as its very annoying.

don't wory, just keep voting, I'm shure they will fix this before the release of 1.5

Problem:

Denn immer wenn ich z.B. meine Felder abernte, landen die Items, die dann auf dem Boden liegen in meinem Fuß-Slot für die Rüstungen der Schuhe! Und angenommen, da liegen dann 20 Items auf dem Boden, hebe ich eines auf in den Fuß-Slot, alle anderen werden aufgehoben, verschwinden dann aber komplett. 😞
(Edit: Wrong language, wrong ticket)

Confirmed in 13w07a

Very severe case. Especially in dark places. (added 2 screens)

I can confirm in 13w07a.

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.

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:

• Go to the graphics card control panel (Catalyst Control Center ?)

• In the Graphics Settings, expand "3D"

• Select "Standard Settings"

• Make sure the "Use custom settings" is unchecked

• See if any other option is controlling the game (like Anti-Aliasing or Anisotropic Filtering) and if so, make it so that anything is controlled by the graphics card.

• Save all changes and you should be ready to go.

Sorry not being able to give accurate indications. I'm not using an AMD card. This is what I remember from an old one.

Can someone confirm or disprove this please?

@Rafael:
This is incorrect as of the snapshot versions. My AMD card has all settings (which is in fact the defaults) set to "Use Application Settings". I've never forced anti-aliasing or anisotropic filtering on any game, because the results usually look terrible.

@Rafael Caetano

Holy shit! The lines are 95% smaller now. Thanks, this works on my Nvidia 520M

@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.

It's like Jonathan said.
Like I mentioned earlier, I think it became more severe when they changed the way textures were handled, I can also verify the problem exists on 13w07a.

I don't have graphic card settings... I'm on a mac. Stupid macs 😞

There are green lines on the wither as well!

Here you can clearly see the lines, especially on the black wool.

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.

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.

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.

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

That's because the bug was always in the game. Though with the new texture pack format the problem is a LOT more severe.

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"

I have this bug too.

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.

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.

I have a ATI Mobility Radeon HD3650 (Windows Vista SP2)
To see it easily : use a bow, charge it and you'll see those dots around the parts of the bow. Other way is to look at the ground on a flat map with rising sun (light passes through those holes)

This still occurs for me in minecraft 13w09a. 1.4.7 is fine. Checked my videocard settings as suggested.

Still not fixed in the 13w09c

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!

I get these random little rectangles in full screen. They usually appear in the inventory bar or the sky, and sometimes in the dark.

This doesn't happen to me.

What version of Minecraft are you running?

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

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.

This bug has appeared with the 1.5 snapshots, on 13w10a too.
All blocs are impacted (even torches, hoppers, etc.)
I haven't had such a problem on 1.4.6 or on any previous version.
I'm running Minecraft on a mid-2011 15" MacBook Pro with OSX Mountain Lion ;
my GPU is an AMD Radeon HD 6750M.

[EDIT : I'm on Mountain Lion]

@ Anon Ymus
I am using 1.4.7

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.

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.

I confirm taht as my PC on Windows is quite old, no AA is activated and the lighting is in the most basic settings.

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.

voted. i'm having an amd graphics card and it's really annoying.
like being said before, this bug has been there for a long time. i didn't even notice it with 1.4. - 1.4.6. it became more severe with 1.4.7, where i noticed white pixels on items held. snapshot 13w0...3 (i believe) made it even worse, with mismatching lines everywhere.

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)
that's just my opinion

btw: anyone having this bug with 32-bit java on a 32-bit computer?

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.

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?

Not fixed in snapshot 13w10b. 😞
Tried getting mojang to fix this bug but no response yet.

Except for the response(s) above in the comments where we attempted to fix the bug and failed.

True, my attempts to get you to see this bug before 1.5 was released was more recent tho', last week and today. 🙂
While not really a gamebreaking issue it still affect the looks of the game to some degree it's slightly annoying, especially if there are dark textures involved. 😞

• I attached a screenshot called slanting.png with a comment in. Might help you detect/find the bug better.

the slanted line is infact from the torch

I highly doubt that will be fixed because it seems to only affect players with AMD graphics cards.

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.

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.

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.

When I turn Advanced OpenGL to on, it reduces this, however, they still appear, just not as much.

All I know is that if 1.5 ships with this bug, I'll probably be done with Minecraft.

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.

Jonathan, they have not. Don't jump the gun.

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. )
EDIT: it still exist on all settings, it even exists in 3D mode (making for a weird occurrence)

William, the lines are not part of the map. They deppend on the gfx card

I included that map because the lines occurred for me there.

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.

So it's not fixed in the Pre Release :|.

so it look like we will just have to wait untill hopefully 1.5.1 brings the fix 😞

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 .

Just because we haven't fixed something, doesn't mean:

• We don't care about it.

• We aren't trying to fix it.

• We won't ever fix it.

• We don't know about it.

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.

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.

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!

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

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.

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.

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.

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.

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.

Could you guys add some kind of fall-back for it though? An option to toggle to the old texturing system?

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.

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.

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.

Guys, back it off. This is a place to report bugs, not to cause drama.
Mojang is under no obligation to release any further updates, yet they do. And they do it for free.

If you don't like, fine, but don't vent it on this bugtracker.

Agreed, this is not the place to complain and rant.

@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.
So stop this cyberhating on developers that ow you not even a single update but do so anyway. be positive, instead of saying: FU dinnerbone and jeb you messed everything up, you could say: good job on fixing over 60 bugs for 1.5, i'm shure everything will be fixed.

@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.

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...

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.

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.

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)

@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.

@Moff Kalast. three words: official Curse client
just tell everyone on the server they have to download that. it's free, takes up allmost no space, performace low plus you can turn it off once the game starts, they are partners of mojang+ you can shift between versions in just 2 clicks.

http://www.curse.com/client

just trying to help you guys🙂

downgrade your Minecraft version in order to play on servers using older software.

I was talking about the players...

Well, with any luck somebody out there will create a mod fixing this bug.

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!

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.

@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.

^ 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.

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?

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.

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.

Well, the lines appear to be transparent, rather than white.
Black wool with lava behind: http://prntscr.com/vmeca

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.

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 :|)

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.

Oh, I thought it was the time of day which determined what you see between the blocks.

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.

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).

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.

Ah, so that's what a line is.

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.

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.

Mojang, fix this BUG!!!!!!

I checked the forums and it seems to happen to all kinds of video cards, including nVidia, GeForce, ATI, AMD, Catalyst, etc...

@Dinnerbone,
Sorry to break your day, but this also happens on earlier versions than 1.4, before the unstitched textures.
With that I mean just the lines between blocks, not the pink water horizon caused by AA/AF, which I have turned off.

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.
I didn't have this issue until recently, when it suddenly popped up. I tried all the different AA/AF settings in the control panel, including factory settings etc...
I do not have optifine installed, but using optifine however does seem to reduce the size of the lines.

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' 😛) and thus was doing AF with "per-pixel samples 2X". Once I turned that to use app settings, the "lines" I have been talking about disappeared (the "dots" and the occasional lineish thing they produce still remain, of course). Well, at least I was right on the fact that there were more than one issue going on, at least for me.

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).

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.

In a dark place, the game almost unplayable. When movement is quickly flashed bright artifacts.

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 😛)its something i had todo for my situation.

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!!)

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.

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!

And success!
http://s9.postimage.org/gxh0hnmnh/holycrap.png
Full-size image so the differences could be clearly-shown, gotta' view at 100% to see the issues in the original.

Core 2 Quad Q8400, Radeon HD 5770.

@Dinnerbone I can confirm, can't see any white lines even in completely dark black wool room. Awesome, thank you very much!

Great job dinnerbone! You squashed this big bug!

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?

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.

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.

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 🙂

As far as I can tell, it's fixed for all blocks, but entities such as minecarts are still affected.

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

It's 100% fixed for me. only redstone torches have a few dots in the corner but man! love you dinnerbone!

Works great thanks 😃 (ATI Radeon HD 4650)

Wait... This fix ISN'T going to be in 1.5!?!

Not fixed for me. AMD Raden HD 6670.

http://prntscr.com/w1684

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 🙂

@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)

@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.

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.

@Alejandro de la Cruz: That a completely different issue: MC-11236

Fixed. AMD Radeon 6700

Fixed for me, ATI Mobility Radeon HD 4670 on 64-bit Linux.

Works here as well, AMD Radeon HD 6970. Good, good.

Much better, but it still happens. http://i.imgur.com/uJKxWRN.png

Windows 7, 64 bit, Radeon 4890

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.

@Deadlock989: No Optifine, and you're sure that your CCC install isn't applying AA/AF, right?

1.5 Has made it worse for aswell,
btw I confirm this aswell on my Mac. ATI Radeon HD 5750

@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?

@CubeTheThird I dindn't see dinnerbone's comment with the fix, sorry

the fix works fine for me - Radeon HD 4200

It seems it has been fixed for me too.
I still have a few distant dots on black wool superflat maps but this is nothing compared to the constellations I used to see.
In closed rooms it completely disappeared.

Good job 🙂

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!

1.5 official release, no mods, default TP;
Mac with ATI Radeon HD 5770, white lines and dots are still VERY obvious on a 30" display; visible at 100%

http://imgur.com/7et2jzy
http://imgur.com/Z0m6h19

You can download 13w11a if you want it fixed.

Thank you! Still present in 13w11a but only while moving. As soon as the camera comes to a halt the dots disappear.

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
you will see the white dots/lines in between the columns: http://i.imgur.com/JmvYYe0.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)

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.

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).

Reopened.

Well, for me it's much better than 1.5 but not perfect, I still see the stitching in certain places.

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.

It seems to be about as common in 13w11a as it was in 1.4.

This bug was not present in 1.4. You might have an issue with your graphics card, Tavis.

to Nathan Adams:
this bug can be fixed if to bind coordinates of all vertices to a small grid, such as 0.001 or less.

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.

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...

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).
You can download the 13w11a snapshot to test the fix here :
http://mojang.com/2013/03/minecraft-snapshot-13w11a/
Please READ all the comments above BEFORE saying anything stupid.
Thanks.

@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.

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 MC-7363. (Beware of discredited hypotheses about 1.5's textures. The part about 1.4 is still valid.) It works by altering the vertex transformation to make it exact. It's such a basic shader that there's no reason not to use it; unlike all of Minecraft (shaderless as it may be at the moment), it's a negligible load even on decade-old machines.

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.

@Alejandro
1) I did, I've been following the thread for several days.
2) 13w11a fixes "most of" the bug, as only some blocs are buggy now (flowing lava is a very special case).
I had dots everywhere before Dinnerbone's fix and now they are so scarce it is hardly noticeable, even near the horizon on black wool superflat worlds.

@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....

@Alejandro
We're mostly back to the pre-1.5 bug, which is pretty discreet...
The visual artefacts were huge in the 1.5 snapshots.
I didn't notice it in 1.4.X.
Call it a major bug if you want to, but I'll forget about it when 1.5.1 is released.

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?)

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

• haven't updated to the actual fixed version;

• force AA;

• force AF;

• or see the geometrical error along section boundaries.

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.

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).

Jonathan: In short

• The AF hasn't been part of my tests and texts after the findings of texture expansion. After that, I've kept AF off, and concentrated mostly to the dots between blocks, and haven't even cared about the dots between chunks (they are always there).

• In 1.4.7 and 1.5 I have dots going between all block edges, not just chunk borders.

• Our chats are getting long, perhaps we should continue on forums 😛

Details:

Originally, I had 3 visual problems (even though I thought I only had 2); the AF-caused lines in distance/low angles, and dots at all block edges, and dots at chunk borders; the latter two looked pretty much the same, I could not tell chunk borders from how they looked from other edges. The AF-caused lines had the solution of expanding the texture pixels at their edges (or turning AF off, of course). That texture expansion also handled the dots at block edges (completely), but not the chunk border stuff. It became difficult to find the chunk borders, the dots became so rare.

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.

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.

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.

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.

As Tenebrae said, please try with the latest snapshot: http://www.mojang.com/2013/03/minecraft-snapshot-13w11a/

As said above, the bug is still occurring on the edges of chunks (which means that it has been divided by 16).
It seems that the lava bug is a real gap (we can see through it), it seems different from the 1-pixel wide dots/lines between ordinary blocs.

I'm happy so long as the random giant lines are gone. The small dots aren't so bad.

@jonathan2520 and other developers

if the geometry is correct, you can snap texture coordinates to the grid. they are usually not very large values.
after all transformations (C example):

float f_round (float f) {
float r = f - (float)(int) f;
f -= r;
return f;
}

float fsnap (float value, float cell) {
return f_round(value / cell) * cell;
}

it will reduce the accuracy of positioning the texture and probably will remove the computing error.
if cell = 0.01 it decrease accuracy to 1%
perhaps in a display lists is not able to do graceful...

/sorry for my bad english/

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".

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.

This bug still persists in 1.5 pre-release. I guess the texture is being rendered smaller than the block is.

Fixed for me in 1.5.1, using ATI Radeon HD 4600 Series.

da's fijn merlijn

I'm just saying that there was NO point in reopening this since it says in the description:
"note that this fixes the issue for many(not all) users, especially those who have only experienced this in 1.5"

@Etan: of course this was reopened, the issue is not yet fully fixed

Still having same problem with 1.5.1
Im using 64bit java and nvidia geforce gtx 550 ti
http://goo.gl/hqIqi

@Antti Harju: Your issue is MC-5178

For me, forcing anti-aliasing on my nVidia GeForce GT 555M causes this issue; however installing Optifine and enabling anisotropic filtering eliminates it.

@Ben W: Your issue is MC-5178

For Windows nVidia Video Cards:

1. Right-click on desktop and click NVIDIA Control Panel
2. Select ‘Adjust image settings with preview’ in the left pane
3. Select the “Use the advanced 3D image settings” on the right
4. Click ‘Apply’ at the bottom right

For Windows ATI Video Cards:

1. Right-click on desktop and click Catalyst Control Center
2. Select ‘Advanced Settings’
3. Select ‘Graphics’ then ’3D’
4. For Anti-Aliasing, check “Use Application settings”
5. For Anisotropic Filtering, check “Use Application settings”
6. Click Apply or OK

It has help's my.

hope it works for you.

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

Also 2013-03-06_14.50.13.png looks like a separate issue to me, as the lines are not just at the edge.

@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.

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.

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.

Here are the dots I see.

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.

____________________________________________________________________
This problem is caused by Mipmapping, from 1 to 4 level.
Anisotropic Filtering is fixing it (even lvl2).
So, turn off Mipmapping or turn it with anisotropic filterring.
____________________________________________________________________

And I can't use that, because anisotropic filtering is bugging my shaders on snow biome, ehh. But hope it help you.

still there in 1.6 on my nvidia graphics card, but not on the intel one !?

@Manuel: Your issue is MC-5178.

you're right, thx for the info 🙂

@Manuel Since that issue is closed, your best option is to get optifine, which is not official, but may help you.

This issue also affects version 1.6.2

Are you sure you aren't seeing MC-5178?

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.

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.

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!

Oh my god, bug or not I have this problem in such bad situations.

I use AMD, does anyone else use AMD?
Maybe it's the codec in AMD and AMD needs to make a new profile just for minecraft.

I have another laptop which is pretty good amd graphics with intel core i5 and these lines don't appear!

@Brian Roach:
Read the comments. As several times explained, this is MC-5178.

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.

It seems like alot of people are affected by this at the moment,
I have this problem too, I've checked on multiple computers and versions, computers which I've tested on:

iMac (OS X) ver. 10.8
Windows 7 32bit
Windows 7 64bit

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.
I've reinstalled my entire computer due to this bug, since I thought it occured due to graphics drivers or something wrong with my hardware, but when I checked on different operative systems and 32 & 64 bits, my conclusion is that something in Minecraft is where the problem is.

Minecraft's graphical issues seems to be these at the moment, which I've noticed so far:
Stitching between blocks
Flickering blocks from a distance (with flickering I don't mean that they disappear and reappear)
Minecraft doesn't know how to render textures properly, from a distance

I've tested with optifine and not optifine, no difference.
These graphical issues are NOT caused by graphics cards / drivers, since I've tested it myself...

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.

Ok, this bug just went 200% worse in new snapshot! I tried every possible setting in video settings menu and now its really bad.

Here you can see white lines on terrain

In here there is black spots/lines in corners ect.

Also there is white lines when you look at anvil in your inventory

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.

Extreme manifestation of crazyman's problem:

1. create an AMPLIFIED world;

2. set mipmap levels to 4;

3. set anisotropic filtering to 4 or more (2 doesn't do it for me);

4. set a decent render distance;

5. fly up and look straight down at the cliffs.

Something about looking at surfaces edge-on goes awry.

Snapshot 13w38a; Mac OS X 10.8.4 (about to update!); Radeon HD 5000 series.

Mipmap levels at 4 makes this realy bad.
Setting it to 0 makes it disappear for me.
I have anthroscopic filtering off.

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.

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.

Well I am using a Nvidia card and the same thing is still happening to me.

Never mind that part in that case. The issue must be in Minecraft's rendering rather than hardware, then.

thats what I assumed, as my girlfriend plays on her acer laptop that has built in graphics, and she gets the same thing.

Can confirm in 1.7.2 with hoppers

Anyone still having this problem in 1.7.2 :/ because my stupid gtx 670 likes to make white dots in minecraft HELP!!!!

When you are in 1.7 go to "Options" -> "Video Settings" -> scroll down ans set "Mipmap Levels" to "OFF".
This does not fix the problem completly, but reduces it.

This bug is so bad, that when I look at a hill, almost every single block is affected. I'll upload a screenshot soon.
NDVIDA 640 Java 64bit newest release windows 7 Intel i5

With NVIDIA graphic cards just return your setting to factory defaults from NVIDIA control panel, that fixed it for me.

For latest snapshots (at least last 2), the white dot is back when looking at the water (like seas)
Can someone else confirm ?

Occurs on held items.

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.

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

Still in 14w08a. I don't have the anti-alias shader or anti-aliasing on my graphics card.

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.

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?

Yes, on MCPE. This tracker is for bugs in the PC version only.

Still present in 1.7.5, on the clouds.

Confirmed in 1.7.5 and 14w11b.

Can the Affects Versions tags please be updated?

Still present in 1.7.9 clouds.

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 MC-31718)

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?

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.

Confirmed on 14w18a - Java 8 Update 5, Radeon HD 6580 [13.12 WHQL], Windows 7 64bit

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.

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.

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.

Confirmed for 14w29b

@Marcono1234 , what's are your video settings?

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 ?

Very clearly seen... They fade over in long distance.

@unknown: Don't force anisotropic filtering on Minecraft.

Maybe confirmed for

• 14w31a Black stripes on snow (MC-9354 describes that but is marked as duplicating this report)

• Minecraft 1.8-pre 1 also with clouds a little bit

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.

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.

@unknown: Clouds are just the eternal MC-7882.

No, I meant there are some stripes in a cloud between each cloud segment (so it seems like a cloud consists out of segments),
Just look very close and in different angles

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

@unknown: 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.

I suspected that. but I have not been able to figure out how to execess the menu that will allow me to change that.
while I realise that you probubly cant help me with my speific computer (though if you CAN, it is VERY MUCH welcome (AMD radeon HD 8670D windows 7 (that is all I know for sure))
now that I know this, I will know exactly what to say when I can get my brother. thus simplifying his job. and making it easyer for me to pay off the favor.
thankyou jonathan2520
(I dont know how to reply to a spefic comment

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:

@unknown: Did you try to set Mipmap levels to 0? It seems to help me in 1.8

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.

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.

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.

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.

This site is only for bug reports. For technical support please use the Mojang Support Center.
Further attempts to seek support on the comments section of this issue will be removed.

Not sure if anyone said this before, but it is actually the background that lies behind blocks not just white(sky)/black(void) dots.

[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

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.

What you are describing could be MC-73186

Can you tell me if this issue persists with mipmaping turned off ?

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.

Confirmed for 15w44b.

It still happens when mipmaping is turned off but only on clouds (not inside).

Please include the description of MC-7363 or at least link to it in the description as it is very detailed

Agreed. Except for heapload of pictures, MC-1794 is basically useless. I'd use MC-7363 instead.

@unknown could you please include a link to the source as well?

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.

Confirmed for 1.9.1-pre3 with (fancy) clouds.

Still confirmed in 16w15b on MacOS. New install of MC, no mods.

@unknown : 16w15b is outdated, please update to 1.9.3-pre2

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.

Confirmed for 1.9.3-pre3.

Confirmed for 1.9.4.

Confirmed for 16w20a.

Confirmed for 16w21a.

Confirmed for 16w21b.

Confirmed for 1.10-pre1.

Confirmed for 1.10-pre2.

Confirmed for 1.10.

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.
Windows 7, 1366x768 screen, fullscreen mode

@unknown: A modernized incarnation:

3;minecraft:bedrock,62*minecraft:air,minecraft:obsidian;2

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:

3;minecraft:bedrock,minecraft:snow_layer;2

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. 😞 Shader hacks to write depth could help but that's another costly can of worms.

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.)

@unknown: I've made you the reporter of this ticket, feel free to edit the ticket's description appropriately.

Confirmed for 1.10.1.

Confirmed for 1.10.2.

@unknown I definitely had this bug in 1.10.2, but not with one of your two presets.

@unknown: 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.

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.

It is really easy to see this issue, just generate a new superflat world with whatever settings you want and look into the distance

I think this bug needs a better "environment" field. I can't reproduce it, I'll insert my hardware here in a few minutes.

Confirmed for Mac OSX on 16w42a on lava

Well, it affects 16w42a, but I think your pictures are just a problem of the block model of lava: MC-105732
And could you please attach your pictures to the report instead of putting them into your comment? They are huge.

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.

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").
There are black spots and lines on the piston arm.

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.

I can confirm this issue on a Titan X Pascal, with no mods and all settings on max, save mipmapping, which is off.

This image that @unknown 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.

This can be made more hidden by making a texture bigger.

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.

Here someone confirms this issue for the following graphics card: https://gaming.stackexchange.com/questions/345324
GTX 1060 with driver version 417.71
Please add it to the environment field.

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.

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.

This bug is evident at chunk section borders in dark areas in 1.14.3.

This issue also exists in 1.14.4. It only seems to occur at chunk section borders.

Then it's probably a different bug.

Can confirm this is occurring between chunk borders on 1.14.4.

this is happing on 19w35a. it only happens if you have mipmap on

it might be happing because the switched to OpenGL 2.0

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.

For 14.4 under video settings, set minmap levels to 0. This worked for me. 

There are a few fixes
1. Set mipmap levels to 0 (In game)
2. Set Anisotropic Filtering to above 0 (Optifine, In game, Laggy)
3. Turn Anisotropic Filtering Off (graphics card settings)
4. Turn Antialiasing Off (graphics card settings)

We already have enough pictures demonstrating the issue. Usually one picture is already enough. Please stop attaching more pictures to this ticket.

you can fix this issue in the nvidia control panel

Confirmed for 20w12a

This bug occurs in 20w22a, i've tried every fix and it doesn't seem to be working

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.

is there a fix for AMD drivers ? 

I have been dealing with this for months now it gets on my nerves 😞 i have tried putting mipmap to 0 and I don't have NVIDIA so I cant fix it through their software. turning off anti aliasing in my computer settings is not working either ! I made sure I was letting minecraft deal with itself and that my graphics card wouldn't interfere. Please help !

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?

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

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

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. 

@unknown What issue is it for you? Is it like

, in which the entire world looks ugly, or is it only a few pixels wrong in rare situations?

@unknown this problem is not on all blocks but all held items. i have tried every fix I dont think my GPU is the problem

if anyone has a fix please tell me. the mods notice on the top of the post does not help at all

@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 🙂

@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 ? 

TLDR: Because it's hard. You can try it yourself, if you want.
A bug fix would also not apply to 1.8.9, because that's an ancient version. You should really consider updating, because 1.8 has a ton more bugs, even more severe ones, that were fixed in the meantime.

@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. 

1.8 will never receive updates again, apart from 1.9 and above, which ARE the updates for it.
All of 1.8 PVP can be simulated with commands in recent versions, if you really want that.
If you want to discuss this further, please don't use the tracker for it, but instead https://www.reddit.com/r/mojira .

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

@unknown, as indicated, please take any further conversation about this report onto the mojira subreddit.

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!! 

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
I if someone has a solution to the entire game that would be helpful because it seems like it's also influenced by the textures scale or something im not a expert

Can confirm in 20w49a.

Can confirm in 20w51a.

Can confirm in 21w03a.

Can confirm in 1.4.1

Can confirm in 21w05a.

Can confirm in 21w05b.

Can confirm in 21w08b.

Can confirm in 21w14a.

I see white pixels in the corners of blocks, is this the same issue?

Can confirm in 21w15a. @unknown, yes, this seems like the same issue.

Can confirm in 21w17a.

Still present in 1.17pre2 (clouds stitches on AMD hardware (event when disabling  all  anisotropic or other mipmap/post-processing options in driver)

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.

I have done everything in the mod notice but the issue persists.

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.

Can confirm in 1.17.1 Pre-release 1.

Note that there is a second ticket that tracks issues with held item models (though there is some overlap): MC-73186

I hope this bug gets fixed sometime because I very commonly see the white lines especially in the clouds and it gets annoying.

Can confirm in 1.17.1 Release Candidate 1.

Can confirm in 1.17.1.

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

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.

Can confirm in 21w39a.

Can confirm in 21w40a.

Can confirm in 21w41a.

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.

@unknown Please do not add a comment to complain, only to add new info or affected versions.

Can confirm in 21w43a.

can confirm in 1.18-pre2

Can confirm in 22w12a.

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.

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.

Can Confirm for 1.19.3 Release Candidate 3, appears to be related to ambient occlusion

Can confirm in 1.19.3 and 23w04a

Can confirm in 23w05a

Can confirm in 23w06a

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.

Affects 1.20.

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.