Tags
Creators
Details
1.11.0+mc26.2-snap7-2026-05-16
Compatibility
Changes
Vulkan PostFX 1.11.0
This release introduces the first experimental VPFX Native Runtime milestone.
Highlights
- Added VPFX Native Runtime v0 skeleton.
- Added VPFX v2 runtime roadmap documentation.
- Added native runtime dry-run support checks.
- Added native fullscreen pipeline planning.
- Added transient render target planning and lifecycle validation.
- Added
mainTarget -> transientColorcopy validation. - Added the first builtin native fullscreen passthrough draw path.
- Added opt-in diagnostic mode that can skip the external PostChain path after a successful builtin native passthrough draw.
Native Runtime Status
The native runtime is still experimental and opt-in only.
Current supported native diagnostic path:
minecraft:main
-> copy to transientColor
-> builtin fullscreen passthrough native draw
-> minecraft:main
This is currently limited to:
- single-pass native-v0-compatible graphs
- builtin passthrough shader only
- no user shader native execution
- no multi-pass
- no custom targets
- no scene_depth / shadow_depth native inputs
- no compute shaders
Verified
./gradlew build- Minecraft 26.2 Snapshot 7 startup
- VPFX Minimal Showcase loading
- native runtime execute flag
- native diagnostic draw succeeded
- external PostChain skipped in diagnostic mode
- fallback backend remains available
- no black screen / no crash observed during local testing
Notes
- The default backend is still
minecraft_postchain. - Native runtime is not enabled by default.
- User VPFX shaders are not executed by the native runtime yet.
- This release is an experimental milestone for testing native runtime infrastructure.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:TsmOcOBN:G8k5PIuY"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:TsmOcOBN:G8k5PIuY"
}

