EntityCulling and MoreCulling: modded blocks turn invisible

The symptom, in two flavours

Install EntityCulling and your Create trains go invisible the moment they assemble. Install MoreCulling and the world develops holes, or a modded block renders as a hollow frame with nothing inside it.

These look like different bugs. They are the same bug wearing two hats. Both mods decide what not to draw by comparing a cheap approximation of an object's shape against what the camera can see, and modded content routinely violates the assumption baked into that approximation.

EntityCulling: the box is not the model

EntityCulling raytraces to an axis aligned bounding box. Its CullTask fetches that box through NMSCullingHelper.getCullingBox(entity), which returns entity.getBoundingBoxForCulling(), then asks culling.isAABBVisible(min, max, camera) whether any ray reaches it. If nothing does, the entity is not drawn.

For a cow that is fine. The box and the cow are roughly the same size. For a Create contraption it is not, because the contraption entity carries a small hitbox and a rendered model that can be tens of blocks across. The model is drawn far outside the box the mod is testing, so the mod concludes nothing is visible while most of the screen should be full of train.

That is exactly what the reports describe. Issue 76, filed in July 2022 and cross posted from Create, states that "Trains in Create 0.5 are invisible when they are created if Entity Culling is present." Issue 84 adds the partial version: "Different parts of the train get culled, resulting in different parts of it getting stretched all around, making the train incredibly confusing to use."

The same mismatch hits block entities. Issue 51, "RenderBoundingBox of BlockEntity is ignored for culling", reports that EntityCulling treated every block entity as a single block box regardless of what the block entity actually renders, which breaks any multiblock where one master block draws the whole structure. ProjectRed's lit lamps hit it from the other direction in issue 54: "Their lit lamps have what seems to be an entity of 'light' that surrounds the block that is incorrectly determined as out of the players' viewport." And in July 2026, issue 313 reported CC: Tweaked monitors losing their display quad when the lower left block leaves the frustum, leaving "a hollow frame, as if the display quad had been culled."

Fixing EntityCulling

Edit config/entityculling.json. There are three lists and they are not interchangeable: entityWhitelist, blockEntityWhitelist and tickCullingWhitelist. Add the offending registry ID to the one that matches what the object actually is.

The default config already carries the well known offenders, including create:contraption, create:carriage_contraption, create:gantry_contraption and create:stationary_contraption. Two more arrived through pull request 304, merged in June 2026, titled "Update default config to not break Create Big Cannons entities" and opened by Create Big Cannons' own author, adding createbigcannons:pitch_contraption and createbigcannons:cannon_carriage. That pull request is the cleanest evidence of the mechanism, because it includes screenshots of the box next to the model it is supposed to represent.

Wildcards are not supported. Entries are looked up as exact registry IDs and quietly discarded if they do not resolve, so there is no error to tell you your entry did nothing.

MoreCulling: a non-solid block treated as a full cube

MoreCulling's version of the mistake happens at block shape level. Issue 464, filed on 29 July 2026, pinned it precisely: when a model declares neither cullshapes nor useModelShape, the fallback calls getOcclusionShape without re-checking canOcclude first. As the report puts it, getOcclusionShape "defaults to state.getShape(...), and Block's default shape is a full cube", so "for canOcclude == false blocks without a getShape override the fallback manufactures a full-block cull shape."

The consequence is that a modded block which explicitly declared itself non-solid gets treated as a solid cube, and every neighbouring face touching it is culled. That is where the holes in the world come from. You are not seeing the modded block disappear, you are seeing the blocks around it disappear.

Fixing MoreCulling

Update first. Issue 464 was fixed in commit ade203b, contained in tags v1.7.3 and v1.8.1.

If you cannot update, set useOnModdedBlocksByDefault to false. It defaults to true and seeds a per-mod modCompatibility map, so turning it off keeps the optimisation on vanilla blocks while handing modded blocks back to Minecraft's own culling.

Not every MoreCulling report is this bug. Issue 465 covers backpack models from Sophisticated Backpacks and Traveler's Backpack vanishing depending on camera direction, and the fix there is the item frame options: useCustomItemFrameRenderer, itemFrameMapCulling, useItemFrameLOD and useItemFrame3FaceCulling. Issue 455 reports Farmer's Delight bamboo baskets being culled wrongly on 1.21.1 NeoForge and is still open.

The general rule

If something modded vanishes after you install an optimisation mod, do not start by turning the mod off. Work out which approximation it is using, then check whether the thing that disappeared honours it. An entity whose model is much larger than its hitbox, and a block that is transparent but does not describe its own shape, are the two shapes of content that break culling, and both mods give you a per-object escape hatch rather than an all or nothing switch.