I've discovered an issue with the itemcache in the AbstractCTMBakedModel. Currently I'm using an item which has a custom ItemMeshDefinition defined which differentiates textures based on NBT data. The itemcache only differentiates textures based on item and metadata.

The case I'm having is that all items with the same item class and metadata have the same texture. When putting one separate in a chest and waiting 10 seconds (chest not opened) the cache clears and the correct texture shows up when opening the chest. However if two "same" items are in the chest, they both have the same texture.

The textures work perfectly without CTM.

If anything is unclear, please ask (I'm also in the Discord, same username).

@tterrag, this is also the last bit of functionality we need to completely integrate Mekanism with CTM.

Yea, the BakedModel isn't something that would work, the MRL which is used to get the BakedModel is something cache worthy, but I don't think it's accessible without a lot of issues/"hacks".

This is a problem I had considered before, but a fix isn't trivial. I could just put the NBT tag into the cache key, sure, but comparisons on large tags are very expensive, not to mention that some items may change NBT with no effect on the model.

An idea could be caching the ModelResourceLocation of the texture?

@tterrag1098, all access to the item cache is done within handleItemState() which has access to the ItemStack being rendered. If you're worried about items without changes between NBT states, add some kind of interface that can be implemented in an Item class with a method like isNBTSpecific(), and only hash the item's NBT tag for the cache if so.

Hashing an NBT state shouldn't require too much overhead. Regardless, it should be up to the implementing mod authors to make sure their items' NBT states are not too large.

How exactly do you look up a ModelResourceLocation for a stack?

I'm clueless about that, just a random suggestion that popped up as the only thing that an ItemMeshDefinition does is setting its MRL. It's called every time it's being rendered so I guess somewhere in the CTM it calls getModelLocation(ItemStack).

I'll start a debugger to check where it's called from

Hmm.. That might be hard to get. You need an instance of ItemModelMesher somehow. That has a way to get the MRL from a ItemStack with getItemModel(ItemStack) which returns an IBakedModel.

--EDIT--
Hmm.. That might be hard to get. You need an instance of ItemModelMesher somehow. That has a way to get the MRL from a ItemStack with getItemModel(ItemStack) which returns an IBakedModel.

@aidancbrady Any solution should be code-free, as it must be usable by resource packs.

I support this notion of NBT-sensitivity myself.

@thommy101 Minecraft.getMinecraft().getRenderItem().getItemModelMesher() but that doesn't solve the issue. IBakedModel isn't a cache key.

Fixed via aef71f3 and 74b0066