[MC-88330] Textures and Effects are off when far away from the center of the map

Introduction

Most of this behavior can be reproduced near the world border: /tp 29999950 29999950
Some of the strange rendering can also be seen closer to the center of the world but not in such an extreme way.

Reason for this bug

The 32-bit float simply run out of resolution/accuracy with the large coordinates. The solution is a bit of "ugly", but it got the work done, as I'm looking at perfectly fine wires at coordinates near X&Y of 17,000,000.
There are more unnecessary (and sort of harmful) (float)-casts in that same method, but they are for Y-coordinates, and since Y-coordinates are, for the time being, very limited, they do not show similar problems. (That whole class seems to be littered with those float-casts, many of which seem to be unnecessary and possibly causing similar issues for other blocks/visuals.)
comment by @unknown on MC-3718

Other bugs caused by this

Fix for fire's smoke
This time no source code as the changes cover almost the whole method. But its the very same fix, in BlockFire.randomDisplayTick(), change floats to doubles and remove casts to float when the variables are handling coordinates. This also includes sound generation coordinates.
comment by @unknown on MC-3718

Affected entities, blocks or particles

The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.

Falling blocks

The offset is probably caused by the method net.minecraft.client.renderer.entity.RenderFallingBlock.doRender(EntityFallingBlock, double, double, double, float, float). The texture being too large, shifted and rotated is caused by something else.

Particles

Apparently only affects particles created under certain circumstances

Landing particles, see MC-76810 created by @unknown
Particles created by the /particle command
TNT explosion particles
Green bone meal particles
barrier particles
- MCP 9.35 rc1 name
  Method: net.minecraft.client.multiplayer.WorldClient.showBarrierParticles(int, int, int, int, Random, boolean, MutableBlockPos)

Rain and snow

Rain and snow renders as large white lines when you are at a very high y-coordinate. This does however only happen for large y, but not for x or z coordinates.

/teleport ~ 3000000 ~

Linked issues

is duplicated by 10

MC-72550 End Portal Texture on the maximum world border Resolved

MC-72559 Activated TNT wrong position Resolved

MC-92435 Item frames are picky about placement (at least at far distances!) Resolved

MC-101320 extended/glitching snowflakes at high Y values Resolved

MC-105359 FallingSand visual glitch Resolved

5 more links

relates to 3

MC-81299 End Portal Texture Glitch at high x/z axis at 1,000,000 Resolved

MC-92901 End Crystals placed at high coordinates are placed with offset Resolved

MC-98656 Falling blocks don't render correctly as you move farther away from 0, 0 Resolved

Attachments

Comments 40

Dlawso the Really Lucky Rabbit 2015-09-10T00:45:32Z

Literally a dupe of MC-3718. Heck, you even copied the summary.

[Mod] redstonehelper 2015-09-10T02:41:34Z

We didn't want to reopen MC-3718 so we moved the still/newly affected stuff here.

bugi74 2015-09-10T10:00:45Z

Marcono1234: Just in case mods didn't already tell you this, please use the 'preview'-feature when trying to get the formatting right. Every single little committed/saved change generates a new email for those who are (still) watching the issue. Teh spam...

Also, all those tables of offsets are likely useless details; the reason is very likely still the old simple one: floating-point rounding, especially because of using 32-bit single-precision float instead of 64-bit double-precision.

However, listing which things are (still) affected and in which way they can be checked (if it is not trivial) should be useful.

I added several comments about fixes in the old MC-3718, but I'm not going to bother rechecking the possible current causes and/or adding the details to this issue. Its too much work for no effect; it has soon been 3 years and this issue is still kicking strong...

marcono1234 2015-09-10T14:29:01Z

I am sorry, I did not know about the preview feature. When I did this I was also concerned about the spam :/

Also, all those tables of offsets are likely useless details; the reason is very likely still the old simple one: floating-point rounding, especially because of using 32-bit single-precision float instead of 64-bit double-precision.

If you know it better, then please add a comment. I am not familiar with the code and I only added the things known. The tables still might be usefull as they provide at least some information.

However, listing which things are (still) affected and in which way they can be checked (if it is not trivial) should be useful.

I guess I did exactly that. Most of the things described in the old report are fixed (if not all). For pistons for example an explanation would make no sense as it would look like this: "Place a piston, power it"...

And like I said if you have specific suggestions, please just write them in the comments and I will try to add them.

Djfe 2015-10-05T20:01:28Z

A video demonstrating the "fix" for this bug, which shows the laggy and not laggy rendering in comparison
https://www.youtube.com/watch?v=KGPwPC7u03w

30 more comments

bugi74 2015-10-06T06:41:43Z

More correctly, the fix in the video fixes another bug than the ones listed here, but the causes are the same: unnecessary/harmful float casts. (The original source code might not have explicit float casts, but e.g. implicit use of float-type, and the compiler creates the casts. Whatever, end result is the same.)

Djfe 2015-10-10T20:11:00Z

yeah the people in the video's comments just told me the same: it's another bug and also that the video's bug was already fixed (but in a later version than the one used in the video) so just ignore the video I posted it's only related in the aspect you just mentioned
that there are unneccessary float casts that should be removed (but might be caused by the compiler and are better visible in MCP translated minecraft code)

Swekob 2015-10-28T20:37:52Z

Confirmed for 15w44a.

