Sodium

Sodium

Mods
44M Downloads

Optimize some of vanilla's block models

muzikbike opened this issue ยท 8 comments

commented

Request Description

Several blocks in vanilla use models that are very unoptimized, using far more texture planes than are strictly needed to achieve said appearance. We can get a visually identical result using less planes - the recent fix for issues like #1316 should eliminate any subpixel discrepancies that would otherwise exist in vanilla.

However, I'm not sure if including these optimized models in Sodium would jeopardise their implementation into vanilla for licensing reasons.

Affected models:

The following fixes would also change texture mapping, which may be undesirable (even if vanilla's is wrong):

Hoppers (https://bugs.mojang.com/browse/MC-262452) would require unused pixels to be removed from the top texture (https://bugs.mojang.com/browse/MC-262454). In addition, optimizing flower pots may require redoing how the texture works entirely, which might be bad news for mods that add their own potted objects based on the vanilla model (https://bugs.mojang.com/browse/MC-262427).

commented

I've not looked into what's wrong with these block models specifically, but if the geometry can be optimized (both fewer vertices and fewer fragments rendered per model), and it would not impact how texture mapping works, then we can consider replacing the default block models.

commented

If we would be scared about jeopardising the implementation of said models into vanilla, what we can consider doing is to have a special file in any directories that these files are stored, that allows Mojang to be able to use these models (just make sure that it permits enough to Mojang because Microsoft wants more rights, seeing from the C418 situation how they dealt with things).

commented

Here's an example batch of optimized models. The following models were optimized by some combination of adding forgotten cullface arguments, merging coplanar quads with appropiate mapping, removing internal faces, removing zero-width faces, and so on:

  • Stairs (straight and inner corner)
  • Hoppers
  • Composters
  • Chorus flowers
  • Stacks of four turtle eggs
  • Cakes with candles
  • Anvils
  • Beacons
  • Item frames
  • Hanging mangrove propagules
  • Hanging lanterns

optimized-models.zip

Outwardly, these optimizations result in no visual differences. You should only see a difference if you clip inside of the models or into adjacent blocks, which for most of these is only possible in Spectator mode, and for the rest (item frames, propagules) nobody will notice the difference and if they do they won't care. In vanilla there are also tiny subpixel mapping differences caused by these changes, but the fixes for #1316/#1902 should make this even harder to see, if not outright impossible, and this is also something that nobody will end up noticing anyway.

The texture mapping should remain identical in all of these, from what I've checked - everyone is welcome to double-check. I've also made an effort to avoid coplanar intersecting quads, except in cases where they are purely internal (I believe this is only the case for the optimized chorus flower model).

Here's some performance comparisons with the optimized stairs model, hopper model and chorus flower model:

2024-05-12_14 30 56
2024-05-12_14 37 45
2024-05-12_15 24 43
2024-05-12_15 25 06
2024-05-12_20 55 23
2024-05-12_20 55 46

There's still a few other blocks which are to be optimized, particularly flower pots and cauldrons. There are also some entities which could be optimized via removing unneeded internal faces - would it make sense to create a separate ticket to track these? Another thing I think is worth asking is whether non-optimization model fixes would be in scope, such as fixing the misconfigured cullface for spawner blocks.

commented

I am fine with other people working on this, but some constraints must be met:

  • Texture mapping should behave identically with the optimized models. This means that resource packs which provide custom textures for these blocks should not look any different.
    • This also means we will not provide custom textures. The original textures must be compatible with any changes.
  • Reducing the amount of geometry is the highest priority, but we do not want to create excessive overdraw (overlapping geometry with transparent areas.)
  • The model files should be included as part of Sodium's mod resource pack, overlaying the original models.
commented

@jellysquid3 would we be making it so we won't jeopardise implementation of these models into vanilla?

commented

Given that there was a commit related to the previous snapshot on the linked PR last week it probably works on the latest versions.

commented

is there a version of this pack for 1.21 and/or programmer art?

commented

This should largely be resolved with d3aed21. If there are additional block models to be worked on in the future, please open another issue and/or pull request.