Fall back to owning mod's jar when a shader isn't found in VulkanMod'… - #882
Open
GreenSurge wants to merge 1 commit into
Open
Fall back to owning mod's jar when a shader isn't found in VulkanMod'…#882GreenSurge wants to merge 1 commit into
GreenSurge wants to merge 1 commit into
Conversation
…s own jar ShaderLoadUtil.getShaderSource(Identifier, ShaderType) discards the Identifier's namespace and only ever looks inside VulkanMod's own jar (RESOURCES_PATH is hardcoded to /assets/vulkanmod). Any mod that registers a custom RenderPipeline pointing at shaders bundled in its own jar -- e.g. malilib's legacy terrain pipelines, used by Litematica for schematic rendering -- silently fails to resolve, breaking compilation of that pipeline (manifests as blank/miscolored schematics under VulkanMod). This adds a fallback: when the in-jar lookup misses, resolve the Identifier's namespace to its actual owning mod via Fabric Loader's ModContainer API and read the shader from that mod's real resource root, using the same two-tier path/name.ext -> path.ext lookup order already used for VulkanMod's own shaders. Tested against Litematica + malilib on 1.21.11: schematic rendering that was previously blank now renders correctly with VulkanMod enabled.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this fixes
Any mod that registers its own
RenderPipelinepointing at shaders bundled in that mod's own jar fails to render correctly under VulkanMod. Confirmed case: malilib's custom terrain pipelines (LEGACY_SOLID_TERRAIN_MASA, etc.), which Litematica uses for schematic rendering schematics render blank, invisible, or miscolored with VulkanMod enabled, and work fine with the vanilla renderer.Root cause
ShaderLoadUtil.getShaderSource(Identifier, ShaderType)builds its file path fromresourceLocation.getPath()only the namespace half of the Identifier is discarded and only ever searches inside VulkanMod's own jar (RESOURCES_PATHis hardcoded to/assets/vulkanmod). So when a pipeline likemalilib:legacy_terrainneeds compiling, this method only looks forlegacy_terrain...inside VulkanMod's own jar, never finds it (the file actually lives in malilib's jar, atassets/malilib/shaders/legacy_terrain.vsh/.fsh), returnsnull, and the pipeline fails to build correctly.This isn't specific to Litematica/malilib it'll happen for any mod using the standard
RenderPipelineAPI with shaders bundled in its own jar, since that's a completely normal, spec-compliant thing to do.The fix
When the existing in-jar lookup misses, fall back to resolving the Identifier's namespace to its actual owning mod via Fabric Loader's
ModContainerAPI (FabricLoader.getInstance().getModContainer(namespace)ModContainer#findPath(...)), and read the shader from that mod's real resource root. This works identically in a dev environment or a packaged jar, and mirrors the same two-tierpath/name.ext->path.extlookup order already used for VulkanMod's own shaders, so behavior for VulkanMod's own shaders is completely unchanged the fallback only ever runs on the specific case where the current lookup already returns null.FabricLoaderis already a dependency used elsewhere in the codebase (ModSettingsRegistry,Initializer), so this doesn't introduce anything new.Testing
Built and tested against Fabric 1.21.11 + malilib + Litematica (both on their
LTS/1.21.11branches). Schematics that previously rendered blank/blue with VulkanMod enabled now render correctly, with no change in behavior for VulkanMod's own shaders or other rendering.I also have a standalone compat-mod version of this same fix (external mixin, for anyone who wants it before this merges) if that's useful context: [litematica-vulkan-shim].
Diff
Single file changed:
src/main/java/net/vulkanmod/render/shader/ShaderLoadUtil.java(+46/-1). Patch attached / see commit.