Repository navigation
[26.3-14] Entity ESP Shader rendering is gated by vanilla outlines and only works when Glow is active #6762
Description
Describe the bug
Description
Entity ESP in Shader mode does not reliably render on Meteor 26.3-14. The issue also reproduces with only Meteor and its bundled dependencies, without third-party addons or optimization mods.
Box mode works. Shader sometimes appears briefly after joining a world, then disappears. This occurs in both singleplayer and multiplayer.
The reporter did not encounter this issue on Meteor 26.2-35.
Environment
- Minecraft 26.3
- Meteor Client 26.3-14
- Fabric Loader 0.20.1
- Java 25
- Windows, OpenGL
Reproduction
- Start a clean Fabric instance with Meteor.
- Enter a singleplayer world with entities matching the ESP filter.
- Enable ESP in Shader mode.
- Observe that the shader outline is missing or disappears.
Resetting ESP, reloading resources, changing fullscreen mode, and switching Java distributions did not resolve it.
Additional diagnostic observation
Using a custom addon containing an independent copy of ESP:
| Built-in ESP | Copied ESP | Result |
|---|---|---|
| Shader | Disabled | Shader missing |
| Disabled | Shader | Shader missing |
| Shader | Glow | Shader renders |
| Glow | Shader | Shader renders |
The addon is not required to reproduce the standalone failure; it helped identify the dependency on vanilla outline rendering.
Findings from local bytecode analysis
In 26.2-35, LevelRendererMixin.draw() directly invokes:
preparedFrame.executeOutline();In 26.3-14, it invokes Minecraft's:
LevelRenderer.executeOutline(preparedFrame);That method returns immediately when currentFrameRendersEntityOutline is false.
Minecraft calculates this flag from the ordinary prepared frame's hasAnyOutline() and shouldShowEntityOutlines. Meteor prepares its Shader entities in a separate queue and switches entityOutlineTarget, but still calls the method guarded by that ordinary-frame flag.
Glow populates the vanilla outline path, explaining why enabling Glow allows the otherwise independent Shader pass to render.
Possible fix
Permit execution specifically while the active target is Meteor's private ESP framebuffer, without enabling vanilla Glow or changing the global outline flag.
A local scoped Mixin implementing this approach passed class-loading and offline checks. Its actual in-game rendering and long-term stability have not yet been verified.
Steps to reproduce
- Launch Minecraft 26.3 with Fabric Loader 0.20.1 and Meteor Client 26.3-14, without third-party addons, optimization mods, or resource packs.
- Enter a singleplayer Creative world containing entities selected in the ESP entity filter.
- Enable the built-in ESP module and set its mode to Shader.
- Observe that the shader outline does not appear, or briefly appears and then disappears.
- Switch ESP to Box mode and confirm that entity highlighting works.
- Switch back to Shader mode. The shader outline remains missing.
Meteor Version
Meteor Client 26.3-14
Minecraft Version
Minecraft 26.3
Operating System
Windows
Before submitting a bug report
-
This bug wasn't already reported (I have searched bug reports on GitHub).
-
This is a valid bug (I am able to reproduce this on the latest dev build).
Activity
github-actions commentedon Oct 27, 2026
This issue is being automatically closed.
Please create a new issue following one of the templates.
cherryrodney26 commentedon Oct 29, 2026
The change in 26.3-14 suggests the engine now checks for active
OutlineBufferstate before allowing custom shader calls. Since the ESP only triggers when the vanillaGloweffect is active, it is likely that theLevelRendererMixinis failing to initialize or bind the necessary framebuffer attachments unless the vanilla outline pipeline is already initialized. Have you checked if manually forcing anOutlineBufferinitialization in thedrawmethod restores the ESP rendering without requiring theGloweffect?NameGTHuB commentedon Oct 30, 2026
Thanks for the suggestion. I investigated this against Minecraft 26.3 and Meteor Client 26.3-14. Your suspicion about the dependency on vanilla outline state was close.
The framebuffer appears to be set up correctly: Meteor’s
LevelRendererMixin.draw()callsmeteor$pushEntityOutlineFramebuffer(shader.framebuffer), prepares its own render queue, and then calls vanillaLevelRenderer.executeOutline().The issue is that
executeOutline()gates rendering oncurrentFrameRendersEntityOutline. Without a vanilla glowing entity, this flag can be false, so Meteor’s outline pass is skipped despite its framebuffer and queue already being prepared. A Glow effect makes that condition true, which explains why Shader ESP starts working.I implemented a workaround in my addon that permits this check only when
entityOutlineTargetis exactly Meteor’s or my addon’s private ESP framebuffer. It leaves the stored vanilla flag unchanged and does not force entities to glow or add framebuffer initialization.This restored standalone Shader ESP in my in-game tests. The evidence therefore points to the vanilla outline gate being reused for a custom pass, rather than a missing framebuffer initialization or binding.