Lag on first frame rendering Tinkers' Construct tools

[mczph]

Tested environment (all latest)

When mixin.dynamic_resources=true

[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/pickaxe.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/shovel.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/hatchet.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/mattock.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/kama.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/hammer.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/excavator.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/lumberaxe.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/scythe.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/broadsword.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/longsword.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/rapier.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/frypan.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/battlesign.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/cleaver.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/shortbow.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/longbow.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/arrow.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/crossbow.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/bolt.tcon#inventory
[16:50:34] [Client thread/ERROR] [tconstruct-API]: Could not load multimodel tconstruct:tools/shuriken.tcon#inventory
[16:50:35] [Client thread/ERROR] [tconstruct-API]: Could not load material model tconstruct:parts/tough_tool_rod.tmat#inventory
[16:50:35] [Client thread/ERROR] [tconstruct-API]: Could not load material model tconstruct:parts/scythe_head.tmat#inventory
[16:50:35] [Client thread/ERROR] [tconstruct-API]: Could not load material model tconstruct:parts/tough_binding.tmat#inventory
[16:50:35] [Client thread/ERROR] [tconstruct-API]: Could not load material model tconstruct:parts/broad_axe_head.tmat#inventory
[16:50:35] [Client thread/ERROR] [tconstruct-API]: Could not load material model tconstruct:parts/large_plate.tmat#inventory
[16:50:36] [Client thread/ERROR] [tconstruct-API]: Could not load material model tconstruct:parts/tool_rod.tmat#inventory
[16:50:36] [Client thread/ERROR] [tconstruct-API]: Could not load material model tconstruct:parts/shovel_head.tmat#inventory
[16:50:36] [Client thread/ERROR] [tconstruct-API]: Could not load material model tconstruct:parts/binding.tmat#inventory
[16:50:37] [Client thread/ERROR] [tconstruct-API]: Could not load material model tconstruct:parts/pick_head.tmat#inventory

mixin.dynamic_resources=false (Just like when you don't have this mod installed)

This has little effect in normal environments, but in large modpacks, it will cause a few seconds of freeze every time the Tool Forge GUI is opened

[jchung01]

Sorry if this isn't quite related to the issue, but you can see similar issues while searching through HEI. There aren't any texture issues in HEI anymore as far as I can tell. However, when HEI needs to render tinker's tools, depending on how many it needs to render, you can experience brief moments of freezing and the same types of errors are printed. I would assume it's because tinker's uses item model overrides and those aren't pre-baked by the dynamic resources functionality?

[embeddedt]

Most likely.

[mczph]

Sorry if this isn't quite related to the issue, but you can see similar issues while searching through HEI. There aren't any texture issues in HEI anymore as far as I can tell. However, when HEI needs to render tinker's tools, depending on how many it needs to render, you can experience brief moments of freezing and the same types of errors are printed. I would assume it's because tinker's uses item model overrides and those aren't pre-baked by the dynamic resources functionality?

I also encountered this problem

[Krutoy242]

The issue is still actual and i would really appreciate fix!

[embeddedt]

I assume most people experiencing this issue have CensoredASM installed. Does it help to disable releaseSpriteFramesCache in its config?

[Krutoy242]

I assume most people experiencing this issue have CensoredASM installed. Does it help to disable releaseSpriteFramesCache in its config?

For the test, i set releaseSpriteFramesCache=false, reloaded game and opened Tool Forge - still freeze for few seconds, as without config change.

[Keaft]

I can also confirm that disabling releaseSpriteFramesCache through FermiumASM (ultimately a fork of CensoredASM) and Binkers Bonstruct does not reduce freezing from this error.

Interestingly, reverting back to FoamFix removes the errors, but I'm still getting freezes slightly less, but still severe. The freezing on VintageFix is much longer.

There are a significant amount of errors, the last of them in this log are related to the issue (with more detail) as I click through all the item pages on HEI. There is a crash that'll list all the mods a little ways up from the bottom. None of the errors restrict continuing to play. latest.log

If you'd like an environment that'll generate this consistently, let me know!

SlimeKnights/TinkersConstruct#3651 suggests this may be a long standing issue?

Edit: As referenced in my latest.log above:

net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model tconstruct:fluid_block#uranium with loader VariantLoader.INSTANCE
    at org.embeddedt.vintagefix.dynamicresources.model.DynamicModelProvider.loadModel(DynamicModelProvider.java:208) ~[DynamicModelProvider.class:?]
etc
etc
etc...
Caused by: java.lang.NullPointerException
    at net.minecraftforge.client.model.ModelLoader$MultipartModel.<init>(ModelLoader.java:1212) ~[ModelLoader$MultipartModel.class:?]
    at net.minecraftforge.client.model.ModelLoader$VariantLoader.loadModel(ModelLoader.java:1345) ~[ModelLoader$VariantLoader.class:?]
    at org.embeddedt.vintagefix.dynamicresources.model.DynamicModelProvider.loadModel(DynamicModelProvider.java:206) ~[DynamicModelProvider.class:?]

I set VintageFix's mixin.dynamic_resources to false and it's freezing behavior now mimics that of FoamFix where it's still severe, but not nearly as severe.

[embeddedt]

In the latest beta I have applied many optimizations to both the Forge model baking pipeline and Tinkers itself. Please try it and let me know if the lag spike is less severe. (Please also let me know if the optimizations cause any models to render incorrectly compared to before.)

https://nightly.link/embeddedt/VintageFix/workflows/gradle/main/Package.zip

[mczph]

@embeddedt I got a crash when updating to the latest build https://mclo.gs/on4tGKH

[embeddedt]

Can you provide the full log please?

[embeddedt]

Update: got a full log from another user with the same crash, and pushed a fix.

[Keaft]

Can confirm! Extraordinarily more manageable even with FermiumASM and Binkers Bonstruct. I wouldn't describe it as freezing at all, but minor hitching. latest.log

I'll keep my eye out for any model rendering issues.

Edit: I'm genuinely uncertain which changes that I've made have caused this, but Chisels and Bits are now exhibiting the same freezing behavior. I updated VintageFix to 0.4.2, then disabled it in curseforge and re-downloaded the above Package.zip. Oddly enough chisels and bits are set to not even show up in my JEI(HEI) list, but they are anyway, which might be more of an incompatibility with HEI. I'll keep testing to see if I can provide more clarity.

Edit 2: Switching back to JEI removes the Chisels and Bits from JEI as intended which also removes the vintage errors regarding the model rendering. This would suggest that if Chisels and Bits were not hidden, the errors would persist. I still don't understand what the circumstances were that caused the game to be as smooth as it was when I originally posted this post. The log in this post does show VintageFix installed with the above package and still shows some errors, but I don't recall freezing. As far as Tinkers I don't see any freezing when scrolling past it's items.

[mczph]

@embeddedt The latest version does fix the crash problem, but the lags when opening the tool forge does not seem to be fixed... I have also checked @Keaft log and found the same [tconstruct-API]: Could not load multimodel warnings

[embeddedt]

The Could not load multimodel warning is not related to VintageFix; it also appears with Tinkers by itself, as far as I know.

[mczph]

The Could not load multimodel warning is not related to VintageFix; it also appears with Tinkers by itself, as far as I know.

So what does the latest update actually fix?

[embeddedt]

Item model loading in Forge & Tinkers was optimized to be faster.

[jchung01]

Tested the newest build, here's some spark results. Using /sparkc profiler --only-ticks-over 50.

With CensoredASM releaseSpriteFramesCache=true, on first opening of tool forge: Before - https://spark.lucko.me/kRxT2OFN8M?hl=62,67,63 After - https://spark.lucko.me/knV4T6hv0a?hl=377,385 So packed quad, tool quad coloring, and cached CustomTextureCreator optimizations do seem to help. From the spark report's indication of TextureAtlasSprite#getFrameCount(), releaseSpriteFramesCache does take a significant amount of time, so here are spark reports with them disabled.

With CensoredASM releaseSpriteFramesCache=false, on first opening of tool forge: Before - https://spark.lucko.me/lKkbo1Ou1M?hl=68 After - https://spark.lucko.me/EtDdeHyKKp?hl=259 So there is a noticeable delay when opening the tool forge, but I think it's better than before. Judging from the spark report, I guess the remaining slowdown is due to net.minecraftforge.client.model.ItemLayerModel$FaceData.get()/set()? This delay did seem to vary though when repeatedly testing between restarts.

Also, I would say in this minimal environment of Tinkers, CensoredASM, HEI, and VintageFix, I can no longer notice a slowdown when scrolling through the tinkers' materials and tools in HEI.

[embeddedt]

I pushed some more minor improvements, but I don't know that they will be enough to suppress the delay.

[jchung01]

Just tested the new build, yeah it does seem roughly the same as when I tested in my previous post. I think the delay is pretty negligible though as long as CensoredASM's releaseSpriteFramesCache=false. Others can test it to see for themselves.

[embeddedt]

Is this still severe enough as of 0.5.0 to warrant further investigation, or can it be closed?

[Krutoy242]

Current lag is very insignificant and can be considered as fix. Thank you for the improvments!

https://github.com/embeddedt/VintageFix/assets/936618/010bc58f-1936-4f67-aba6-5663f2265de7