Transparent textures appear as opaque when using the OBJ model loader

[ultimateimmersion]

Bug Description

I have been trying to find solutions how to make alpha textures render correctly with obj and Sodium (NeoForge 1.21.1).
Everything else renders great except that. Previously I've been using Forge and Optifine since 1.16.5 and that returned no issues with same assets. I have a few screenshots here and tests I've been running to conclude it has something to do with Sodium.

Render type on blocks is "cutout_mipped"

NeoForge 1.21.1 only

JSON model, same texture map as the tree

NeoForge 1.21.1 + Sodium 0.6.0-beta

JSON model, same texture map as the tree

NeoForge 1.21.1+ Sodium 0.6.0-beta + Iris 1.8.0-beta + SEUS HRR 3

-------------- 1.20.1 Tests --------------

Forge 1.20.1 only

Forge 1.20.1 + Optifine H6

When shader is applied here, alpha is being rendered correctly

Reproduction Steps

It's a permanent bug

Log File

latest.log

Crash Report

No crash

[jellysquid3]

I'm frightened by the amount of geometry and overdraw in your screenshots.

[jellysquid3]

The problem with texture alpha being discarded was possibly introduced with #2666 and is a regression.

[jellysquid3]

Can you please attach a demonstration mod or resource pack which we can use for testing a bug fix?

[jellysquid3]

Regarding some of the screenshots where you show very large pieces of geometry being stretched across the world, this is a limitation of Sodium currently, as block models cannot extend more than 8 blocks outside of a chunk section without graphical corruption.

[ultimateimmersion]

Sure thing, here's the testing mod and resource pack for grass, fern and large tree mode. Keep in mind that for the sake of compressing this down to 25Mb to share here I had to remove other tree variations and this large tree is missing one mesh. It's random on placement so 1 in 4 will return a missing block.

ExperiArch Transparency Test.zip
experiarch-1.9-neoforge-1.21.1.zip

I tried changing the render type as for that thread you suggested but I didn't notice any differences in behaviour. These meshes are certainly pushing the limit of Minecraft but I compressed them down as much as I could initially and retain visual quality at the same time. But they were working fine since 1.16.5 like I mentioned.

Is the limit of mesh size going to be resolved in the future?

[jellysquid3]

Is the limit of mesh size going to be resolved in the future?

There are no plans right now. It might be increased to 32x32x32 blocks as a side effect of other work in the future, but that is not a design goal of the mod. Minecraft itself limits the models to no larger than 4x4x4 blocks, and the only way to get around this is with alternative model loaders (though, the game cannot properly calculate the light values for such large models.)

[jellysquid3]

I tried changing the render type as for that thread you suggested but I didn't notice any differences in behaviour.

Sodium 0.6 largely ignores the render type you assign, and tries to "downgrade" the render type if it determines the texture does not actually have alpha. But it will not "upgrade" the render type (either to enable alpha-testing or alpha-blending) for block models that didn't ask for it.

I'm pretty sure the bug that is affecting your mod exists in the render type downgrade logic.

[jellysquid3]

I've merged changes (a864415 and 267f84d) which address some of the issues your mod was provoking, mainly in regards to memory management.

The graphical bugs are still not resolved with these changes.

[ultimateimmersion]

I've merged changes (a864415 and 267f84d) which address some of the issues your mod was provoking, mainly in regards to memory management.

The graphical bugs are still not resolved with these changes.

Amazing thank you! I'm looking forward to the transparency fix.

As for the trees, my guess is they will remain broken like that until the block size is increased (quietly hoping that transparency fixes it unintentionally).

[jellysquid3]

I don't see any issue with Sodium's rendering of the transparent textures, at least when the blocks are on the correct render layer. Are you sure that you are configuring the model correctly?

The other issue described (geometry being corrupted when a block model is too large) will be made into a separate issue to avoid confusion.

[Altirix]

Your Resource pack doesnt seem to be defined correctly for the behaviour you want.

in grass_cluster_01.json you have:

{
  "parent": "neoforge:item/default",
  "loader": "neoforge:composite",
  "children": {
    "part1": {
      "loader": "neoforge:obj",
      "model": "experiarch:models/item/grass_cluster1.obj",
      "emissive_ambient": false,
      "textures": {
        "#grass_medium_01_sphere": "experiarch:block/green"
      }
    }
  },
  "textures": {
    "particle": "experiarch:block/green"
  },
  "render_type": "cutout_mipped"
}

the render_type should be with the child not the parent as you use neoforge:composite which seems to let you specify multiple parts that can be rendered as diffrent types. didnt look much into it tho so i could be wrong.

changing it to:

{
  "parent": "neoforge:item/default",
  "loader": "neoforge:composite",
  "children": {
    "part1": {
      "loader": "neoforge:obj",
      "render_type": "cutout_mipped",
      "model": "experiarch:models/item/grass_cluster1.obj",
      "emissive_ambient": false,
      "textures": {
        "#grass_medium_01_sphere": "experiarch:block/green"
      }
    }
  },
  "textures": {
    "particle": "experiarch:block/green"
  }
}

i suspect you dont need to use a composite loader here but youll probs want to so you can only use cutout_mipped on parts of the obj that need cutout_mipped it also looks like you may want to be resonable if you end up using translucent as overly complex geometry can cause the build time of a chunk to be much slower than vanilla. resonable usage of translucent shouldnt have any negatives however.

[ultimateimmersion]

Your Resource pack doesnt seem to be defined correctly for the behaviour you want.

in grass_cluster_01.json you have:

{
  "parent": "neoforge:item/default",
  "loader": "neoforge:composite",
  "children": {
    "part1": {
      "loader": "neoforge:obj",
      "model": "experiarch:models/item/grass_cluster1.obj",
      "emissive_ambient": false,
      "textures": {
        "#grass_medium_01_sphere": "experiarch:block/green"
      }
    }
  },
  "textures": {
    "particle": "experiarch:block/green"
  },
  "render_type": "cutout_mipped"
}

the render_type should be with the child not the parent as you use neoforge:composite which seems to let you specify multiple parts that can be rendered as diffrent types. didnt look much into it tho so i could be wrong.

changing it to:

{
  "parent": "neoforge:item/default",
  "loader": "neoforge:composite",
  "children": {
    "part1": {
      "loader": "neoforge:obj",
      "render_type": "cutout_mipped",
      "model": "experiarch:models/item/grass_cluster1.obj",
      "emissive_ambient": false,
      "textures": {
        "#grass_medium_01_sphere": "experiarch:block/green"
      }
    }
  },
  "textures": {
    "particle": "experiarch:block/green"
  }
}

i suspect you dont need to use a composite loader here but youll probs want to so you can only use cutout_mipped on parts of the obj that need cutout_mipped it also looks like you may want to be resonable if you end up using translucent as overly complex geometry can cause the build time of a chunk to be much slower than vanilla. resonable usage of translucent shouldnt have any negatives however.

Thanks a lot! Looks like there was a mistake in my script when it comes to transparency! This solves that problem.

[ultimateimmersion]

Is the limit of mesh size going to be resolved in the future?

There are no plans right now. It might be increased to 32x32x32 blocks as a side effect of other work in the future, but that is not a design goal of the mod. Minecraft itself limits the models to no larger than 4x4x4 blocks, and the only way to get around this is with alternative model loaders (though, the game cannot properly calculate the light values for such large models.)

I can confirm that the "melting vertices" are due to Sodium mesh size limitations. I tried scaling the tree mesh down and it rendered perfectly fine. What are the drawbacks of increasing the size limit? Does if affect performance in general?

Here's the screenshot: