mojira.dev

tterrag

More than one avatar was detected! There might be multiple accounts sharing this same name.

Assigned

No issues.

Reported

MC-127478 Texture metadata parsing fails if animation block is not present Fixed MC-102384 Chat screenshot links are broken in Windows Cannot Reproduce MC-84633 Resource packs: ambientocclusion flag only respects topmost parent Fixed

Comments

This was fixed in 1.13-pre6 (at least my suggested code adjustment was implemented by Grum) however it still seems to affect a very small amount of players. I have a feeling this is mostly players with Intel GPUs. The second example video posted by Kumasasa shows an Intel GPU in the debug screen.

So please, if you can reproduce this, give us the model of your GPU, or just post a screenshot with F3 open.

The game uses this bit of rendering magic to prevent z-fighting for the breaking animation:

GlStateManager.doPolygonOffset(-3.0F, -3.0F);

However, this seems to be ineffective at nearly perfectly straight-on viewing angles. I think this is due to the second parameter, the constant, being too low. I tested changing this to

GlStateManager.doPolygonOffset(-1.0F, -10.0F);

And was not able to reproduce this bug anymore, nor could I find any new issues caused by this change.

Using MCP names, this change was made in RenderGlobal.preRenderDamagedBlocks.

That's not how mcmeta files have ever worked...they have multiple sections that are all optional. It depends on the resource what sections it reads and uses. Prior to 1.13 it was entirely valid to leave out the animation section. I would really like to hear from Mojang on this issue because I sincerely doubt it is intended.

I believe I have finally solved this bug, in attempting to fix my own extension of this particle's glitchy movement. Here is the explanation as well as I can give it, using MCP names for the methods involved:

  • Particle#setSize is bugged in that it sets the BB based on the min coords. so a width/height of 0.2 gives a bb from 0,0,0->0.2,0.2,0.2.

  • Particle#setPosition moves the BB so that its geometric center is at the particles xyz coords.

  • There is no problem you call setSize() and then setPosition(). But particles like ParticleDrip call setSize() a second time, which shifts the BB to the NW (negative axes).

  • Particle#resetPositionToBB is what actually causes the glitched movement.

  • The bug (imo) is Particle#setSize growing the BB from the min not the center.

This is still occuring in 1.12 pre-2. An example resource pack is here.

Iron Ore was changed to have "ambientocclusion":false, but it still inherits from block/cube_all
Gold Ore was changed to have no parent, but has ambientocclusion set to true
Coal Ore was changed to have no parent, but has ambientocclusion set to false.

How this resourcepack appears ingame:

[media]

The ore textures were modified to more clearly show the AO effects (and lack thereof).

Intended result: Iron Ore and Coal Ore should have no AO
Actual result: only Coal Ore has no AO

All models will obey the AO flag of their topmost parent. This does not seem intentional.

If this went from broken to working, wouldn't that imply that it was fixed, not "Cannot Reproduce" ?

It is definitely not working in 1.10.2.