MC-118624Superflat presets can't use blockstates
The bug
When the block data values were removed, and fully replaced with block states, the ability to set the block state on superflat worlds was lost. You used to be able to set the data value in the preset.
This preset is expected to work and place top slabs, but it doesn't.
minecraft:stone_slab[type=top];minecraft:the_void;decoration
No format actually exists anymore to set block states in the superflat preset.
This goes for both the world generation menu, and custom dimensions.
Linked Issues
Attachments1
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Created Issue:
Superflat presets dont use blockstates.
Superflat presets dont use blockstates but use the deprecated Id system.
This seemed like something that was forgotten to be changed.The presets I tried:
3;minecraft:bedrock,2*minecraft:stone:variant=diorite;1;village3;minecraft:bedrock,2*minecraft:stone[variant=diorite];1;village3;minecraft:bedrock,2*minecraft:stone:[variant=diorite];1;village3;minecraft:bedrock,2*minecraft:stone(variant=diorite);1;village3;minecraft:bedrock,2*minecraft:stone:(variant=diorite);1;village3;minecraft:bedrock,2*minecraft:stone{variant=diorite};1;village3;minecraft:bedrock,2*minecraft:stone:{variant=diorite};1;villageNone of those actually counted as a preset and were reset to the classic flat preset.
Environment
java 1.8.0_131 SE
windows 10 pro
Superflat presetsdont use blockstates.Superflat presets can't use blockstates.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Superflat presets can't use blockstates.
java 1.8.0_131 SE
windows 10 pro
Superflat presets dont use blockstates but use the deprecated Id system.
This seemed like something that was forgotten to be changed.The presets I tried:
3;minecraft:bedrock,2*minecraft:stone:variant=diorite;1;village3;minecraft:bedrock,2*minecraft:stone[variant=diorite];1;village3;minecraft:bedrock,2*minecraft:stone:[variant=diorite];1;village3;minecraft:bedrock,2*minecraft:stone(variant=diorite);1;village3;minecraft:bedrock,2*minecraft:stone:(variant=diorite);1;village3;minecraft:bedrock,2*minecraft:stone{variant=diorite};1;village3;minecraft:bedrock,2*minecraft:stone:{variant=diorite};1;villageNone of those actually counted as a preset and were reset to the classic flat preset.
The bug
Superflat presets don't use blockstates but use the deprecated Id system. This seemed like something that was forgotten to be changed.
The presets I tried:
3;minecraft:bedrock,2*minecraft:stone:variant=diorite;1;village3;minecraft:bedrock,2*minecraft:stone[variant=diorite];1;village3;minecraft:bedrock,2*minecraft:stone:[variant=diorite];1;village3;minecraft:bedrock,2*minecraft:stone(variant=diorite);1;village3;minecraft:bedrock,2*minecraft:stone:(variant=diorite);1;village3;minecraft:bedrock,2*minecraft:stone{variant=diorite};1;village3;minecraft:bedrock,2*minecraft:stone:{variant=diorite};1;villageNone of those actually counted as a preset and were reset to the classic flat preset.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
The bug
Superflat presets don't use blockstates but use the deprecated Id system. This seemed like something that was forgotten to be changed.
The presets I tried:
3;minecraft:bedrock,2*minecraft:stone:variant=diorite;1;village3;minecraft:bedrock,2*minecraft:stone[variant=diorite];1;village3;minecraft:bedrock,2*minecraft:stone:[variant=diorite];1;village3;minecraft:bedrock,2*minecraft:stone(variant=diorite);1;village3;minecraft:bedrock,2*minecraft:stone:(variant=diorite);1;village3;minecraft:bedrock,2*minecraft:stone{variant=diorite};1;village3;minecraft:bedrock,2*minecraft:stone:{variant=diorite};1;villageNone of those actually counted as a preset and were reset to the classic flat preset.
The bug
Superflat presets don't use blockstates but use the deprecated Id system. This seemed like something that was forgotten to be changed.
The presets I tried:
minecraft:stone_slab:type=top;minecraft:the_void;decorationminecraft:stone_slab[type=top];minecraft:the_void;decorationminecraft:stone_slab:[type=top];minecraft:the_void;decorationminecraft:stone_slab(type=top);minecraft:the_void;decorationminecraft:stone_slab:(type=top);minecraft:the_void;decorationminecraft:stone_slab{type=top};minecraft:the_void;decorationminecraft:stone_slab:{type=top};minecraft:the_void;decorationNone of those actually counted as a preset and were reset to the classic flat preset.
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
The blockstates was before numbers (has worked) and after the convert the blockstate names don't work. Is that really a feature request?
![[Mod] LateLag](../../../data/avatars/users/92884.png){kind=small}
![[Mojang] Maxime Lebrot](../../../data/avatars/users/18941.svg){kind=small}
Normal![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
The bug
Superflat presets don't use blockstates but use the deprecated Id system. This seemed like something that was forgotten to be changed.
The presets I tried:
minecraft:stone_slab:type=top;minecraft:the_void;decorationminecraft:stone_slab[type=top];minecraft:the_void;decorationminecraft:stone_slab:[type=top];minecraft:the_void;decorationminecraft:stone_slab(type=top);minecraft:the_void;decorationminecraft:stone_slab:(type=top);minecraft:the_void;decorationminecraft:stone_slab{type=top};minecraft:the_void;decorationminecraft:stone_slab:{type=top};minecraft:the_void;decorationNone of those actually counted as a preset and were reset to the classic flat preset.
It is expected that the second line works, as that format is consistent with commands.
The bug
Superflat presets don't useblockstatesbut use thedeprecated Id system. This seemed like something that was forgotten to be changed.The presets I tried:
minecraft:stone_slab:type=top;minecraft:the_void;decorationminecraft:stone_slab[type=top];minecraft:the_void;decorationminecraft:stone_slab:[type=top];minecraft:the_void;decorationminecraft:stone_slab(type=top);minecraft:the_void;decorationminecraft:stone_slab:(type=top);minecraft:the_void;decorationminecraft:stone_slab{type=top};minecraft:the_void;decorationminecraft:stone_slab:{type=top};minecraft:the_void;decorationNo
ne of those actually counted as a preset and were reset to the classicflat preset.
It is expected that the second line works, as that format is consistent with commands.The bug
When the block data values were removed, and fully replaced with block states, the ability to set the block state on superflat worlds was lost. You used to be able to set the data value in the preset.
This preset is expected to work and place top slabs, but it doesn't.
minecraft:stone_slab[type=top];minecraft:the_void;decorationNo format actually exists anymore to set block states in the superflat preset.
This goes for both the world generation menu, and custom dimensions.
![[Mod] Jarl-Penguin](../../../data/avatars/users/92849.png){kind=small}
Cannot reproduce this in 20w07a also due to MC-118624.
The general solution proposed here to ignore unknown properties and log them might not actually be that good.
This issue can no longer be reproduced due to the resolution of MC-118624.
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.
The bug
Two-block-tall plants such as tall grass and tall flowers can be optimized such that they take less of a toll on the game's rendering engine and increase game performance.
Currently, the bottom half and top half are both separate block models, meaning that each full plant takes up eight texture planes. However, we can cut this in half and render the same plant using four texture planes, considerably increasing performance. This involves redoing textures such that each plant uses a single 16×32 texture rather than two 16×16 textures.
While this results in a considerable performance increase, I don't like this nearly as much as the other model optimizations I've done due to it causing the particles of these blocks to become distorted, potentially affecting how the blocks look with respect to lighting, and also violating the paradigm that every block texture must be a 16×16 square by default, among other reasons. As such, the attached demo resource pack only applies this to five of seven potential target plants (leaving out pitcher plants and sunflowers). If Mojang is still interested in implementing this optimization, I can extend it to these two plants as well if desired.
How to reproduce
As MC-118624 remains unfixed for some reason, we will need to set up our test environment manually.
- Create a superflat world with the preset
minecraft:bedrock,2*minecraft:dirt,minecraft:grass_block;minecraft:the_void
- Execute the command
/tp @s 0 -60 0
- Execute the command
/fill ~-90 ~ ~-90 ~90 ~ ~90 minecraft:tall_grass[half=lower]
- Execute the command
/fill ~-90 ~1 ~-90 ~90 ~1 ~90 minecraft:tall_grass[half=upper]
- Execute the command
/tp @s 0 0 0 0 90
- Set your render distance and simulation distance to five chunks
- Open the performance graphs with F3+2
- Observe with and without the attached resource pack
Expected results
Good framerates in vanilla.
Actual results
Not necessarily. The resource pack improves things considerably.
The bug
The way in which leaf litter blockstates is wasteful; more planes are used than are actually needed to achieve said visual result.
The current system works as follows: each of the four segments is its own model. For only one piece of leaf litter in a block, this is already optimal, however this becomes wasteful when we increase the amount:
- two pieces of leaf litter can easily be done using an 8x16 pixel flat plane rather than two 8x8 planes. This brings the number of faces from 4 to 2.
- three pieces can be done with the aforementioned 8x16 plane alongside the currently used 8x8 plane, rather than three 8x8 planes. This brings the number of faces from 6 to 4.
- four pieces can be very easily done using just one flat plane covering the entire block face. This brings the number of faces from 8 to 2.
As leaf litter is very common in forested biomes, we should be aiming to reduce its rendering performance impact.
How to reproduce
As MC-118624 still remains unfixed, we will need to set up our test environment manually.
- Create this superflat world:
minecraft:grass_block;minecraft:the_void
- Run these commands:
/fill -90 -63 -90 90 -63 90 minecraft:leaf_litter[segment_amount=4]
,
/fill -90 -62 -90 90 -62 90 minecraft:grass_block
,
/fill -90 -61 -90 90 -61 90 minecraft:leaf_litter[segment_amount=4]
,
/fill -90 -60 -90 90 -60 90 minecraft:grass_block
,
/fill -90 -59 -90 90 -59 90 minecraft:leaf_litter[segment_amount=4]
,
/fill -90 -58 -90 90 -58 90 minecraft:grass_block
,
/fill -90 -57 -90 90 -57 90 minecraft:leaf_litter[segment_amount=4]
,
/fill -90 -56 -90 90 -56 90 minecraft:grass_block
,
/fill -90 -55 -90 90 -55 90 minecraft:leaf_litter[segment_amount=4]
- Enter flying mode and run the command
/tp @s 0 100 0 0 90
- Compare framerates with and without the attached resource pack using F3+2
Expected results
Ideal framerates in vanilla.
Actual results
The resource pack demonstrates that there is indeed room for improvement.
How to fix
Use this system for leaf litter models, rather than vanilla's current approach. I give Mojang full permission to use and implement the attached assets.
Further notes
I have considerably upgraded my PC setup since the last model optimization report, so you'll be seeing less of a performance boost in the attached screenshots compared to previously, but there is definitely an improvement.
Can confirm for MC 1.12.1.
Confirmed for 1.13.1.
Confirmed for 1.16.3
Seems to affect 20w49a
I can also confirm the issue happening on 20w49a - when trying to make pistons facing up via flatworld preset, no matter what I try, the preset gets reset to default one.
Confirmed on 1.16.5
Can confirm in 21w07a.
Can confirm in 21w11a.
This is a feature request.
@[Mojang] Adrian Östergard
In earlier versions, you could specify block states with numbers.
Example:
minecraft:stained_glass:11
Here was "11" the metadata (today block state)
And here a old video at 3:54 you can see that meta datas/ block states was a thing:
https://www.youtube.com/watch?v=yoLzUirxNcw
I wouldn't consider this a feature request. There are some blocks that generate naturally with various blockstates such as logs, dripleaf or dripstone (see image above), and then a lot of blocks can be waterlogged. Not allowing those means you can't generate the worlds properly.
Reopened; reasoning is valid.
Can confirm in 1.20.1 with the params provided.
The second line is the syntax that's expected to work (it matches commands), so when fixing this, please use that syntax.
Affects 1.21. I'd like to request ownership of this report, as it has an inactive owner that can no longer maintain it.
Can confirm in 24w34a.