Falling block visual stuttering bug

COMMAND TO REPLICATE BUG HIGHLIGHTED AT THE BOTTOM

There exists a bug in current versions of Minecraft affecting certain types of Falling Block entities, specifically those that have a "position offset" (example: flowers, pointed dripstone, short and tall grass, most foliage) determined by the XZ coordinates and the world seed. Though happening very rarely in vanilla, both in-game circumstances and commands can easily demonstrate this visual bug.

When a Falling Block with a positional offset is spawned with or at any time during its fall is given (by tnt, a creeper, etc) enough horizontal velocity to cross the boundary into another XZ block position, the current rendering logic assumes that the Falling Block's visual offset must be updated to match its new position. This causes a horizontally moving pointed dripstone, for example, to stutter very jarringly along its trajectory. This "position offset" does not change along the Y axis which is why this bug can be difficult to spot in survival.

The proper rendering implementation for this should be very easy to set up since Falling Block's already contain data of where they spawned initially, which can be used to maintain the proper offset for the entirety of its trajectory. That said, this bug emerges from two classes within the code; ModelBlockRenderer and FallingBlockRender. ModelBlockRenderer has a problematic implementation where both the lighting and "position offset" are handled using the same block position (or BlockPos). This means that if you attempt to simply fix the issue by changing the inputted BlockPos to where the Falling Block initially spawned, as mentioned before, it will cause the entity to permanently retain the lighting of its initial spawning position, causing it to appear extremely unnatural as it falls through different light levels below it.

One way to address this is to allow the ModelBlockRenderer to accept an additional BlockPos object that contains the "position offset" data. That way both the lighting and offset data can be handled separately, since currently the logic that maintains proper lighting conversely breaks the offset rendering and vice versa. See:

After both changes are implemented, here's how it should look!

-

For the Mojang testers, you can easily confirm this bug for yourself by going into a 1.21 world with cheats and running:

/summon falling_block ~1 ~ ~ {BlockState:{Name:"minecraft:pointed_dripstone"},Time:1,Motion:[1.0,1.0,0.0]}

The entity will launch eastbound and you'll notice it stuttering as demonstrated.