optional Vivecraft VR post-processing compatibility (fix: https://github.com/FoundryMC/Veil/issues/91 )

[DarkFoxYT]

Optional Vivecraft VR Post-Processing Compatibility

Overview

This PR introduces an optional VeilVRCompat integration layer that enables VR-aware post-processing when running alongside Vivecraft, while fully preserving Veil’s existing rendering pipeline for standard desktop gameplay.

The integration is entirely reflective, meaning Veil does not require a hard Vivecraft dependency. VR-specific behavior only activates during active Vivecraft stereo eye rendering (LEFT / RIGHT render passes). Outside of VR rendering, Veil continues using its normal framebuffer, post-processing, and dynamic buffer workflow unchanged.

---

Key Features

VR-Aware Rendering Path

• Detects Vivecraft reflectively without introducing a compile-time dependency.
• Detects active VR rendering state and the currently rendered eye.
• Routes veil:post through isolated left/right eye post-processing framebuffers.
• Creates per-eye variants of data-driven Veil framebuffers used by post pipelines.
• Keeps temporary composite framebuffers and dynamic buffers isolated per eye.
• Automatically resizes VR dynamic buffers to the active eye render target instead of the desktop window size.

Per-Eye Lighting & Buffer Isolation

• Routes Veil light rendering and built-in bloom capture through eye-specific framebuffers.
• Resolves Vivecraft eye render targets reflectively to avoid binding the desktop mirror target during VR rendering.
• Prevents cross-eye contamination for:
  • color
  • depth
  • normals
  • material masks
  • light buffers
  • velocity/history buffers

This avoids stereo mismatches, ghosting, reprojection issues, and other VR rendering artifacts.

VR-Safe Rendering State Handling

• Temporarily disables Vivecraft hidden-area stencil/scissor state during Veil light and post passes, then restores it afterward.
• Avoids clearing the main Vivecraft render target during stereo eye rendering when doing so could break Vivecraft compositing alpha.

Automatic VR Uniform Support

Post shaders automatically receive VR-aware uniforms:

• VeilIsVR
• VeilEyeIndex
• VeilViewMatrix
• VeilProjectionMatrix
• VeilInverseViewMatrix
• VeilInverseProjectionMatrix
• VeilCameraPosition
• VeilViewportSize

Additional VR safety uniforms/fallbacks are also provided for:

• motion blur
• camera shake
• fullscreen distortion scaling

---

Why Per-Eye Rendering Matters

Vivecraft renders the scene independently for each eye. Sharing framebuffer data between eyes can introduce severe stereo artifacts, including:

• ghosting
• stereo desync
• broken reprojection
• incorrect depth-based effects
• motion discomfort / nausea

This integration isolates eye-specific rendering resources while preserving the existing Veil shader authoring workflow. Existing shaders continue to function normally and automatically receive the correct eye-specific framebuffer state, matrices, viewport data, and camera information without requiring separate shader variants.

---

Non-VR Behavior

The VR compatibility layer remains completely dormant unless all of the following conditions are true:

• Vivecraft is installed
• VR compatibility is enabled in Veil
• Vivecraft reports VR rendering as active
• The current render pass is LEFT or RIGHT

When those conditions are not met:

• Veil uses the normal framebuffer manager path.
• Composite post-processing uses the existing shared temporary framebuffer map.
• Dynamic buffers use the standard render path.
• Post shaders continue receiving the normal camera and viewport uniforms.

---

Configuration

New client configuration options added to config/veil-client.json:

• enableVrCompatibility
• usePerEyePostProcessing
• disableMotionBlurInVR
• reduceDistortionInVR
• vrPostQuality
• debugVREyeBuffers

---

VR-Specific Adjustments

Default VR Safety Behavior

• Motion blur is disabled by default in VR.
• Camera shake intensity is reduced/suppressed.
• Strong fullscreen distortion effects are scaled down.

Per-Eye Resource Isolation

The following systems are isolated per eye during stereo rendering:

• temporal framebuffer history
• dynamic color/depth/normal/material/light buffers
• velocity buffers
• bloom mip/blur chains
• composite post-processing intermediates

Dynamic Buffer Improvements

• Dynamic albedo/normal buffers used by Veil lighting now bind directly to the active eye render target.
• Buffers resize to the active eye resolution, preventing lower-left boxed rendering artifacts common in VR framebuffer mismatches.

Lighting Compatibility

• Veil lighting passes render independently from Vivecraft’s hidden-area eye stencil, preventing partial-eye clipping and cutout artifacts.

---

Limitations

• Veil cannot automatically guarantee that every externally created framebuffer is VR-safe. Warnings are logged when post passes reference framebuffers that are not known to be per-eye isolated.
• Custom shaders using non-standard motion blur, distortion, or camera-shake uniforms may need to adopt the new Veil*Scale VR safety uniforms.
• Vivecraft integration remains fully reflective and intentionally avoids a hard dependency.
• This implementation targets Fabric 1.21.1 with Yarn mappings and should still be validated in real headset testing scenarios.

ps: i just wanted to have veil have vr support for horror mod lol but if it ain't gona be used i hope ya don't mind if i use this version for myself, but i tested and it works for fabric and neoforge so like yeah... also according to this it would be peak so like i made it XD #91

[KalarianAthecila]

I like this one, hyped for them to merge this!

[DarkFoxYT]

so uhh latest commit is just for like better performance and compat with bloom and stuff in fp and in vr and having other stuff like sodium not crash when vr is active.

Small changes but mainly just issue fixing XD fixes this too btw #107

[DarkFoxYT]

oh btw i wanna slide in a quick note, the fps is capped due to the refresh rate of the headset, vivecraft does that by it'self and it is completeley normal, just saying!

[DarkFoxYT]

quick fix for issue #144

The issue was that Veil always skipped Minecraft’s vanilla particles_target setup in Fabulous mode, even when Veil dynamic buffers were not actually active. Particles then rendered into the wrong target and disappeared during Fabulous compositing. I changed it so vanilla target setup/clear runs unless Veil is truly replacing that framebuffer state. I also corrected the clear hook to wrap clearRenderState() instead of accidentally wrapping setup twice.

[Derpgamer22]

Can't wait for a possible fix for the Fabulous graphics issue so I can finally see particles behind colored glass 🥹

[DarkFoxYT]

Updated the optional Vivecraft VR compatibility work with a cleaner, lower-noise debug path and improved documentation.

Changes:

• Added a concise console status line for Vivecraft/VR state:
  • whether Vivecraft is present
  • whether VR initialized
  • whether VR is active
  • detected provider/runtime/hardware when available
• Removed duplicate VR matrix/camera uniforms from the post shader upload path.
  • Shaders should use the existing VeilCamera buffer instead.
  • This avoids duplicating data already exposed as VeilCamera.ViewMat, VeilCamera.ProjMat, VeilCamera.IViewMat, VeilCamera.IProjMat, and VeilCamera.CameraPosition.
• Removed the shader compatibility warning/check to avoid noisy or misleading logs.
• Polished the VR shader compatibility wiki with a clearer compatibility checklist.
• Kept the VR integration optional and reflective.

Validation:

• :common:compileJava
• :fabric:compileJava
• :neoforge:compileJava