[1.21.11] Fast Item Frames conflict: front face of 3D item-frame contents is culled on even rotations when itemFrame3FaceCulling is enabled

[BraianAzcune]

Summary

I found a reproducible rendering conflict between MoreCulling and Fast Item Frames.

With both mods enabled, 3D item contents inside item frames (example: a normal block item) lose their front face at specific rotations.

Pattern:

• Rotation 0°: front face missing
• Rotation 45°: renders correctly
• Rotation 90°: front face missing
• Rotation 135°: renders correctly
• (same alternating behavior continues)

Environment

• Minecraft: 1.21.11
• Loader: Fabric 0.18.4
• MoreCulling: moreculling-fabric-1.21.11-1.6.2
• Fast Item Frames: FastItemFrames-v21.11.1-mc1.21.11-Fabric
• Fabric API: 0.141.3+1.21.11

Reproduction

1. Enable MoreCulling + Fast Item Frames.
2. Keep MoreCulling item frame options enabled:
   • useCustomItemFrameRenderer = true
   • useItemFrame3FaceCulling = true
3. Place an item frame and put a 3D block item inside.
4. Rotate the item with right-click and observe alternating visibility of the front face.

Expected

The item should render consistently at all frame rotations.

Actual

The item front face is culled at even rotations (0/90/180/270), but appears at odd steps (45/135/225/315).

Workaround

Setting useItemFrame3FaceCulling = false completely avoids the bug while keeping both mods active.

Technical hypothesis (conflict area)

Not proposing a fix here, only sharing where the conflict appears to happen:

• MoreCulling replaces item-frame rendering path in:
  • ItemFrameRenderer_cullMixin (moreculling$optimizedRender)
• Item rendering is redirected through:
  • ExtendedItemStackRenderState.moreculling$submitItemFrameItem
  • then quad filtering in ItemStackRenderState_faceCullingMixin
• The 3-face culling branch is gated by:
  • useItemFrame3FaceCulling
  • dist > itemFrame3FaceCullingRange
  • frame.rotation % 2 == 0
  • transform rotation checks
• Fast Item Frames builds and submits a custom/synthetic ItemFrameRenderState from block-entity data (instead of vanilla entity path), including forced invisibility behavior.

Given this, the interaction seems to happen specifically in MoreCulling’s 3-face quad-direction filtering for item-frame items when the state comes from Fast Item Frames. The even-rotation gate (frame.rotation % 2 == 0) matches the exact visual pattern.

Why I’m reporting

Mainly for discoverability and reproducibility, so users searching this rendering issue can identify the source and apply the known workaround.