Shader Compatibility¶

This document explains how Ansible Crafting handles rendering when shader mods like Iris are active, why different shader packs may behave differently, and which shader packs have been tested.

See also: Architecture Overview for the overall rendering pipeline, Configuration Reference for highlight and overlay settings.

How It Works¶

Ansible Crafting renders two types of visual elements in the 3D world:

1. Block highlights — colored wireframe outlines around inventory blocks (when you click an item in the side panel)
2. Wifi overlay icons — small status icons on the faces of inventory blocks showing enabled/disabled state

Without shaders, these are rendered using Minecraft's vanilla rendering pipeline during the AFTER_TRANSLUCENT world render phase. This works because the vanilla pipeline provides a reliable depth buffer for occlusion (hiding icons behind walls) and processes our shader programs (POSITION_COLOR for highlights, POSITION_TEXTURE for icons) correctly.

The Problem with Shaders¶

Shader mods like Iris replace Minecraft's rendering pipeline with their own. This causes two issues:

1. Vanilla shader programs are replaced. Iris substitutes its own shaders for POSITION_COLOR and POSITION_TEXTURE, which may render to different framebuffers or produce no visible output.

2. Post-processing overwrites output. Iris applies compositing passes (bloom, tonemapping, color grading) after the AFTER_TRANSLUCENT phase, which can overwrite or discard geometry rendered during that phase.

The Solution: Shader-Aware Dual Rendering¶

Ansible Crafting detects Iris at runtime using reflection (no hard dependency) via the ShaderCompat utility class. When shaders are detected:

flowchart TD
    FRAME[Frame Render] --> AT[AFTER_TRANSLUCENT event fires]
    AT --> CHECK1{Shaders active?}
    CHECK1 -->|No| RENDER_NORMAL[Render highlights + overlays<br/>GPU depth test for occlusion]
    CHECK1 -->|Yes| SKIP[Skip rendering]

    FRAME --> LAST[LAST event fires]
    LAST --> CHECK2{Shaders active?}
    CHECK2 -->|Yes| RENDER_SHADER[Render highlights + overlays<br/>Raycast occlusion for icons]
    CHECK2 -->|No| SKIP2[Skip - already rendered]

• Without shaders: Renders at AFTER_TRANSLUCENT with GPU depth testing — pixel-perfect occlusion, zero overhead.
• With shaders: Renders at LAST (after Iris compositing finishes) with raycast-based occlusion — slightly less precise but reliable across shader packs.

Raycast Occlusion¶

When rendering at LAST, the GPU depth buffer may not accurately represent the scene (Iris may have modified it during compositing). Instead of relying on the depth buffer, we cast a ray from the camera to each icon's position on the block face using Minecraft's World.raycast(). If the ray hits a different block first, the icon is behind a wall and is skipped.

Key detail: The raycast targets the icon's actual world-space position on the block face, not the block center. This ensures accurate occlusion even with non-full blocks like crafting tables, slabs, and stairs.

Performance: Each raycast costs ~1-5 microseconds. With typical inventory counts (10-50 visible blocks), the total overhead is 50-250 microseconds per frame — well under 1% of a 60fps frame budget. Raycasting only runs when shaders are active.

Why Different Shader Packs May Behave Differently¶

Each shader pack controls:

• When and how the depth buffer is modified during compositing passes
• Which framebuffers are active at each rendering stage
• How custom geometry (like our highlights) interacts with the shader pipeline

This means:

• Some shader packs may cause highlights to appear slightly brighter or dimmer than without shaders
• Some shader packs may apply bloom or glow effects to the highlight wireframes
• In rare cases, a shader pack's compositing may interfere with the LAST render event

These are cosmetic differences, not functional failures. The highlights and icons should always be visible — they just may look slightly different depending on the shader pack's post-processing.

When to Report an Issue¶

Please open an issue on GitLab if:

• Highlights or overlay icons are completely invisible with a specific shader pack
• Icons render through walls that they shouldn't (occlusion failure)
• The mod crashes when a shader pack is enabled
• Visual artifacts appear that make the highlights unusable

Include the shader pack name, version, and Iris version in your report.

Shader Detection¶

The ShaderCompat class detects shader mods using Java reflection:

Detection happens once at mod initialization (class loading). The areShadersActive() check runs once per frame and costs ~50 nanoseconds (cached reflection method handles).

Known Shader Packs¶

The following table tracks shader pack compatibility with Ansible Crafting. "Compatible" means block highlights and wifi overlay icons are visible and functional. "Untested" means the pack hasn't been verified yet.

Status key: - ✅ Compatible — highlights and overlays work correctly - ⚠️ Partial — works with minor visual differences (noted in comments) - ❌ Incompatible — highlights or overlays are invisible or broken - ❓ Untested — not yet verified

Help us build this list! If you've tested Ansible Crafting with a shader pack, let us know by opening an issue or submitting a merge request to update this table. Include the shader pack name, version, Iris version, and whether highlights and overlay icons were visible.

How to Test¶

1. Install Iris + Sodium + your shader pack
2. Install Ansible Crafting with its dependencies
3. Place a crafting table near some chests/barrels
4. Open the crafting table and click an item in the side panel — verify colored wireframe highlights appear on the containers
5. Close the crafting table — verify wifi overlay icons are visible on container faces
6. Place a solid block (like stone) between you and a container — verify the wifi icon is hidden behind the block
7. Toggle shaders off (Iris settings) — verify everything still works without shaders

Technical Reference¶

Key Classes¶

Render Events Used¶