Fusion

Fusion

Minecraft 1.20.1 / Forge: this page documents that build and its measurements. For the separate 170-control Minecraft 1.21.1 port, see Minecraft 1.21.1 NeoForge.

Two client-side controls for Fusion 1.3.14+a (mod id fusion), both added in 1.0.26: chunk-layer checks read the layer id Forge already stores on every render type, and connected-texture lookups compare blocks by identity and hash each connection key once. The separate BonsFusion mod is not part of this JAR. Another Fusion build is left untouched with one WARN line.

Key	Target	Side	Since	Kind
fusion_chunk_layer_id	Fusion 1.3.14+a	CLIENT	1.0.26	opt
fusion_connection_lookups	Fusion 1.3.14+a	CLIENT	1.0.26	opt

---

fusion_chunk_layer_id

Since: 1.0.26 · Target: Fusion 1.3.14+a · Side: CLIENT · Kind: opt

Mixins: ChunkLayerIdMixin

Fusion keeps its connected-texture quads in small per-layer maps, and every access asks whether the render type is one of the five chunk layers (an equals search through the layer list) and then looks its index up in a map. Forge already gives every render type that index: the chunk layers get 0 to 4 in the same list order, every other type gets -1. The two checks now read it. Only Oculus' wrapper render types define their own equals, and none of them matches another class, so every answer stays the same, including for render types that are not chunk layers.

Measured: in a harness running Fusion's own classes, the per-face layer-map work took 123 ns instead of 171 (1.4x faster), no change in allocation; these checks were about 2% of chunk meshing time.

In-game section comparisons found no differing vertex/index data. The isolated in-game timing difference was inside the rig's noise; the method-level speedup above is not a demonstrated whole-meshing or FPS gain. The separate BonsFusion changes are not part of this JAR.

---

fusion_connection_lookups

Since: 1.0.26 · Target: Fusion 1.3.14+a · Side: CLIENT · Kind: opt

Mixins: ConnectionKeyHashMixin, MatchBlockIdentityMixin

Two lookups on Fusion's connected-texture path. The key under which Fusion stores a face's connection result hashed all of its parts on every store access (two to three per connected face), every block of a block list included; the parts never change, so the first hash is now kept, computed exactly the way Java computes it for any record. A "match these blocks" condition asked its block set whether it holds the neighbour, which calls equals and hashCode on blocks; no block in the pack defines either (checked again at startup over every registered block), so sets of up to 16 blocks are now scanned by identity. Larger sets, and any pack where a block does define equals, keep Fusion's set.

Measured: in a harness running Fusion's own classes, block checks 1.3x to 1.9x faster (4.2 ns instead of 6.2 for one or two blocks) and the key's use in the property store 1.3x faster; no change in allocation.

In-game section comparisons found no differing vertex/index data. The isolated in-game timing difference was inside the rig's noise; the method-level speedup above is not a demonstrated whole-meshing or FPS gain. The separate BonsFusion changes are not part of this JAR.

Since 1.0.34. The values this control keeps on a record class are skipped by Gson. Up to 1.0.33 a mod that saves such a record with Gson failed with a NoSuchMethodException, because Gson asks a record for an accessor for every field it holds (reported with Dragon Mounts Remastered on Minecraft 1.21.1; no case is confirmed on Forge 1.20.1). Nothing else changes.