Starfield

Starfield is a unique graphical effect used for rendering certain features related to the End.

Starfield effects are used for the following:

• 👁 Image
  End portal
• 👁 Image
  End gateway
• Endermen holding End portals or End gateways^{[verify for Bedrock Edition]}
• Minecarts with custom-displayed End portal or End gateway blocks^{[verify for Bedrock Edition]}
• Lit TNT entities set to display as End portals or End gateways^{[verify for Bedrock Edition]}
• Block display entities set to display as End portals or End gateways‌^{[Java Edition only]}
• Background in the credit sequence, End poem, and loading screen when entering or leaving the End‌^{[Java Edition only]}
• Items using the end_cube special model type in a resource pack‌^{[Java Edition only]}

Falling block entities of the End portal and End gateway do not render the starfield effect, and it seems highly unlikely (although unproven) that moving piston blocks would either.^[1]

The rendering of the starfield effect has changed several times throughout the game's history.

There are two subtly different gateway effects, referred to by the end_cube special model type as portal (used for end portal blocks, the dimension loading screens for entering and exiting the End, and the credits sequence and preceding poem) and gateway, used specifically for end gateways. The latter renders an extra layer of blue pixels which are absent from the former, which can be seen by placing the two blocks next to each other; blue pixels will disappear when they migrate to the space where the end portal is present. See later in this section for a technical explanation of the difference.

Two different texture files are utilised in generating the starfield effect:

The "End sky" texture, which is indeed the same texture used for the actual End sky, is used as the "background" texture: it is sampled using screen-projected coordinates and multiplied by
 #06191C. The shader uses the projected screen-space y-coordinate directly as the vertical texture coordinate; because the screen-projected vertical coordinate increases upwards while the texture image is displayed with its vertical axis running downwards, the background texture appears vertically mirrored.

The "End portal" texture is sampled in multiple layers on top of this background. Each layer uses a different colour multiplier, scale, rotation, fixed horizontal offset, and time-based vertical offset. In the fragment shader, the RGB results of the layers are combined additively before the final colour is output with full opacity. The End portal uses 15 layers of the "End portal" texture, while the End gateway uses 16 layers. The first 15 layers are shared between both effects, while the End gateway has an additional layer using
 #1550A9.

The colour values used by the layers are as follows. Index 0 is also used for the "End sky" background, but the velocity listed for index 0 applies only to the first layer of the "End portal" texture. The End portal uses indices 0 through 14, while the End gateway uses indices 0 through 15. The Velocity column gives the rate at which the time-based vertical offset increases. In the current Windows behaviour, this is also the apparent downward velocity of the layer. In the pre-25w07a behaviour, where the apparent travel direction follows each layer's rotation, the same listed velocity is transformed by the layer's rotation and scale.

For the nth layer, where n starts at 1 and equals the table index plus 1, the horizontal offset is ¹⁷⁄_n, the rotation angle is (n×n×4321+n×9)×2 degrees,​^{[more information needed]} and the scale is (4.5-ⁿ⁄₄)×2. The vertical offset is (2+ⁿ⁄_1.5)×(GameTime×1.5). Since GameTime increases by ¹⁄₂₄₀₀₀ per game tick, the Velocity value listed in the table is ⁽³⁺ⁿ⁾⁄₂₄₀₀₀. In unaffected rendering behaviour, the Rotation value gives the apparent travel direction, while the apparent travel velocity is the listed Velocity divided by the listed Scale.

On some AMD Windows systems, the layers appear to move vertically downwards instead of following the directions listed in the table. This behaviour is unintentional. On some,sustems, only OpenGL exhibits this behaviour, whereas the Vulkan renderer does not, although on other systems both are affected. It does not affect OpenGL on macOS, Linux, or when using Nvidia graphics hardware.^[2]

The starfield effect is completely constant regardless of view: while moving and rotating the camera will change the position of the object using the starfield effect itself on screen, the starfield itself will remain fixed in place. In effect, anything using the starfield effect effectively creates what can be seen as a "hole" in the world, behind which the starfield rests. The shape of the starfield also changes with the window size, although this is presumably not intentional.^[3]

The starfield effect in Bedrock Edition is rendered using a layered parallax system.

For end portals, the effect consists of 17 overlapping horizontal quadrilateral layers with identical positions, dimensions, and depths. Each layer covers the full horizontal area of a block and consists of 2 triangles.

For end gateways, the effect consists of 17 overlapping layers with identical positions, dimensions, and depths. Each cube layer occupies a full block space and consists of 6 faces and 12 triangles.

