ISRosillo14

Fixing this caused MC-277218.

This has been "fixed" in 24w18a.

@BugTracker But that's just pure coincidental, for example, the video from the report of MC-180 also shows the bug of MC-193749 (and it's not considered a duplicate)

@EliteTracker This bug doesn't have anything to do with camera stuttering, that's only mentioned in the history of a related boat bug which indirectly affected this.

Can confirm in 24w10a.

Can confirm in 24w09a. I forgot to mention that the good way of fixing this, is by somehow pausing animations from the singleplayer world and continue ticking animations for the screen only.

Can confirm in 24w05a.

As of 20w05a the issue seems fixed. Probably related to the fix of MC-225170.

Can confirm in 23w51b.

Can confirm in 23w51b.

Can confirm in 1.20.4.

Introduced in 1.9 snapshot 15w44b, relates to MC-91715. Also can confirm in 1.20.4.

Can confirm in 1.20.2 and 1.20.3 Pre-release 2. Regarding the proposed fix by ~marcono1234, there's a problem which makes it unviable, as it creates way too many single particles, and each one is sent by the server to every player (client) near the egg, which definitely would lag the server.

So the rest of this comment will adress an alternate fix, which has been already tested on my modified client and seems to work fine without creating lag. Here it is:

The concept of this fix is to basically let server tell the client that it has to create various teleport particles from one position to another. For this we are going to take advantage of the LevelEvent feature, which consists of sending packet ClientBoundLevelEventPacket from server to client (so now we are reducing from hundreds of packets to a single one), but since not everything is perfect, I had to modify level event's integer "data" parameter to use a long number, since we want to store the destination position on the packet witout altering this feature's behaviour (this is why I'm not suggesting to add another BlockPos parameter to the packet, because otherwise it would break this feature for any other part of the game using it and would add more weight), so now we can use the got destination position's BlockPos.asLong() directly at BlockDragonEgg.teleport(BlockState, Level, BlockPos) and through "LevelEvent" the client will handle the teleport particles correctly at LevelRenderer.levelEvent(int, BlockPos, int).

Code attachment depicting the classes I changed (excluding all LevelEvent methods' changes to "data" parameter, from integer numbers to long ones). — From decompiled minecraft 1.19.3 by MCP Reborn using official mapping and my own parameter names.

package net.minecraft.world.level.block;

public class DragonEggBlock extends FallingBlock {
   //...

   private void teleport(BlockState thisState, Level level, BlockPos position) {
       if (level.isClientSide) {//no need to use this method in the client anymore, make it server-side only
           return;
       }

       WorldBorder worldborder = level.getWorldBorder();

       for (int tries = 0; tries < 1000; ++tries) {
           BlockPos destPos = position.offset(level.random.nextInt(16) - level.random.nextInt(16), level.random.nextInt(8) - level.random.nextInt(8), level.random.nextInt(16) - level.random.nextInt(16));

           if (level.getBlockState(destPos).isAir() && worldborder.isWithinBounds(destPos)) {
               level.setBlock(destPos, thisState, 2);
               level.removeBlock(position, false);
               level.levelEvent(1999, destPos, position.asLong());//send DRAGON_EGG_TELEPORT LevelEvent
               return;
           }
       }
   }

   //...
}

Also, in these examples I assigned "1999" as the id of this level event type I added (also present in net.minecraft.level.block.LevelEvent.DRAGON_EGG_TELEPORT).

package net.minecraft.client.renderer;

public class LevelRenderer implements ResourceManagerReloadListener, AutoCloseable {
   //...
   public void levelEvent(int p_234305_, BlockPos eventPos, long /* instead of int */ data) {
      RandomSource randomsource = this.level.random;
      int dataAsInt = (int)data; //compatibilize with other level events
      switch (p_234305_) {
         //...
         case 1999: /* using this number for DRAGON_EGG_TELEPORT event */
             BlockPos destPos = BlockPos.of(data);//this is why we need long number

             for (int j = 0; j < 128; ++j) {//this is moved from DragonEggBlock.teleport(..)
                 double d0 = randomsource.nextDouble();
                 float f0 = (randomsource.nextFloat() - 0.5F) * 0.2F;
                 float f1 = (randomsource.nextFloat() - 0.5F) * 0.2F;
                 float f2 = (randomsource.nextFloat() - 0.5F) * 0.2F;
                 double d1 = Mth.lerp(d0, (double)destPos.getX(), (double)eventPos.getX()) + (randomsource.nextDouble() - 0.5D) + 0.5D;
                 double d2 = Mth.lerp(d0, (double)destPos.getY(), (double)eventPos.getY()) + randomsource.nextDouble() - 0.5D;
                 double d3 = Mth.lerp(d0, (double)destPos.getZ(), (double)eventPos.getZ()) + (randomsource.nextDouble() - 0.5D) + 0.5D;
                 this.level.addParticle(ParticleTypes.PORTAL, d1, d2, d3, (double)f0, (double)f1, (double)f2);
             }

             break;
          //...
      }
   }

   //...
}

In short, instead of creating the particles by the server like Marcono said, we are making the client create them to reduce packet usage, while also fixing this bug.

Can confirm in 1.20.3 Pre-release 2.

I think the best way of solving this problem is by fixing this the way I described before (that "easy" way) and marking MC-116696 as WAI, which makes a lot more sense since the advancements & statistics screens are considered to be pause screens, (and this bug has been re-opened, which inherently means that things aren't supposed to move in pause).

Can I request the ownership for this issue? Of course if user33 agrees first...

This issue also affects particle "minecraft:vibration", because it uses the same animation method as blocks. Video attached reproducing this issue in latest snapshot (23w44a).

The main reason (I think) Dinnerbone marked this issue as WAI is because the fix applied for MC-116696 directly contradicts the fix this bug needs, inside the code. What it's happening here is that the advancements screen is a menu that also pauses the game, so if this bug got fixed the easiest way (just readding the "if not paused" check to the TextureManager.tick() call on Minecraft.tick()), MC-116696 would reappear because AdvancementsScreen is a "pausing screen".

//class Minecraft.java
   public void tick() {
      if (this.rightClickDelay > 0) {
         --this.rightClickDelay;
      }

      this.profiler.push("gui");
      this.chatListener.tick();
      this.gui.tick(this.pause);
      this.profiler.pop();
      this.gameRenderer.pick(1.0F);
      this.tutorial.onLookAt(this.level, this.hitResult);
      this.profiler.push("gameMode");

      if (!this.pause && this.level != null) {
         this.gameMode.tick();
      }

      this.profiler.popPush("textures");

      if (this.level != null) {//what should be here is " && !this.pause" but can't really do it because of MC-116696
         this.textureManager.tick();
      }
      //...
   }

Yeah, you would say that by simply adding a "is advancements screen", the two bugs would get fixed, but no, instead, textures would get animated when you have the advancements screen open. Making the advancements screen a non-pausing screen wouldn't be a good option either, because that wouldn't make much sense since this is very often opened from the pause menu. Also I forgot to mention that MC-116696 also affected the statistics screen.

Should this be marked as "Fixed" due to the new bat model? (which doesn't contain any z-fighting issue)

Interestingly enough, this issue was also present in Beta 1.5, but then got fixed in Beta 1.6

@Dhranios @Connor Steppie The fix you are suggesting (the one that would also fix MC-142156) cannot be applied without rewritting the whole rendering system, as there is currently no way of detecting pixels with alpha=0 while appliying another texture (literally you would need to add a way to insert two or more textures to the shader files, and then compare the alpha value between every one. There are also more ways of detecting 0 alpha pixels, but they are not perfomance-friendly)

It would be better to merge overlapping layers when building models on resource reload (so just one layer of the destroy texture is rendered) and cache them as baked faces at BakedModel.java on separate fields, and use them only when textures like "enchant_glint" and "destroy_progress" are being used. I made some tests yesterday and both MC-166101 and MC-265667 (this issue) seem to be fixed.

@ampolive Yes / May I move the attached videos to the other report after you close this as duplicate?