Renderer API's vanilla adapter doesn't work with all multipart/weighted models
Chocohead opened this issue ยท 2 comments
From BakedModel implementing FabricBakedModel, all vanilla models will return true for FabricBakedModel#isVanillaAdapter. For most models this is fine, but for a multipart or weighted model where one of the components would otherwise return false this can cause problems from the component completely not supporting being rendered the vanilla way:
Example crash
In this particular example, this is from trying to render Ignis Fatuus's carved pumpkin, made up of both vanilla and non-vanilla components
java.lang.NullPointerException: Tesselating block model
at java.util.ArrayList.addAll(Unknown Source)
at net.minecraft.class_1095.method_4707(class_1095.java:67)
at net.minecraft.class_778.renderModelSmooth(class_778.java:143)
at net.minecraft.class_778.renderModel(class_778.java:101)
at net.minecraft.class_776.renderModel(class_776.java:83)
at net.minecraft.class_776.method_3355(class_776.java:74)
at net.minecraft.class_846$class_851$class_4578.redirect$zbc000$hookChunkBuildTesselate(class_846.java:715)
at net.minecraft.class_846$class_851$class_4578.method_22785(class_846.java:891)
at net.minecraft.class_846$class_851$class_4578.method_22783(class_846.java:718)
at net.minecraft.class_846.method_22757(class_846.java:182)
at java.util.concurrent.CompletableFuture.uniComposeStage(Unknown Source)
at java.util.concurrent.CompletableFuture.thenCompose(Unknown Source)
at net.minecraft.class_846.method_22763(class_846.java:180)
at net.minecraft.class_846.method_23086(class_846.java:254)
at net.minecraft.class_3846.method_16907(class_3846.java:94)
at net.minecraft.class_3846.method_16900(class_3846.java:137)
at net.minecraft.class_3846.run(class_3846.java:105)
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(Unknown Source)
at java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source)
at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Thread: Render thread
Stacktrace:
at java.util.ArrayList.addAll(Unknown Source)
at net.minecraft.class_1095.method_4707(class_1095.java:67)
at net.minecraft.class_778.renderModelSmooth(class_778.java:143)
-- Block model being tesselated --
Details:
Block: Block{ignis-fatuus:carved_pumpkin_block}[facing=north,lid=false,torch=false]
Block location: World: (-201,67,-220), Chunk: (at 7,4,4 in -13,-14; contains blocks -208,0,-224 to -193,255,-209), Region: (-1,-1; contains chunks -32,-32 to -1,-1, blocks -512,0,-512 to -1,255,-1)
Using AO: true
Model class: net.minecraft.class_1095
Is Fabric model: true
Is adapted vanilla model: true
Stacktrace:
at net.minecraft.class_778.renderModel(class_778.java:101)
-- Block being tesselated --
Details:
Block: Block{ignis-fatuus:carved_pumpkin_block}[facing=north,lid=false,torch=false]
Block location: World: (-201,67,-220), Chunk: (at 7,4,4 in -13,-14; contains blocks -208,0,-224 to -193,255,-209), Region: (-1,-1; contains chunks -32,-32 to -1,-1, blocks -512,0,-512 to -1,255,-1)
Block render type: MODEL
Stacktrace:
at net.minecraft.class_776.renderModel(class_776.java:83)
at net.minecraft.class_776.method_3355(class_776.java:74)
This does seem to have been noticed and handled within JMX (here and here), but it might be nice if the rendering API itself would do it to avoid the otherwise quite unclear crashes from this edge case.
Creator of said mod, I JiJ'd jmx to avoid an issue where multipart models in normal indigo would call getQuads