Since MC-50142 is a duplicate of MC-3718, and this is about the same issue as MC-3718, I'll add screenshots. The description of this should also be updated so it mentions what MC-50142 describes.

[Mod] redstonehelper 2015-10-28T21:41:45Z

Included MC-50142, sorry for not staying with your formatting @unknown 🙂

marcono1234 2015-10-28T21:49:57Z

@unknown you can directly write MC-50142 and it will become a link. That way it is also easier to see what this report is about because it gets a hover text as well.

@unknown that is kind of alright 🙂

[Mod] redstonehelper 2015-10-28T21:51:53Z

So that's why Swekob's mentioned tickets aren't struck through when closed. @unknown: Please stop linking tickets your way, it's very confusing.

marcono1234 2015-10-28T21:54:54Z

MC-50142 rather duplicates this report here now

Swekob 2015-10-29T08:13:46Z

@unknown & @unknown: I just realized that just before reading your comments! Thanks anyway 🙂

Swekob 2015-11-06T18:03:09Z

Confirmed for 15w45a.

Swekob 2015-11-26T19:43:41Z

Affects 15w47c

user-f2760 2016-04-26T16:39:08Z

Since the teleport in hight became limited in 1.9.3, I assume the Rain and Snow part will not be fixed.

pascalos99 2017-04-06T19:24:53Z

Affects 17w13b, at least for falling sand: https://bugs.mojang.com/browse/MC-115402

marcono1234 2017-04-26T12:58:57Z

Since the teleport in hight became limited in 1.9.3, I assume the Rain and Snow part will not be fixed.

@@unknown you can still summon an entity at heigh y coordinates and then teleport yourself to it.

tomudding 2017-11-22T16:19:43Z

I can no longer reproduce this in 17w47a.

DoctorGrass 2018-02-18T04:11:04Z

Sand blocks are stuck like that in 18w07c.
still not resolved.

tomudding 2018-03-01T16:26:59Z

Can confirm for the barrier block and TNT particles in 18w09a.

tomudding 2018-03-07T14:39:14Z

Can confirm for 18w10a.

tomudding 2018-04-04T18:35:27Z

Can confirm for 18w11a and 18w14a.

tomudding 2018-04-11T18:22:00Z

Can confirm for 18w15a.

tomudding 2018-04-19T17:35:31Z

Can confirm for 18w16a.

tomudding 2018-05-09T14:28:42Z

Can confirm for 18w19b.

tomudding 2018-05-19T11:33:13Z

Can confirm for 18w20c.

tomudding 2018-06-15T15:31:24Z

Still an issue in 1.13 PRE-2

muzikbike 2018-11-25T11:38:24Z

Affects 18w47b

muzikbike 2018-12-05T17:38:41Z

Affects 18w49a. Can I request ownership of this ticket?

muzikbike 2018-12-12T16:30:27Z

Affects 18w50a

marcono1234 2018-12-13T00:10:58Z

@@unknown, you are now the reporter.

muzikbike 2019-09-27T17:00:12Z

I'm tempted to split this ticket up further, since there's multiple different issues caused by floating point casting. Willing to discuss this on the eigencraft discord.

violine1101 2019-09-27T19:13:49Z

I'd say, go ahead, better to have specific small tickets, than a huge one with everything lumped together.

With 19w39a, the issue with falling sand seems to have been fixed at least.

bugi74 2019-09-27T19:24:17Z

Just add a short text in each of them, describing the that there are separate issues for each case, and add the related links. Otherwise I see someone soon ending up joining them back as "duplicates" or something. (see e.g. MC-6820 and MC-7192 what I mean.)

violine1101 2019-09-27T22:15:09Z

We don't want to have too many large tickets collecting multiple symptoms of what might be the same bug anymore. If there's a code analysis and that code analyis confirms that multiple symptums stem from the same bug, we can do a collection about all instances of the bug, sure. In this case, this seems to be about multiple different cases in which coordinates are not handled correctly by the client – such tickets, we have noticed, are not really helpful to the devs. This ticket has a code analysis, so it's not too bad. But if there's more instances of this bug appearing, things get chaotic rather quickly.

An extreme example with what can happen if we lump too many issues in one ticket can be seen in MC-9553 and MC-138550 for example. We rather have multiple tickets that are neatly cleaned up and linked, rather than one big ticket where everything gets thrown in.

muzikbike 2019-09-28T00:13:46Z

I've split the ticket into MC-161888, MC-161968, MC-161969, MC-161970, MC-161972, MC-161974, MC-161975 and MC-161981, as well as the two existing tickets MC-125638 and MC-76810 that still affect 19w39a.

I'm not sure if the rain issue is still valid, since it's not possible to teleport up that high without using NBT editors or a mod. There's aso some other hard to test prefcision loss errors that I might make tickets for later. Since this is now (to my knowledge) completely split, can it be closed?

FaRo1 2019-09-28T08:11:30Z

You can get arbitrarily high by setting Pos[1] of a dummy entity to a high value (for some reason this requires the "d" at the end) and then (in the same tick?) teleporting yourself to it.

muzikbike 2019-10-02T15:02:46Z

Since I've split this ticket up, can it be resolved?

violine1101 2019-10-07T08:40:22Z

Done.

This ticket has been resolved as invalid as it contained multiple destinct issues. It has split up into separate tickets, most of which are linked as related to this ticket and/or MC-76810.