Weird bug causes entities to become invisible

[MenacingPerson]

Best replicable in an igloo.

[tr7zw]

This is a current issue with the math/logic screwing up. Currently trying to lookup/get together the math to make the tracing work differently, and then this should be resolved in the same go.

[itsdinkd]

Any luck on this

[tr7zw]

Haven't got around to it yet, since this bug is like searching for a needle in a haystack. Somewhere something is done the wrong way around, the direction of checking the blocks is an issue or something like that. I know that it's an issue with what gets put into the cache, the issue is that removing the cache slows down the entire thing by a good chunk. I want to try to redo the vision-logic by using a pyramid from the eye to the corners of the hitbox and then checking the cubes in between. The issue with that is to get the math down which will eat many many hours.

[LMLB]

I made a test world: EntityCulling item frame test.zip

Stand on or near the planks and place an item frame on the iron block.

The bug doesn't seem to happen if an item frame is already on the iron block when the world is loaded. In this case, remove and replace the item frame to trigger the bug again.

There's also an item frame behind the wall by the way.

(I tested this in Minecraft 1.18.1 with Entity Culling 1.3.3 for Fabric)

[tr7zw]

Thanks, I'll look into it once I'm done handling a big license issue I'm facing currently.

[tr7zw]

OH MY GOD... I want to die...
First of all, thank you so much for this minimal example map that even made it possible to debug this in a sane way... I checked what gets written to the cache, checked the values that get written and read, checked the logic from a top level...
It turns out, the reason it was broken was a single id++; missing inside a really early exit condition.
For the logic:

• check all positions you will be checking and note in order the cache value for it. If you find a visible cache value, return true.
• if you get to here there was no already known path to the target
• go through all locations again
• if the current id was marked before as non visible, skip it
• otherwise check the location, if visible return true, otherwise increment the current id...

And the issue is in line 4... it doesn't increment the id it is on... So depending on entity loading order, the back itemframe gets checked first, and correctly marks the 2 stone blocks sticking out and the 2 below and 2 left to it as solid blocks. Now the front itemframe gets checked, the first loop notes the 2 sticking out stone blocks as checked invalid, then the second check(because it starts at the min position and goes to the max position) will first check the front left stone, see that it's noted as invalid, but forget to increment the value it is on. This causes all other(absolutely valid paths) to also check this front stone. Result: the code assumes there is no valid free block around the item frame, therefore it does no tracing at all, turning it invisible.
This explains why it is directional, so hard to replicate, and ate more hours than I want to admit... 5 characters/a simple logic fuckup...
Will be fixed next release 🙃

[tr7zw]

Fixed in 1.5.0.

[newbthenewbd]

Don't want to be that guy, but it seems to me that in some cases the problem persists, and one of them is simply when there's a 3-or-4-block high ceiling while in third person mode... Here's hoping it's instantly reproducible and not an obscure conflict with some other e.g. trig optimization thing I've got installed :)

Quick video showcasing it here, if there was, say, a lot of chests nearby, some would also disappear:

2022-02-11.02-07-43.mp4

Anyways, while I'm still here, many thanks for the mod!

[tr7zw]

Ehhhhh I think that's something else, that the camera sliiiightly clips into the block(I hope). Shouldn't be that bad to fix and is certainly less of an issue compared to the one above^^

[tr7zw]

Adding a bit of code so that if the ray starts inside a solid block, to allow it to travel through solid blocks till it's outside once. Could potentially make spectator compatible(currently it just turns off) and allow better freecam compatibility(or other cases where you manage to ram your head/camera into a solid wall).

[tr7zw]

Hm so far unable to reproduce it(1.18 fabric only entityculling 1.5.0/ 1.18.1 fabric highly modded with version 1.4.0). Do you potentially have a mod like better third person mod installed? (or other info like optifine?)

[newbthenewbd]

entityculling-forge-mc1.18-1.5.0.jar
trulytreasures-forge-1.18.1-2.2.3.jar
collective-1.18.1-4.0.jar
fixedanvilrepaircost_1.18.1-1.7.jar
justenoughmobs-1.18.1-1.0.0.jar
sit-1.18-1.3.1.jar
lazydfu-1.0-1.18+.jar
krypton-1.0.0.jar
AI-Improvements-1.18-0.4.0.jar
ferritecore-4.1.1-forge.jar
worldedit-mod-7.2.9.jar
hourglass-1.18-1.2.1.0.jar
Ping-1.18.1-1.8.0.jar
sneakthroughberries-1.1.0+1.18.1-forge.jar
soundphysics-forge-1.18.1-1.0.4.jar
magnesium-0.4.0-alpha6.jar
starlight-1.0.1+forge.36a1c6c.jar

A few are custom in here, but a wild guess would be that only Ferrite Core or Magnesium could be the culprit... I will take a quick look without.

[newbthenewbd]

Also happens with both removed. Maybe it's something with Forge?

[tr7zw]

Ok was able to reproduce it... But only under Forge... So this actually seems to be a Forge bug that probably moves the camera ever so slightly into the wall... 🙃

[tr7zw]

RjkSD4uGSm.mp4

You can actually see that the pixels of the tree/grass shift by one pixel on a 4k image... That's fun... Thanks Forge.

[tr7zw]

This will be tracked at #11 .