Projection 360 skyboxes are not rendered

[Baplar]

Summary

Despite having managed to solve the issue of other skybox types (#515) and applying the same fixes to the Projection 360 ones, it still renders completely grey.

Steps / context

1. Visit Interdimensional Zen
2. The sky is grey

Expected / actual

Expected: Projection 360 skyboxes should render properly.

Actual: They do not render at all, leaving us to stare at the grey clear color.

Logs / attachments

I have added a bunch of logs before each early return in renderide::passes::world_mesh_forward::skybox::prepare_material_skybox, and it seems that when in a world with a projection skybox, it exits early due to store.shader_asset_for_material(material_id) failing to resolve the skybox’s material.

2026-05-20_23-36-08.log

I have also edited the shader itself to force it to return bright colors, and it had absolutely no effect, which leads me to believe that the shader is not used at all:

diff --git a/crates/renderide/shaders/passes/backend/skybox_projection360.wgsl b/crates/renderide/shaders/passes/backend/skybox_projection360.wgsl
index 80eaa581..6b39660d 100644
--- a/crates/renderide/shaders/passes/backend/skybox_projection360.wgsl
+++ b/crates/renderide/shaders/passes/backend/skybox_projection360.wgsl
@@ -140,5 +140,7 @@ fn fs_main(in: VertexOutput) -> @location(0) vec4<f32> {
         _SecondCube,
         _SecondCube_sampler,
     );
-    return rg::retain_globals_additive(p360m::finish_skybox_color(c, params));
+    let result = p360m::finish_skybox_color(c, params);
+    let c2 = min(result + vec4<f32>((ndc + 1.0) / 2.0, 1.0, 0.0), vec4<f32>(1.0));
+    return rg::retain_globals_additive(c2);
 }

[Baplar]

I figured it out!
Changing the value of ZTest on the material to GreaterOrEqual or Equal in Resonite (which corresponds to Equal and LessOrEqual) fixes it, whereas it fails to render with LessOrEqual (which corresponds to Less).

It seems that there’s something at Z=0 that’s winning the Z-fight against the skybox.
Moving the clip_pos from Z=0 to Z=1e-10 fixes it, but that’s a very inelegant solution. I’d rather figure out what is the cause of the Z-fighting failure.

[DoubleStyx]

Should be fixed now with #515.