Opacity

This article is about see-through block textures, models, and lighting. For similar concepts, see Transparency.

Opacity (and its inverse, transparency) are properties of blocks which affect how the game renders it and other nearby blocks, as well as how occlusion culling is handled.

Properties

The primary purpose of opacity is to tell the game engine if it needs to render other blocks behind that block; an opaque block completely obscures the view behind it, while a transparent block does not. Therefore, transparency applies not only to solid blocks like ice and glass, but also to blocks like cacti, stairs, chests, and single slabs, which are not considered full blocks. By this definition, transparency does not imply that a block is actually see-through, which is a quality of the item texture specified by the game or resource pack.

In Bedrock Edition, most transparent blocks become opaque when located far away from the player. This is especially noticeable when looking long distances with the spyglass. The distance at which blocks become opaque is proportional to the render distance.

Water that is completely surrounded by water or opaque blocks does not have a current. However, if one of the surrounding blocks is transparent, the water shows a downward current on its side, like a waterfall, although swim speed through that water remains unchanged.

Opacity is independent of redstone conductivity and spawnability for full blocks, although they often coincide. A slime block is an example of this independence: a slime block is partially light-transparent and has a see-through texture, but still conducts redstone power and allows mob spawning on top.

Lighting

Opacity also affects how light propagates through the world. Opaque blocks completely prevent light from traveling through them, while transparent blocks generally diminish the light by one light level per block (these values can be overridden however, and there are several exceptions).

The growth of grass blocks is linked to the amount of light in the blocks directly above them. A grass block can be killed by placing an opaque or partially transparent block above it.

Some transparent blocks can reduce or block light, according to type:

• Glass and carpets do not reduce the light passing through them, i.e. there is no additional modifier. In other words, light passes through them as if it were air.
• Lava is set to completely block light propagation.‌^{[Bedrock Edition only]} This is often unnoticeable since lava has the maximum light level of 15, but can be observed in cases where lava blocks skylight propagation.
• Water, ice, leaves, slime blocks, honey blocks, and cobwebs do not have any extra effect on block light, but they do diffuse sky light.
  • In Bedrock Edition, water and ice have a -1 modifier to light propagation, on top of the normal decrease of 1 per block.
  • The light level from sunlight or moonlight is the same in each block of air in the column of air above the highest obstruction in the column. When placed, water, ice, leaves, slime blocks, honey blocks, and cobwebs obstruct that light column so that the lowest air block above the leaves acts as other light sources do.
• Sunlight is attenuated by leaves and each vertical layer of leaf blocks attenuates the light further.

Types of transparent blocks

Occlusion shape

The occlusion shape determines whether or not a block prevents the propagation of light and the rendering of adjacent faces of other blocks, among other functions.

Most blocks have their occlusion shape identical to their interaction box or an empty occlusion shape. A block has an empty occlusion shape if it doesn't have a collision box^{[note 1]} or if it is explicitly defined not to have a occlusion.

The list below shows all blocks defined as noOcclusion in Java Edition:

However, there are blocks that, even though they have a non-empty occlusion shape, have an occlusion shape that differs from their interaction box. The table below shows all the exceptions in Java Edition:^{[note 2]}

Block	Occlusion shape	Interaction box	Notes
Fences	4×16×4 Additionally, for all sides set to true: Facing east/west: 6×9×2 Facing north/south: 2×9×6	4×16×4 Additionally, for all sides set to true: Facing east/west: 6×16×4 Facing north/south: 4×16×6	Centered on the block's center. The additional boxes for sides set to true face the respective direction. For the occlusion shape, the additional boxes's top are 1px below the top of the block.
Fence Gates	Two boxes 2×11×2 Each box is adjacent to opposite vertical faces of the block. If facing is east/west: The boxes are centralized on the Y-axis. If facing is north/south: The boxes are centralized on the X-axis.	Not in wall, facing is east/west: 16×16×4 Not in wall, facing is north/south: 4×16×16 In wall, facing is east/west: 16×13×4 In wall, facing is north/south: 4×13×16	If in_wall is false: The boxes's top are at the top of the block. If in_wall is true: The boxes's top are 3px below the top of the block.
Lectern	Identical to its collision box, that is: 16×2×16, with an 8x12x8 column above	The collision box plus two 16x4x4.333333 boxs and a 16x4x4.333334 box.	The additional blocks of the interaction box are positioned diagonally, approaching the visual model. They are also rotated according to the facing.
Sculk Shrieker	16×8×16	Full block (16×16×16)	The occlusion shape is identical to collision box

If a block's occlusion shape is a full block, it is considered a solid render block.

Propagation of light

When a block has a light level greater than one, it attempts to propagate the light in all six directions. If successful, the light is propagated to the adjacent block and with one less level.

However, there are two situations that can prevent light propagation between blocks:

• Case the block through which the light is trying to propagate is a solid render block or tinted glass.

• Case, when joining the adjacent faces of the blocks, considering their occlusion shape, forms a full square.

