Optimize some of vanilla's block models #2460
Comments
muzikbike
added
S-needs-triage
|
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). |
|
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. |
jellysquid3
added
S-accepted
|
I am fine with other people working on this, but some constraints must be met:
|
|
@jellysquid3 would we be making it so we won't jeopardise implementation of these models into vanilla? |
|
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:
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:
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. |
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).
The text was updated successfully, but these errors were encountered: