mojira.dev
MC-239212

Vector3f#normalize treats small lengths the same as 0

Vector3f#normalize treats small lengths the same as 0.

 

Instead of using 1.0E-5D a value such as Float.MIN_NORMAL or checking if it's greater than 0 can be done.

 

Using forge's render pipelines

[media]

 

I haven't found a case where it's directly impacting Minecraft rendering pipeline though it does cause certain faces to turn completely black in forge due to the way lighting is calculated.

 

I haven't fully checked though there may be problems with rendering small parts in mc but with different bugs.

 

This is with the threshold removed, so it can be removed or possibly lowered.

  

[media]

Attachments

Comments 3

This sounds like a forge bug, not a Minecraft bug. Can you verify if this is indeed also the case with the base game, without forge? (I mean the core issue, I understand the result is only visible with mods)

The issue is that the render pipeline seems to be the only part affected by this.

Though it seems to have been coded in a way that has this error in mind. But the way the render pipeline has been made causes render problems like this in vanilla.

This isn't a direct result of the bug however it seems to be a problem resulting from how the normals are being used after being calculated.

[media]

How it should possibly look with multiple render pipeline fixes applied.

 

 

[media]

The only reason it doesn't seem to cause a bug in Minecraft on its own is where it's used that actually gets small seems to be written in a way that doesn't cause a consistent problem. However, the code that handles the normals after rather than actually treating them as normals seems to cause even more issues as seen in the screenshots above.

I may be completely misunderstanding what's going on however that's what I can see from tinkering with the decompiled code's logic.

It's only really really tiny blocks around 1px large that seem to have the vector maths bug though. The other issues seem to be caused by how the returned normals are processed.

After a bit of a look into it, the only other places other than block face normals that it is used are larger vectors which will always be the same before normalised. And any places where this code is hit by this problem are handled in a way that it doesn't matter if it occurred.

 

The problem is that while yes the main issue is a bug affecting forge it is caused by the function having way too high a value.

Sekwah

(Unassigned)

Confirmed

(Unassigned)

1.17.1, 22w18a

22w43a

Retrieved