[1.21.4pre9 Bug] CIT with custom non-3D models render invisible, CIT shields don't work, CIT potions render invisible, CIT armor models don't work

[SeaOfPixels]

Description of Issue

In 1.21.4pre7, various instances of CIT do not apply, or render invisible. CIT that uses a custom model that is not a 3D model render invisible. Additionally, CIT shields do not apply in-game, CIT potions render invisible, and CIT armor models do not apply in-game.

Model properties

CIT model that is not 3D, makes item render invisible:

{
  "parent": "item/generated",
  "display": {
    "gui": {
      "rotation": [ 0, 0, 0 ],
      "translation": [ -1, -1, 0 ],
      "scale":[ 1.75, 1.75, 1 ]
    },
    "ground": {
      "translation": [ 0, 2, 0 ],
      "scale": [ 1, 1, 0.5 ]
    },
    "head": {
      "rotation": [ 0, 0, 0 ],
      "translation": [ 0, 0, 0],
      "scale":[ 5, 5, 5 ]
    },
    "thirdperson_righthand": {
      "rotation": [ 0, -90, 55 ],
      "translation": [ 0, 4.0, 0.5 ],
      "scale": [ 1.70, 1.70, 0.85 ]
    },
    "thirdperson_lefthand": {
      "rotation": [ 0, 90, -55 ],
      "translation": [ 0, 4.0, 0.5 ],
      "scale": [ 1.70, 1.70, 0.85 ]
    },
    "firstperson_righthand": {
      "rotation": [ 0, -90, 25 ],
      "translation": [ 1.13, 3.2, 1.13 ],
      "scale": [ 1.36, 1.36, 0.68 ]
    },
    "firstperson_lefthand": {
      "rotation": [ 0, 90, -25 ],
      "translation": [ 1.13, 3.2, 1.13 ],
      "scale": [ 1.36, 1.36, 0.68 ]
    },
    "fixed": {
      "rotation": [ 0, 180, 0 ],
      "scale": [ 2, 2, 1 ]
    }
  }
}

CIT shield example properties, does not apply texture in-game:

type=item
matchItems=minecraft:shield
model=optifine/cit/models/new_default_plus_dungeons/shield_scale_x32_buckler
model.shield_blocking=optifine/cit/models/new_default_plus_dungeons/shield_scale_x32_buckler_blocking
nbt.display.Name=regex:Buckler|.*\\(Buckler\\)|\\(Buckler\\).*

CIT potion example properties, makes item render invisible:

type=item
items=potion
model=item/fire_resistance_potion
components.potion_contents.potion=minecraft:fire_resistance

CIT armor example properties, does not apply texture in-game:

type=armor
items=minecraft:diamond_chestplate minecraft:netherite_chestplate
texture.diamond_layer_1=amethyst_armor_1
texture.netherite_layer_1=amethyst_armor_1
nbt.display.Name=pattern:Amethyst Armor Chestplate

OptiFine Version

OptiFine 1.21.4_HD_U_J3_pre7

Screenshots

Invisible CIT non-3D models:

Broken shield CIT:

Invisible potion CIT:

Broken CIT armor models:

Test resource pack

https://legacy.curseforge.com/minecraft/texture-packs/newdefaultplus/files/5945906

[sp614x]

Model resolving and relative paths fixed in pre9.
Many properties have invalid checks like "nbt.Damage=453".
Many models complain about missing textures:

Unresolved texture references in minecraft:optifine/cit/models/melee_scale_x32:
	#particle-> #layer0

[SeaOfPixels]

Pre9 fixed invisible non-3D CIT models and invisible potion CIT, shield CIT and armor model CIT are still broken.

[SeaOfPixels]

Model resolving and relative paths fixed in pre9. Many properties have invalid checks like "nbt.Damage=453". Many models complain about missing textures:

Unresolved texture references in minecraft:optifine/cit/models/melee_scale_x32:
	#particle-> #layer0

