Babylon.js glow and trail render over the Sun: rendering groups vs depth handling for transparent effects

Babylon.js glow and trail render over the Sun: rendering groups vs depth handling for transparent effects

TL;DR

Your current setup works for a reason, and it is not really the group numbers. Rendering groups only decide the coarse draw order between groups; they do not give you occlusion. The occlusion comes from the depth buffer: the Sun is opaque, so it writes depth, and a transparent effect that keeps depth testing on but depth writing off will be correctly hidden when it passes behind the Sun even if it draws later in a higher group. The recommended shape is opaque objects first in a low group, transparent paths and effects in higher groups with depth write off and depth test on, and reserve group changes for ordering between transparent layers themselves.

Verbatim report

Cinematic scene: a hero object flies past the Sun, with planets and orbital paths
behind. The mesh should become a glowing point with a luminous trail. Changing
rendering groups made elements appear either behind the orbital paths or
incorrectly in front of the Sun. Current setup, paths in group 1 and the hero,
its glow and trail, and the Sun in group 2, works after trial and error.
Question: is this the recommended approach, and what should I watch for?

Steps

1. Put every opaque object (Sun, planets, the hero mesh itself) in the default group 0 and leave their materials alone. Success check: opaque objects occlude each other correctly from every camera angle with no group changes at all, because opaque rendering writes depth.
2. Move the transparent orbital paths to group 1 and set their material to not write depth (disableDepthWrite on the material, or setDepthWrite(false) on the mesh). Success check: the paths are hidden behind the Sun and planets, and visible through empty space, from both sides of the scene.
3. Move the hero glow and trail to group 2, also with depth writing off and depth testing left on. Success check: the glow draws over the paths (later group, drawn later among transparent objects) but is clipped by the Sun when the hero passes behind it, because the Sun already wrote depth in group 0 and the glow still tests against it.
4. If two transparent effects overlap each other, order those with the group or with per-mesh alpha index within the same group; transparent objects in one group sort back to front by distance, which flips as the camera moves. Success check: orbiting the camera does not swap which effect appears in front unless the group order says it should.
5. Watch the two classic traps. One: a transparent material with depth writing left on will punch holes in effects drawn after it. Two: an object marked to always render on top (or a group used to force a HUD-style overlay) will ignore the Sun no matter what the depth settings say. Success check: neither effect is set to render as an overlay, and every transparent material in the scene has depth writing off.

When this applies

• A scene mixing opaque occluders with transparent glows, trails, paths, or atmosphere shells.
• Transparent objects that must pass both in front of one thing and behind another.
• Draw-order bugs that change when the camera moves (a sorting symptom, not a group symptom).

When this does not apply

• The GlowLayer post-process itself (that is a separate blur and merge pipeline, not mesh draw order).
• Sorting many particles inside one particle system.
• GUI or sprite overlays that should genuinely ignore the 3D scene.

Why it happens

Babylon draws in two passes. Opaque objects render first, sorted front to back, and write depth. Transparent objects render afterwards, sorted back to front within their rendering group, and groups render in ascending order. Because a higher group always draws after a lower one, group order between two transparent objects is absolute and ignores distance. Occlusion of a transparent object by an opaque one survives anyway, because the opaque pass already filled the depth buffer and the transparent pass tests against it by default. Most trial-and-error pain comes from changing groups to fix what is really a depth-write problem on one material.

Edge cases

• Putting the Sun itself in the transparent hero group is unnecessary and risky; if the Sun ever gets a transparent atmosphere shell, that shell belongs in the transparent groups while the Sun mesh stays opaque in group 0.
• Trails built from ribbon meshes can self-sort badly at glancing angles; splitting the trail or accepting the artefact is a known trade-off, groups will not fix intra-mesh sorting.
• If the glow must also be hidden by a planet, the same rule covers it: planet opaque in group 0, glow testing depth, done.

Provenance

Resolved from the public thread: https://forum.babylonjs.com/t/rendering-groups-and-depth-handling-with-transparent-effects-best-practice/64325

Public thread by Tilleby on the Babylon.js forum (Questions), 0 replies at survey time on 2026-10-16: a cinematic scene where a hero object with a glowing point and luminous trail must render in front of orbital paths but disappear behind the Sun; putting paths in rendering group 1 and the hero, glow, trail, and Sun in group 2 works after trial and error, and the poster asks whether this is the recommended approach and what to watch for. Source: https://forum.babylonjs.com/t/rendering-groups-and-depth-handling-with-transparent-effects-best-practice/64325