In both effects, one layer forms an opaque base layer, while the remaining 16 render the pixels making up the starfield. The geometry of the 17 layers overlaps exactly within each effect; the depth and parallax of the starfield are produced by the different texture coordinates and layer parameters used by each layer.

Two different texture files are utilised in generating the effect:

The end_portal.png texture supplies the starfield pattern, while the end_portal_colors.png texture supplies the colours used by the individual starfield layers. Both textures use nearest-neighbour filtering and wrap addressing on both texture-coordinate axes, so coordinates outside the texture range continue sampling from the opposite side.

The opaque base layer has a layer parameter of 1. In this case, the pixel shader enters the base-layer branch and generates the output colour from the current fog colour and fog factor. At positions unaffected by fog, the fog factor is 0, causing the layer to appear black; as the fog factor increases, the colour of the base layer approaches the fog colour of the scene.

The remaining 16 layers render the starfield pixels and are indexed from 0 through 15. Their layer parameters are ²³⁹⁄₂₅₅, ²²³⁄₂₅₅, and ²⁰⁷⁄₂₅₅, decreasing by ¹⁶⁄₂₅₅ for each subsequent layer until ¹⁵⁄₂₅₅ at index 14; the layer parameter at index 15 is 0.

Each starfield layer has a fixed set of colour texture coordinates. The 16 coordinate pairs form a 4x4 grid, with both coordinates successively taking the values ⁹⁄₁₆, ¹¹⁄₁₆, ¹³⁄₁₆, and ¹⁵⁄₁₆. With nearest-neighbour filtering, these coordinates fall within the bottom-right 2x2-pixel region of the colour texture, so four colours are used,^[verify] each by four starfield layers.

The parameters used by the starfield layers are as follows. The Rotation column gives the exact angle in radians, reduced to the range from 0 to 2π:

For a starfield layer with a layer parameter of p, the virtual depth is 32p, the rotation angle of the texture coordinates is 32p×^5π⁄₇ radians, and the layer brightness is 1-p.

The RGB components of the vertex colour encode the direction of the current block face, while the alpha component stores the layer parameter. The vertex shader uses the vertex position, block-face direction, viewpoint position, and virtual depth to calculate the position projected from the viewpoint onto a virtual sampling plane. The actual geometry of all 17 layers overlaps exactly, but the virtual sampling planes corresponding to the layers lie at different depths, producing multiple levels of parallax as the camera moves.

The virtual sampling position is then converted into two-dimensional coordinates according to the direction of the block face and scaled to ¹⁄₁₆ of its original size. The coordinates are rotated by the rotation angle of the layer, then offset by 32p in the same direction. The time value supplied by the renderer is divided by 256 and added to the second texture coordinate, causing the starfield pattern to move continuously. All layers use the same time increment, while their different rotation angles and virtual depths produce different apparent directions of travel and degrees of parallax.

The time value supplied by the renderer increases in seconds, so the time offset increases by ¹⁄₂₅₆ of a texture-coordinate unit per second. The parallax texture uses wrap addressing; with the camera position and other rendering parameters kept unchanged, the starfield animation returns to the same texture phase every 256 seconds.

The output colour of an ordinary starfield layer is obtained by multiplying the colour texture, parallax texture, layer brightness, and fog attenuation component-wise. If the layer parameter is p and the fog factor is f, the colour of the layer is the component-wise product of the colour texture, the parallax texture, 1-p, and 1-f.

The blend state causes the base layer to replace the existing colour in the framebuffer, after which the 16 starfield layers are added successively. Different graphics backends may use different output alpha values and destination blend factors to produce the same colour-compositing result.

The effect uses depth testing and depth writing, with the depth comparison function set to less than or equal. As all 17 layers of each effect use the same geometry and depth, each layer can pass the test at equal depth and take part in the final composition.

From 15w33a^[verify] to 21w08b, the starfield effect was defined in the game's code. 21w10a introduced resource-pack-configurable core shaders, with the shader file rendertype_end_portal containing the starfield's definition.

Before

The background layer, rather than being a fixed background, was treated much more similarly to the starfield particle layers on top of it; it was scaled, tessellated, and would move over time.

Rather than being explicitly defined, the set of colours used were generated using a fixed numeric seed (31100).​^{[more information needed]} The same set of colours were generated on every session. End portals and end gateways used different colour multipliers.​^{[more information needed]}

After

​^{[more information needed]}

Comparison

For a 128×128 end_sky.png which is completely white in the center, and has a one-pixel-thick red border around the edges, we get the following results (recolored to the input texture) for a 1024×1024 window:

• 👁 15w33a to 21w08b[note 2]
  
  15w33a to 21w08b^{[note 2]}
• 👁 21w10a to present
  
  21w10a to present