What this is

A one-mixin client fix for Create's shafts, cogwheels and other Flywheel-instanced models rendering as blown-out white shapes when a shaderpack is enabled.

NeoForge 21.1.x / Minecraft 1.21.1. Nothing is modified or redistributed — install it, remove it, nothing is written to your world.

The problem

Turn on a shaderpack and Create's kinetics stop looking like objects. Shafts become solid white bars, cogwheels lose their teeth, everything bleeds bloom into the surrounding blocks. The usual description is "glowing and semi-transparent", but that is the eye's reading of the actual failure: the geometry is drawn massively overbright, and the exposure destroys the shape.

Everything else in the world renders normally. Turn shaders off and Create looks correct again.

The cause

Flywheel supports order-independent transparency. Materials tagged Transparency.ORDER_INDEPENDENT are not drawn like everything else — InstancedDrawManager.render sorts them into a separate oitDraws list, renders them into an accumulation buffer (OitFramebuffer), and resolves that buffer in a composite pass afterwards.

iris-flywheel-compat supplies its own IrisInstancedDrawManager, which is a structural copy of that method — same fields, same call order — so it inherits the split. But its programs are built by irisflw's own compiler rather than Flywheel's, and the composite step does not survive the trip. The accumulation buffer is never resolved, and what reaches the screen is raw weighted accumulation.

That is precisely what raw accumulation looks like: far too bright, shape washed away, blooming.

What this mod does

It reports ORDER_INDEPENDENT as OPAQUE, which sends those draws down the ordinary path where nothing needs resolving. The geometry comes back correct.

The swap is gated on ShadersModHelper.isShaderPackInUse(). Without a shaderpack nothing changes at all — Flywheel's own OIT works fine there and is left alone.

Trade-off, stated plainly

While a shaderpack is active, Flywheel materials that genuinely want order-independent blending render opaque instead. In practice this is hard to notice next to the bug it replaces, and the alternative most people land on is backend = "flywheel:off" — which disables Flywheel entirely and puts every block entity back on the CPU.

Install

Drop the jar into mods/. Client only — it changes rendering and nothing else. displayTest = "IGNORE_ALL_VERSION" is set, so it will not cause a mod-list mismatch when joining a server.

Requires Flywheel (bundled with Create). Only does anything useful alongside iris-flywheel-compat, but it is harmless without it.

You do not need this if

You play without shaders
You do not use iris-flywheel-compat
Your Flywheel backend is already flywheel:off — though you can now turn it back on, which is the point

If a future version breaks it

The mixin config uses "defaultRequire": 1, so if Flywheel changes the target method the game fails to start with a clear Mixin error instead of silently doing nothing. If that happens, remove this mod.

Notes

Not affiliated with the authors of Create, Flywheel or iris-flywheel-compat. Found by elimination against a live modpack: the generated GLSL, the light values in Java and on the GPU, instance colour and alpha, the packed material uniform and the shaderpack program were each measured and cleared before the accumulation buffer became the remaining candidate.

The intent is that this is fixed upstream in iris-flywheel-compat, at which point this mod becomes unnecessary.

Flywheel OIT Fix