Temperamental 'Tesselating Block In World' Crash

[Anemony22]

Hi all,

Since upgrading to 1.18 (but also before that in a few other versions) I've occasionally run into a crash where the game will try to load, and then as soon as it tries to load one of my custom model blocks in the world it will crash, providing the error:

Tesselating block in world - Indigo Renderer

The frustrating part is that the crash is a little bit different every time, and I'm not well enough acquainted with the MC render system to understand the underlying issue.

Crash log 1:
https://zerobin.net/?5f350b2e0da1d0f4#4IcmUkNmLtTEtN4enxYguYVOcFNIkP8oi6zkrzE3HAc=

Crash log 2:
https://zerobin.net/?5ec1c0e75b934018#XcikG57lMk6dG9S6BjoizhJbJEfntc/62w1LRYLc8bk=

The crash always seems to revolve around my DynamicCuboid class that I made to make emitting quads a bit easier and less manual. Since upgrading to1.18 it didn't work at all and crashed every time, but I reinstalled java and switched JDKs a few times, and now it seems to be working again. Now it works with every JDK, however it always scares me a bit when a bug fixes itself suddenly because that means it could break itself again just as suddenly - thought I'd raise the issue here in case I'm missing something obvious to someone else!

Here is the DynamicCuboid file, although the rest of the code is public too.

Thanks!
Anemony

EDIT
It's stopped working again completely. Mostly getting this error now:

Description: Tesselating block in world - Indigo Renderer

java.lang.NullPointerException: Cannot invoke "net.minecraft.util.math.Direction.getId()" because the return value of "net.fabricmc.fabric.api.renderer.v1.mesh.MutableQuadView.nominalFace()" is null

[warjort]

This sounds similar to this bug report?
#1871

I can't say for sure, I know little about MC rendering and Indigo even less.

[Anemony22]

Possibly, although I'm working with BlockEntity NBT data rather than blockstates. Are there any workarounds? It seems this issue has gotten much worse since 1.18

[oliviathevampire]

I’m getting kind of the same crashes but not related to my mod, but other mods, like something is null all of a sudden without changing anything

[PepperCode1]

The first crash seems to be caused by some sort of mismatch in the data length and stored index. There are checks in place to ensure this does not happen, but it looks like it did anyway.
The second crash makes no sense because the nominalFace() result is null-checked before being used. Storing it in a local variable would probably fix it, but I also have no idea how this happens in the first place.

After looking at your code more closely, I am 99% sure both of these are the result of concurrency issues that your models experience. You are sharing a Collection<DynamicCuboid> across a single model, which is rendered on multiple threads at once. A single cuboid is then modified across those threads, resulting in unexpected results like these crashes. Use a ThreadLocal to make sure any data that needs to be modified is always localized to a single thread.

[Anemony22]

Oo okay interesting. I suspected it would be something like that - weird communication issues between the client and the server. I know the client NBT system changed this update.

Do you have any advice on how to implement the Threading system? I haven't touched that area or Minecraft (or Java) yet.

[PepperCode1]

This is not a client server communication issue and neither does it have anything to do with NBT. Models are always strictly client-only. The only advice I have is to look at ThreadLocal because there isn't one general threading system that all models can use and it all works on a case-by-case basis - either there are concurrency issues, or there aren't. However, you can look at the models of other rendering mods.

[Anemony22]

Thanks for clarifying. I'll look into it!

[Anemony22]

I've attempted adding a ThreadLocal to the Collection<DynamicCuboid> like you suggested, although the issue still persists. If I've done it wrong please let me know, but otherwise looking through the crash logs it seems like it's not the collection interaction that's breaking, but instead the creation of the models for each side:

CarvedWoodModel 160-181:

// Carved side north
int northSideCount = 0;
for (int y = 13; y >= 1; y -= 2) {
    for (int x = 13; x >= 1; x -= 2) {
        int carveState = ((CarvedWoodEntity) entity).getFaceArray(Direction.NORTH)[northSideCount];

        // Where a state of 1 means carved - do not render anything
        if (carveState != 1) {
            DynamicCuboid cuboid;

            cuboid = new DynamicCuboid(x, y, 0, 2, 2, 1);
            // 2 means highlighted
            if (carveState == 2) {
                cuboid.setSideOverlay(Direction.NORTH, 0x2bff95);
            }

            cuboid.applyTextureToAll(new SpriteIdentifier(SpriteAtlasTexture.BLOCK_ATLAS_TEXTURE, new Identifier(log)));
            cuboid.create(emitter, textureGetter); // HERE is where the crash is happening.
        }
        northSideCount++;
    }
}

This code has nothing to do with the collection, as a new DynamicCuboid object is created and used immediately. Surely this would be done on the same thread? Or do I need to make the DynamicCuboid object itself more thread-safe?

[PepperCode1]

CarvedStencilModel.builder, .emitter, and the same fields in CarvedWoodModel should be ThreadLocal as well, although there is no point in storing the emitter separately as it can be gotten from the builder. Adding something like private static final ThreadLocal MESH_BUILDER = ThreadLocal.withInitial(() -> RendererAccess.INSTANCE.getRenderer().meshBuilder()); to both model classes instead of the current fields should work.