The nbtDamage error is coming from elytras, as there seems to be an issue in the latest OptiFine versions where broken elytra textures do not function using NBT damage 431 (it's 431, not 453 as you stated). Regarding the model "#layer0" error, these models are used by multiple CIT items and thus cannot have textures assigned inside the model. Using models with CIT where the models themselves don't specify textures makes them default to using the vanilla item's texture and thus the CIT texture, which is a completely normal thing for resource packs to do and I don't understand why it's outputting error logs.

EDIT: The "layer0" errors are new to OptiFine 1.21.4, they did not appear in OptiFine 1.21.1. Unless I missed them, this seems to be a bug in OptiFine 1.21.4, unless something changed that packs need to account for on their end:

1.21.1 (no errors):

1.21.4 (layer0 errors):

[sp614x]

In 1.21.4 the #particle texture is required and comes from the model.
The "item/generated" model has parent "builtin/generated" which automatically adds an alias "#particle -> #layer0" and later the vanilla texture resolver complains if the #layer0 is missing.
If the 3D model has no geometry and is only used for the transforms then OF could remove the #particle mapping and use the 2D model texture as particle.

[sp614x]

Instead of nbt.Damage=431 you can use the CIT check damage=431.
The item NBT checks were replaced with component checks in recent MC versions.
OF only supports some NBT checks (like nbt.display.Name) for backwards compatibility.
https://github.com/sp614x/optifine/blob/master/OptiFineDoc/doc/cit_single.properties#L78

[sp614x]

Using models with CIT where the models themselves don't specify textures makes them default to using the vanilla item's texture and thus the CIT texture, which is a completely normal thing for resource packs to do and I don't understand why it's outputting error logs.

There is no fallback to vanilla texture for "builtin/generated" models without texture.
It kind of works if CIT specifies both a 3D model (json) and a 2D model (texture). In this case the 3D transform comes from the 3D model and the 2D model is used for rendering.
However for MC the 3D model is broken if it has no textures and it will be empty if used for rendering, this is why it complains.
The model loading is vanilla, it was reorganized in 1.21.4 and it behaves a bit differently now.

[sp614x]

In 1.21.4 shields are rendered as entities and can be configured via CEM.

[SeaOfPixels]

In 1.21.4 shields are rendered as entities and can be configured via CEM.

Converted shield models from JSON (CIT models) to JEM (CEM models) using blockbench, named them shield2/shield3/shield4 and put it in CEM folder, created shield.properties file and put it in CEM folder which contains the following:

models.2=2
name.2=regex:Accretion Disk|.*\\(Accretion Disk\\)|\\(Accretion Disk\\).*

models.3=3
name.3=regex:Acoustic Buckler|.*\\(Acoustic Buckler\\)|\\(Acoustic Buckler\\).*

models.4=4
name.4=regex:Admin Fred Shield|.*\\(Admin Fred Shield\\)|\\(Admin Fred Shield\\).*

This doesn't work. I also don't understand how you would make it work for blocking shields.

[sp614x]

Got the CIT shield model working:

The banner patterns don't match the custom model:

The blocking model is not working yet.

[SeaOfPixels]

Got the CIT shield model working:

What was I doing wrong in the above example? Could you send me your test pack for the vanguard shield that you got working so I can go off of that maybe?

The banner patterns don't match the custom model:

Will there be a way to fix/hide banner patterns?

The blocking model is not working yet.

Thanks for working through this with me, hoping the blocking model gets support in J3. Will CIT armor models be fixed, or do those also have to be done via CEM now? (I saw u were testing CIT armor models in the screenshots via molten netherite chestplate)

[sp614x]

Got the classic CIT shields working in an experimental version, current preview can't show them.
By default when using the CIT model the banner patterns are not rendered at all.
I could leave it like this and when the CIT model is active (2D or 3D) it would disable the banner patterns.
The blocking model would probably be fixed.

[sp614x]

Added nbt.Damage check as backwards compatibility (complains deprecated).
Damage can also be checked with damage=... and components.damage=....
Added broken elytra as variant texture.elytra_broken (coming in next preview).
Added variant textures for brush, spyglass and trident.

[SeaOfPixels]

CIT armor models and CIT shields confirmed fixed in pre10, however CIT items in the GUI are now rendered darker than they should be.

[SeaOfPixels]

CIT tridents are rendered backwards when charging a throw:

CIT tridents don't affect the thrown entity (do we HAVE to use CEM for this or will this be addressed to make it fully CIT-based?):

[sp614x]

Thrown tridents are entities (CEM), handheld and GUI tridents are items (CIT).
The handheld trident is special, the item is rendered with a renderer using an entity model (like shields).
Currently CEM can be used for the thrown trident. Base model for handheld one can be changed with CEM, but it can't be randomized yet.

[SeaOfPixels]

What is controling the first person charging position of CIT tridents? Is the first person charging position model able to be changed for CIT ones, like how the vanilla one has a separate changable item model for its first person charging position (trident_throwing)? Like how CIT shields have a model.shield_blocking parameter in their CIT properties, tridents need to have a model.trident_throwing parameter.

[sp614x]

In assets/minecraft/items/trident.json there is a conditional selector which changes between models item/trident_in_hand and item/trident_throwing.
CEM doesn't know about the conditional model, so it can't fix it currently.

[SeaOfPixels]

In my pack I'm using CIT for the handheld and GUI, and only using CEM for the thrown trident. I was suggesting there be a parameter in the CIT properties for model.trident_throwing, exactly how CIT shields have model.shield_blocking. I was not making any suggestions regarding CEM (unless I misunderstood your response). Since you previously stated that CIT tridents became possible due to vanilla changing them to be handled like shields, I assumed that a _throwing parameter would be possible in the same way the _blocking parameter is possible. Because without a separate model for the throwing position, you're effectively forced to mimic the vanilla trident's 1st person handheld position with all CIT tridents for it to not look terrible when charging a throw.

Looking at assets/minecraft/items/trident.json and comparing how it handles trident_throwing to how assets/minecraft/items/shield.json handles shield_blocking made me think that my model.trident_throwing inside CIT properties suggestion was possible, as they are written practically identically.