Engine Overview

Vulkan Schnee is a desktop VR engine for scenes authored in Blender and rendered through Vulkan and OpenXR.

This page gives a quick technological overview of the engine. Use it as a map from engine capability to the detailed documentation page for that system.

What Vulkan Schnee Is Built For

• Desktop VR through OpenXR.
• Static or mostly-static worlds with baked lighting.
• GPU-driven rendering of glTF scenes.
• Large scene geometry with meshlet-based visibility reduction.
• Lightmapped static objects and probe-based ambient lighting.
• Blender as the primary editor and export path.

Rendering

Vulkan Schnee renders stereo VR views through Vulkan and submits frames to OpenXR. The renderer also supports desktop mirror output for inspecting headset rendering on a normal window.

The renderer owns persistent GPU resources, records per-frame command buffers, and coordinates frame synchronization through renderer-side frame state.

References: Renderer Overview, VR Renderer, Mirror View.

GPU Scene And Culling

Scene geometry is flattened into GPU-side buffers for transforms, materials, meshlets, draw data, and culling data. Per-frame CPU work updates transforms and frame constants; visibility reduction and draw preparation run on the GPU.

The main path runs primitive culling, optional cluster LOD selection, meshlet binning, meshlet unpacking, and indirect draw preparation before the mesh shader or vertex-shader fallback draws visible geometry.

References: GPU-Driven Rendering Pipeline, Rendering Data Hierarchy, Rendering Data Manager, Shader Bindings.

Scene Data And Asset Loading

The runtime imports glTF scene data, mesh primitives, materials, textures, skins, animations, collision metadata, lightmap metadata, and SH probe metadata. glTF sub-assets are addressed with stable handles and loaded through asynchronous asset pipelines.

Texture loading supports PNG/JPG through glTF, EXR lightmaps, and KTX/KTX2 texture payloads. KTX/KTX2 assets can carry precomputed mip chains and block-compressed formats such as BC5, BC6H, and BC7 depending on texture type and export settings.

References: Asset Loading System, Ktx2Loader, AssetRegistry.

Lighting

Static lighting uses baked lightmaps on a dedicated lightmap UV channel, typically TEXCOORD_1. The Blender exporter writes lightmap metadata into the engine glTF extension, including the lightmap texture path and UV channel.

The tooling can bake EXR lightmaps in Blender and export compressed runtime textures. Current export options include BC6H conversion for HDR lightmaps and BC7 conversion for PBR textures. Normal maps can use BC5 encoding when authored that way.

Ambient diffuse lighting uses spherical harmonics probe grids baked from Blender probe volumes. The exporter writes .shprobe references into the scene-level engine extension, and the runtime loads the probe grid during scene import.

References: Lightmap Baking, SH Probe Baking, Blender Exporter Plugin.

Physics And Collision

Vulkan Schnee uses Bullet 3 as the physics backend. PhysicsBody components own Bullet rigid bodies, while collision components provide Bullet shapes such as boxes, spheres, capsules, convex hulls, and triangle meshes.

Collision behavior is profile based. Profiles resolve to Ignore, Overlap, or Block, and the registry maps active profiles to Bullet collision groups and masks.

The physics API exposes immediate gameplay queries for ray traces, sphere overlaps, and sphere sweeps. Use these for line of sight, hitscan, placement tests, sensors, and continuous projectile checks.

References: Collision Responses, Physics Queries, PhysicsBody, Collision Component.

Input And XR Tracking

Input has two layers. Input::XrInputHandler samples raw OpenXR input, and Input::InputManager exposes named bool, float, and glm::vec2 actions to gameplay code.

Input is sampled once per frame before gameplay tick. Callbacks dispatch after tracked poses are resolved, so input callbacks can read current-frame controller transforms.

References: Input Handling, Player Controller Handbook.

Gameplay Model

Runtime gameplay is built from scenes, actors, components, and tickable logic. Actors own scene nodes, can attach to other actors or nodes, and can receive per-frame updates through the tick system.

Use custom logic components for actor-local gameplay state. Use attachment rules when reparenting actors while preserving either world-space or local-space transforms.

References: Custom Actor And Component Handbook, Actor Attachments, Tick System, Timer Manager.

Audio

Audio uses miniaudio for decoding and playback. Audio assets decode WAV, FLAC, and MP3 files asynchronously, store PCM data in asset records, and register loaded clips with the audio engine for playback.

Spatial audio, streaming music, and ECS audio source/listener components are not part of the current runtime path.

References: Audio Integration, Asset Loading System.

Animation

Skins and animations load from glTF through the model asset pipeline. Runtime skeletal data stores skin and animation payloads owned by the asset managers and can be referenced by ECS animation state.

References: Asset Loading System.

Blender Tooling

Blender is the primary authoring environment. The editor plugin adds Vulkan Schnee object, material, lightmap, collision, and export properties. The exporter writes engine data into glTF extensions and copies or converts referenced runtime assets.

The tooling includes lightmap baking, SH probe baking, engine export presets, custom material metadata, collision metadata, and optional texture conversion for runtime-ready assets.

References: Tooling, Blender Editor Overview, Vulkan Schnee Blender Editor, Blender Exporter Plugin, Asset LSP.

Current Constraints

• The main target is desktop VR, not mobile VR.
• Mesh shaders are optional at runtime. The renderer enables vertex-shader-only mode when mesh shaders are unavailable.
• Blender is the expected content authoring workflow.
• Audio playback is clip based and non-spatial in the current runtime path.
• Some gameplay systems are prototype-level and game-specific.