Barriers and light blocks produce multiple particles instead of one per block
I definitely remember this being mentioned somewhere, but searching the bug tracker produced no results.
The bug
Barriers and light blocks, rather than showing a single particle at their position, tend to show many coincident particles. This results in no visual difference (it may with translucent textures however I am yet to test this), as the particles are all rendered as perfectly coinciding with each other. With enough of the blocks present, this may result in significant lag, given that the game has to render easily around ten times as many particles as there are blocks for no real reason.
How to reproduce
- Enter an area with no sources of particles near the player, such as a superflat world. Wait until the P parameter in the debug screen reaches 0 if need be.
- Place down a single barrier or light block
- Notice how, as the particles pop into view, the P value doesn't stop at 1
Expected result
Only one particle would be generated for each barrier or light block, resulting in a P of 1
Actual result
P instead fluctuates at higher values, rendering up to 15 particles for just a single block at times
How to fix
The fix would be to make only one particle render for each block at a time. However, this may be difficult to do given how other particle-emitting blocks behave. It may be better to switch to a non-particle-based system for rendering blocks. Using a non-particle-based system would have the potential to fix several other issues with their rendering as well, such as MC-47660 (not appearing or disappearing immediately), MC-47607 and MC-221558 (not appearing at all with a low Particles graphics setting), and possibly allow for customizability and bring parity depending on how it is fixed.
This could be to render wireframe cubes at their positions instead (like how save structure blocks with Show Invisible Blocks enabled display them).
Alternatively, the blocks could be made to use models for when made visible instead. This would allow for more customizability as the models and textures associated with the blocks would be fully customizable, and would also be somewhat of a parity fix as this would bring Java Edition more in line with how Bedrock Edition handles structure voids. The cubes shown by structure blocks could also be changed to use models as well, potentially fixing rendering bugs such as MC-225940. An example resource pack may be attached in the future.
Created Issue:
Barriers and light blocks produce multiple particles instead of one per block
I definitely remember this being mentioned somewhere, but searching the bug tracker produced no results.
The bug
Barriers and light blocks, rather than showing a single particle at their position, tend to show many coincident particles. This results in no visual difference (it may with translucent textures however I am yet to test this), as the particles are all rendered as perfectly coinciding with each other. With enough of the blocks present, this may result in significant lag, given that the game has to render easily around ten times as many particles as there are blocks for no real reason.
How to reproduce
- Enter an area with no sources of particles near the player, such as a superflat world. Wait until the P parameter in the debug screen reaches 0 if need be.
- Place down a single barrier or light block
- Notice how, as the particles pop into view, the P value doesn't stop at 1
Expected result
Only one particle would be generated for each barrier or light block, resulting in a P of 1
Actual result
P instead fluctuates at higher values, rendering up to 15 particles for just a single block at times
How to fix
The fix would be to make only one particle render for each block at a time. However, this may be difficult to do given how other particle-emitting blocks behave. It may be better to switch to a non-particle-based system for rendering blocks. Using a non-particle-based system would have the potential to fix several other issues with their rendering as well, such as MC-47660 (not appearing or disappearing immediately),
MC-47607andMC-221558(not appearing at all with a low Particles graphics setting), and possibly allow for customizability and bring parity depending on how it is fixed.This could be to render wireframe cubes at their positions instead (like how save structure blocks with Show Invisible Blocks enabled display them).
Alternatively, the blocks could be made to use models for when made visible instead. This would allow for more customizability as the models and textures associated with the blocks would be fully customizable, and would also be somewhat of a parity fix as this would bring Java Edition more in line with how Bedrock Edition handles structure voids. The cubes shown by structure blocks could also be changed to use models as well, potentially fixing rendering bugs such as MC-225940. An example resource pack may be attached in the future.
The bug
When switching the intensity of the light block, the texture displayed will overlap with its previous version.
This bug is a direct product of MC-47660, as since the particles do not immediately disappear, they are allowed to coincide like this. MC-238261, which is considered Won't Fix (but in light of this is probabyl worth reopening), may also be considered partially at fault as more than one texture is allowed to coincide as a result.
How to reproduce
- Obtain a light block: /give @s light
- Place down the light block and wait for it to show itself via the particle
- Right click on the light block in order to change its light level
Overlapping textures are shown, giving a nonsensical result
Expected result
Right clicking would change the texture to the actual light level, and that only
Actual result
Overlapping occurs, which causes an ugly and hard to read combination of particles to appear
How to fix
According to JellySquid in the Sodium discord, it is not possible for a block to test for the existence of a particle in a given area, and as such the game simply spawns the particles randomly, giving rise to this bug, MC-47660 and MC-238261. It may be advisable to ditch the particle approach entirely (although maybe keeping block_marker for mapmaking purposes), and use an alternate method of revealing these blocks when held.
Solution 1
The ability for blocks to check for the existence of particles could be added. With this, particle could be made to appear and disappear immediately depending on the held item, and for only a single particle to be able to exist per block. This would match Bedrock Edition's behaviour.
Solution 2
Light blocks and barriers could be made to render the same way all invisible blocks do when structure blocks are set to display invisible blocks. Light blocks could possibly be distinguished by using darker shades of yellow for lower light levels.
Solution 3
Models. My personal favorite solution, listed in MC-238261 but will be rewritten and improved here.




Can confirm.