ShaderLoadUtil.getShaderSource() ignores the Identifier's namespace, so any mod's custom RenderPipeline with shaders in its own jar fails to compile (breaks Litematica schematic rendering)

[GreenSurge]

Summary

Any mod that registers its own RenderPipeline pointing at shaders bundled in that mod's own jar fails silently under VulkanMod, because ShaderLoadUtil's shader source lookup only ever searches inside VulkanMod's own jar and discards the Identifier's namespace when building the file path. This affects malilib's custom terrain pipelines (used by Litematica for schematic rendering), and presumably any other mod doing the same normal, spec-compliant thing with the RenderPipeline API.

Reproduction

1. Install Fabric 1.21.11 + VulkanMod + malilib + Litematica.
2. Load into a world with a schematic loaded in Litematica.
3. Schematic renders blank, invisible, or with wrong/garbage coloring instead of the expected ghost-block overlay. Disabling VulkanMod (falling back to the vanilla renderer) fixes it immediately.

Root cause

net.vulkanmod.render.shader.ShaderLoadUtil:

public static final String RESOURCES_PATH =
    SpirvCompiler.class.getResource("/assets/vulkanmod").toExternalForm();
...
public static String getShaderSource(Identifier resourceLocation, ShaderType type) {
    String path = resourceLocation.getPath();   // namespace discarded here
    String[] splitPath = splitPath(path);
    String shaderName = "%s%s".formatted(splitPath[1], shaderExtension);
    String shaderFile = "%s/shaders/%s/%s".formatted(RESOURCES_PATH, path, shaderName);
    // falls back to "%s/shaders/%s%s".formatted(RESOURCES_PATH, path, shaderExtension)
    ...
}

RESOURCES_PATH is hardcoded to VulkanMod's own jar (/assets/vulkanmod), and resourceLocation.getNamespace() is never consulted. So when VkGpuDevice.compilePipeline (via VkRenderPass.setPipeline's lazy on-demand compile path) needs to resolve, say, malilib:legacy_terrain, it only ever looks for .../assets/vulkanmod/shaders/legacy_terrain... inside VulkanMod's own jar. It never finds it (the file actually lives in malilib's jar at assets/malilib/shaders/legacy_terrain.vsh/.fsh), getShaderSource returns null, and the pipeline compiles incorrectly/incompletely.

I confirmed this by cloning both xCollateral/VulkanMod (dev branch, MC 1.21.11) and sakura-ryoko/malilib (LTS/1.21.11) and tracing the actual call path:

• fi.dy.masa.malilib.mixin.render.MixinRenderPipelines registers LEGACY_SOLID_TERRAIN_MASA etc. via the standard RenderPipelines/RenderPipeline.builder(...) API, pointing at getId("legacy_terrain") (i.e. malilib:legacy_terrain), with the actual shader files at src/main/resources/assets/malilib/shaders/legacy_terrain.vsh / .fsh in malilib's own jar.
• fi.dy.masa.litematica.render.schematic.ChunkRenderLayers uses those pipelines for schematic terrain rendering.
• net.vulkanmod.render.engine.VkRenderPass#setPipeline lazily calls VkGpuDevice#compilePipeline the first time a given RenderPipeline is drawn, which is otherwise a nice generic design (not a hardcoded whitelist) -- it's specifically the shader source lookup inside that path that's jar-scoped and namespace-blind.

Suggested fix

In getShaderSource(Identifier, ShaderType), when the in-jar lookup misses, fall back to resolving the Identifier's namespace to its owning mod (e.g. via Fabric Loader's FabricLoader.getInstance().getModContainer(namespace) and ModContainer#findPath(...)) and read the shader from there, mirroring the same two-tier path/name.ext -> path.ext lookup order already used for VulkanMod's own shaders. Happy to open a PR with this if useful -- I already wrote and tested the approach as a standalone compat mod (mixin into getShaderSource, fallback via ModContainer#findPath) and it's a small, self-contained change.

Environment

• Minecraft 1.21.11
• VulkanMod dev branch / 0.6.8+1.21.11-dev
• malilib LTS/1.21.11 (sakura-ryoko fork), Litematica LTS/1.21.11 (sakura-ryoko fork)
• Fabric Loader 0.19.3

[GreenSurge]

Update: I built and tested the fix described above (patching ShaderLoadUtil.getShaderSource to fall back to a namespace-aware lookup across other mods' jars when the in-jar lookup misses). Confirmed it resolves the blank/miscolored schematic rendering I opened a PR with the change.

While testing I also found a second, separate bug in the same Litematica + VulkanMod combo that's worth knowing about, even though it's a different mechanism: LevelRendererMixin injects into LevelRenderer.extractVisibleBlockEntities and submitBlockEntities at @At("HEAD") and unconditionally cancels both. Litematica hooks its own schematic block-entity rendering by injecting additional logic at @At("RETURN") on those same two methods. Cancelling at HEAD means the original method body never runs, so any RETURN-based injection into it including Litematica's never executes either. Regular chunk-mesh blocks are unaffected (they go through a separate path both mods cooperate on via renderSectionLayer), but anything rendered through a block entity renderer (chests, beds, signs, banners, etc.) never gets prepared or submitted at all in the schematic overlay.

I worked around this client-side with a lower-priority mixin that hooks the same two methods and calls Litematica's own rendering methods before VulkanMod's cancellation fires, but the real fix is more structural than the shader bug and probably deserves its own issue if it's not something you want folded into this one. I'd be happy to open it separately with the same level of detail if useful. Let me know either way.