For example, a top slab does not propagate light to a horizontally adjacent bottom slab. Because, by joining the adjacent faces of its occlusion shape, that is, the top 8×16 with the bottom 8×16, it forms a full square.

However, not all blocks use their shape to prevent light propagation; in reality, only a select list of blocks uses their occlusion shape for this purpose. All other blocks are considered to have an empty occlusion shape when it comes to light propagation.

The list below shows all blocks that can use their shape for light occlusion in Java Edition:

Considering solid render blocks with an empty occlusion shape is important for the functioning of light emitters. If, for example, glowstone considered its shape, it could never propagate light to other blocks. This would occur because each of its faces is already a complete square, and when joined with a face of any other block (even if it is empty) would generate a full square. Therefore, solid render blocks do not receive light (due to the first condition at the beginning of the session) but can still emit light (due it to be considered with an empty occlusion shape).

Some blocks that use their shape for light occlusion are also light emitters, from example the enchanting table. Unlike solid render blocks, these can obstruct their own emitted light. This could be a total obstruction on one face (e.g., the enchanting table does not emit its light from the face below) or a partial obstruction on one face (e.g., the enchanting table does not emit its light to a horizontally adjacent top slab).

This behavior works for both block light and sky light propagated between blocks. For light emitted directly from the sky onto the block, the behavior is slightly different. The game creates a column of blocks with level 15 sky light starting from the top of the world and extending to the tallest block that satisfies at least one of the conditions below:

• The block below has a full block interaction box or is a chorus plant, and is not in list below:

• The block below to be in a fluid (including waterlogged blocks), and is not a copper grate.

• Its bottom face joined with the top face of the block below form a full square. Again, considering only the shape of some blocks, the same ones from propagation between blocks.

Blocks above and below the dimension's building limit are considered air. If there are no blocks blocking the skylight, it can continue through the void.

Block face rendering

To improve game performance, Minecraft does not render all block faces. Block faces that are completely hidden by the face of the adjacent block do not need to be rendered, and rendering them will result in a performance loss without any gain.

The occlusion shape is used to determine when one face of a block is hiding the face of another. If face A of one block is adjacent to face B of another block, and when comparing the shape of each face, considering the occlusion shape of each block, cas the face A is full^{[note 3]} or if face B is not empty and there is no point that is only on face B (in other words: if the non-empty face B is contained in the face A), then face B is not rendered.

This is the only time in the game when the occlusion format of all blocks is actually used. For light rendering, only blocks with a full block occlusion shape (solid render blocks) and blocks from a select list are used. In other uses, only the fact that a block is or is not a solid render block is used.

However, there are certain non-occluded blocks that sometimes do not render the face of the adjacent block. This often occurs when there are transparent blocks next to the same transparent block. For example, in a glass cuboid, only the sides are rendered, preventing many glass faces from being visible within the cuboid, which would be visible due to the transparency of the glass and would break the continuity of the cuboid.

Stained glass also prevents the rendering of identical blocks next to it. However, it must be the same block type (same block id); for example, a green stained glass does not prevent the yellow stained glass next to it from rendering its face. Below is a list of all blocks that prevent the rendering of the blocks next to them, if and only if they are of the same block type.

Mangrove roots does not render other magoves rootes that are directly above or below it. However, it still renders those that are next to it.

Iron bars, copper bars, glass pane and stained glass pane don't render the face of adjacent blocks of the same type. Furthermore, these blocks will not render the faces of adjacent blocks if both the block itself and the adjacent block are within the #bars block tag. In vanilla, only the iron bar and (all) copper bars are in this tag, however, using data packs it is possible to add the glass pane and stained glass pane.

When "Options" → "Accessibility Settings" → "See-Through Leaves" is not enabled, leaves don't render other leaves, even if they are of different types.

Water and lava normally don't render block faces that are in the same fluid. Because the rendering of fluid is more complex, sometimes the faces are rendered. For example, a waterlogged top slab will still have its upper face rendered if there is a block of water on top of it.

Cullfaces

In Java Edition, the parts of the block that may not render because it is adjacent to a certain block depends on the block's model. More specifically, the face <face> of the nth block model's element does not render if there is a block preventing rendering in direction defined by elements[n].faces.<face>.cullface. However, there are blocks that are not rendered by models but rather by the associated block entity. These are:

These entity blocks has not a cullface, with the exception of the end gateway. For more details, see non-model-dependent block elements.

Most block models do not render the elements' faces that are on the block face. An exception is the beacon, which renders the glass shell^{[note 4]}.​

Videos

Issues

Issues relating to "Opacity" or "Transparency" are maintained on the bug tracker. Issues should be reported and viewed there.

Trivia

• In the Nether, the spawn point is always on top of an opaque block. This can be seen if the player used a respawn anchor to set their spawn in the Nether.
• If an opaque block is given transparent pixels in an edited texture, then instead of showing the block behind it through the transparent part, it simply fills in the area with white. However, currently X-ray texture packs could be created using the blocks custom models feature.^[1]

See also

• Liquid

Notes

References