Pink petal block models are not optimized
The 'flowerbed_#' block models used by the pink petals have several block faces that can never be seen by the player, potentially causing frame drops.
Linked Issues
relates to14
MC-267127Composter model is unoptimized, causing extra rendering lagConfirmedMC-250246Moving in mangrove swamps FPS/TPS drop below normal forests
NormalMC-262427Flower pots and potted objects have very poorly optimized models and strange texture mappingNormalMC-262452Hopper models are unoptimized and cause rendering lagNormalMC-262461Stair models are unoptimized and can cause rendering lagNormalMC-262470Cauldron models are very unoptimized, causing render lagNormalMC-262527Item frame models are quite unoptimizedNormalMC-262641Chorus flower models are incredibly unoptimized and cause serious rendering lagNormalMC-262689Hanging mangrove propagule models are comically unoptimizedNormalMC-262953Fence gate models are very unoptimized, causing lag among other issuesConfirmedMC-267281Fence multipart model system performance optimizationNormalMC-267315Rendering performance optimization for glass pane modelsNormalMC-267864Two-tall plant model/rendering not optimizedNormalMC-279350Leaf litter multipart model system is unoptimized, causing render lag
Low
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
Created Issue:
Pink petal block models are not optimized
The 'flowerbed_#' block models used by the pink petals have several block faces that can never be seen by the player, potentially causing frame drops.
Attachments3
pink_petal_fix.zip
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
relates to
![[Mojang] Moesh](../../../data/avatars/users/10122.svg){kind=small}
Normal![[Mojang] Georgii Gavrichev](../../../data/avatars/users/22428.png){kind=small}
[Mojang] Georgii Gavrichev![[Bot] Piston](../../../data/avatars/users/31202.png){kind=small}
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
relates to
relates to
relates to
relates to
relates to
relates to
relates to
The bug
The specifications for hanging propagules are several times larger than they need to be.
Many of the model elements of hanging propagules are flat planes, meaning that only two sides of said elements are ever visible (e.g. top and bottom). However, the model files define faces for all six sides of these planes as if they were full cuboids, despite the fact that due to being planes, four of these "sides" have zero area and are mathematically impossible to see. Despite being invisible in practice, the game tries to render these anyway, causing a bunch of render lag we really don't need (and may be in part responsible for MC-250246).
If we modify the propagule models to delete these unwanted faces, we can see a noticeable uptick in framerate in regions containing large amounts of mangrove propagules, while not changing how they look in the slightest.
As it is in vanilla, hanging mangrove propagules of ages 2, 3 and 4 are the most complex block models in the game, beating even vanilla cauldrons. We can more than half the amount of faces that every type of propagule needs, though, without changing anything visual about them at all. To be specific:
- Age 0 propagules use 42 faces, but only need 18
- Age 1 propagules use 48 faces, but only need 22
- Age 2, 3 and 4 propagules use 60 faces (two more than the cauldron at 58 - see MC-262470), but only need 26
I believe MC-260296 was the exact same issue as this (zero-width faces), but with pink petals, and was fixed promptly while this still remains an issue.
How to reproduce
(Note: Due to MC-118624, we cannot create a superflat world to demonstrate this issue like with other optimization tickets I've made.)
- Download the attached resource pack
- Go to a region of your creative world you don't care about (you can use a default superflat world for this to cut out any unwanted FPS lag sources)
- Execute this command:
/fill ~-50 ~1 ~-50 ~50 ~1 ~50 minecraft:mangrove_leaves[persistent=true] - Repeat the command, replacing both cases of "~1" with "~3", "~5", ... up to some odd number you're happy with
- Without moving, now execute the following command:
/fill ~-50 ~0 ~-50 ~50 ~0 ~50 minecraft:mangrove_propagule[age=4,hanging=true] - Repeat this command as well, replacing both "~0" instances with even numbers until you're one lower than the odd number you previously stopped at
- Use Spectator mode to fly out of this mess, then go to one of the corners of this infernal mangrove lasagna you've created and switch back to Creative mode
- Point the player camera at this preposterous pile of propagule plywood
- Set your render distance to 4 chunks
- Open the FPS meter by using F3+2
- Observe how it performs with the vanilla resources versus with the attached propagule fix resource pack
Expected results
Acceptable framerates.
Actual results
A client lagfest.
How to fix
This should be a very easy fix. The resource pack attached contains complete fixes for all five affected mangrove propagule models, so it should be as easy as just replacing the five vanilla hanging propagule models with those in the resource pack. I've also deleted some redundant lines from the model files which rotate elements by 0 degrees, which is identical to doing nothing.
As I've said many times before (do I even need to say this anyway?), Mojang have my full permission to use all of these model files to fix this issue, and are strongly encouraged to do so. Everyone wants the game to perform better, and this is just one way we can make that happen.
Relates to: MC-260296 MC-262427 MC-262452 MC-262461 MC-262470 MC-262527 MC-262641 MC-262652 MC-262689 MC-262953 MC-267127 MC-267315 MC-267864 MC-279350
The bug
The current multipart system for walls can use more quads than are necessary to achieve an identical visual result. Making Minecraft render more quads increases render lag, so decreasing the amount needed will improve performance.
The case in question is much the same as MC-267281, arising where two opposite connections of a wall are either both "low" or both "tall". Minecraft, by default, will render one model in each direction, with a total of two. However, the exact same visual outcome can be achieved using a single, continuous model, reducing the amount of quads used for this case from 10 to 6. Since there are no texture mapping issues on walls (unlike MC-109478 and MC-225819/MC-267871), this fix also completely preserves their appearance, so we get no bonus fixes.
How to reproduce
- Create this superflat world:
minecraft:barrier;minecraft:the_void
- Initiate flying mode
/fill -30 -63 -30 30 -56 30 cobblestone_wall
/fill -30 -55 -30 30 -48 30 cobblestone_wall
/tp @s 0 0 0 0 90
- Compare framerates with and without the attached resource pack using F3+2
Expected results
Vanilla's framerates would be ideal.
Actual results
The resource pack gives better results.
How to fix
Adopt the system demonstrated by this resource pack for walls. I give Mojang full permission to use this resource pack to fix this optimization problem.
Relates to: MC-260296 MC-262427 MC-262452 MC-262461 MC-262470 MC-262527 MC-262641 MC-262652 MC-262689 MC-262953 MC-267127 MC-267281 MC-267315 MC-267864 MC-279350 MC-279354
The bug
Bamboo fences, like other fence types (see MC-267281), are not modelled in a way which is optimal for rendering performances. As a result, areas which use large amounts of bamboo fences will decrease framerate much more than otherwise should be the case.
Bamboo fences use a fundamentally different system for modelling compared to other fences, which is why I'm reporting this separately from the other fences. Tragically the issues with the normal fence model have carried over to the system used for bamboo fences.
The model system bamboo fences use is also more complicated than is neccessary - it uses four models for orthogonal connections, whereas this optimized system achieves a visually identical outcome using just three.
Note that since bamboo models use a unique texture rather than just copying the bamboo planks texture, the texture mapping will need to be shifted around. A modified version is found within the attached resource pack - the visual outcome will be identical, but existing resource packs will need to be changed by their authors to fit around it (assuming they don't take the lazy route and just copy over the old, terrible models).
How to reproduce
- Create a creative Superflat world with the following preset:
minecraft:barrier;minecraft:the_void
- Enter flying mode by double pressing the jump button
- Run the command
/tp @s 0 -20 0 0 90
- Run the command
/fill -30 -63 -30 30 -56 30 bamboo_fence
- Open the performance graphs via F3+2
- Switch between the default resources and the attached resource pack, comparing the performance
Expected results
Good framerates in vanilla.
Actual results
We can do far better.
How to fix
Simply implement the resources in the attached resource pack into vanilla. I give Mojang my full permission and encouragement to use these files to make vanilla Minecraft run better.
Further notes
Mipmapping will be affected, however this is a non-issue.
The bamboo fence item model is also updated to fit the new system.
Many of the old model files can be safely deleted once the new ones are added, as this improved system renders them completely superseded.
For me, the performance gain was much less noticeable, bit it was still a difference of around 5-10 FPS (tested it on a grass platform on a Cherry Grove single biome world, but there were less pink petals).
Relates to MC-262427,
MC-262433, MC-262452, MC-262461, MC-262470, MC-262527, MC-262641 andMC-252693.