Hey, wanted to flag a rendering issue I've been tracking down in the 1.21.1 beta port.
When Advanced Rocketry is loaded alongside rendering optimization mods (specifically Sodium and/or ImmediatelyFast), JEI and FTB Quests screens flicker. The flicker does not occur with AR alone in a minimal test pack, it only shows up in a fuller environment with those rendering mods present.
After digging through the jar I think the culprit is the HDRTextureTarget + LevelRendererMixin combination. It looks like AR injects a custom HDR framebuffer into the level render pipeline, but when a GUI screen opens mid-frame (JEI, FTB Quests, etc.) the framebuffer doesn't get properly unbound before the GUI begins drawing. In vanilla rendering this doesn't manifest because Minecraft's GUI transition code has defensive framebuffer resets. Sodium and ImmediatelyFast strip those out for performance, so the GUI ends up drawing into AR's offscreen HDR target for a frame or two before recovering that's the flicker.
The relevant classes from the jar:
- advRocketry/Render/HDRTextureTarget.class
- advRocketry/mixins/LevelRendererMixin.class
- advRocketry/Render/SkyRenderer.class
- advRocketry/Render/shaderUtils.class
The fix would likely be ensuring the HDR framebuffer is explicitly unbound (restoring the default framebuffer binding) before any GUI screen render begins, or hooking into the screen open event to force a framebuffer flush.
Tested on NeoForge 1.21.1 with Sodium 0.8.12-beta.1 and ImmediatelyFast 1.6.10. Happy to provide logs or more detail if useful.
Here's a video showing what happens:

Hey, wanted to flag a rendering issue I've been tracking down in the 1.21.1 beta port.
When Advanced Rocketry is loaded alongside rendering optimization mods (specifically Sodium and/or ImmediatelyFast), JEI and FTB Quests screens flicker. The flicker does not occur with AR alone in a minimal test pack, it only shows up in a fuller environment with those rendering mods present.
After digging through the jar I think the culprit is the HDRTextureTarget + LevelRendererMixin combination. It looks like AR injects a custom HDR framebuffer into the level render pipeline, but when a GUI screen opens mid-frame (JEI, FTB Quests, etc.) the framebuffer doesn't get properly unbound before the GUI begins drawing. In vanilla rendering this doesn't manifest because Minecraft's GUI transition code has defensive framebuffer resets. Sodium and ImmediatelyFast strip those out for performance, so the GUI ends up drawing into AR's offscreen HDR target for a frame or two before recovering that's the flicker.
The relevant classes from the jar:
The fix would likely be ensuring the HDR framebuffer is explicitly unbound (restoring the default framebuffer binding) before any GUI screen render begins, or hooking into the screen open event to force a framebuffer flush.
Tested on NeoForge 1.21.1 with Sodium 0.8.12-beta.1 and ImmediatelyFast 1.6.10. Happy to provide logs or more detail if useful.
Here's a video showing what happens:
