Vulkan Rendering & Optimization
A Vulkan real-time renderer combining glTF PBR scene rendering with compute-driven vegetation, CPU and GPU visibility culling, static batching, shadow caster filtering, mipmapped assets and GPU timestamp profiling.
Frame Architecture
The project is presented as a frame, not as a scene. Compute work updates and compacts vegetation. A shadow pass and main pass consume different visible sets. Timestamp queries then report where the GPU budget went.
Simulation & Compaction
Every blade is updated in a compute shader, tested for visibility and compacted into the output buffer. The surviving count becomes the indirect draw command.
Click a stage to inspect the framecompute → shadow → main → resolve → present
Half a million blades. One compacted draw.
The grass system is the largest controlled workload in the renderer. A quadratic Bezier blade stores shape and physical state; compute applies gravity, recovery and wind before three culling tests remove work that cannot contribute to the frame.
GPU-Driven Data Flow
No visible blade list returns to the CPU. The compute shader writes surviving blades into a compact buffer and atomically updates the instance count consumed by the draw.
uint dst = atomicAdd(draw.instanceCount, 1); visibleBlades[dst] = blade; vkCmdDrawIndirect(cmd, drawBuffer, 0, 1, stride);
Scene Visibility & Submission
The imported scene uses a different optimization path from the grass. Bounding volumes are tested on the CPU, compatible static primitives are merged, shadow casters are filtered independently and complete mip chains stabilize distant textures.
Visibility / CPUScene frustum culling
At the locked capture camera, world-space AABB tests reduce submitted scene batches from 290/290 to 247/290, rejecting 43 batches while preserving the rendered image.
Shadow / light spaceIndependent shadow filtering
The shadow pass uses a separate conservative receiver test, sweeping each caster up to 40 world units along the light direction. At this locked view it intentionally retains all 290 potential casters to prevent off-screen shadow popping; this image validates behavior, not a claimed frame-time gain.
Submission / CPUMaterial + spatial batching
With batching disabled the scene produces 495 draw batches; material- and cell-compatible batching reduces that to 290, eliminating 205 batches (41.4%) without turning the level into one un-cullable mesh.
Sampling / textureGenerated mip chains
This image shows the current mipmapped output. A still frame is not an ON/OFF proof: GPU-generated mip chains and trilinear filtering primarily reduce temporal shimmer in distant stone, foliage and texture edges while the camera moves.
GPU Timestamp Profiling
CPU frame time cannot explain which graphics pass is expensive. Timestamp query pools bracket the graphics frame, shadow pass and main pass so the title HUD reports actual GPU duration after query availability is confirmed.
Example captured frame from the runtime HUD. The visual below turns the same timestamp result into a readable frame breakdown.
Implemented Rendering Systems
The final scene is only the stress test. The actual work is a set of reusable rendering systems, each solving a different bottleneck in simulation, visibility, submission, shading or measurement.
glTF + PBR
Static scene import, material channels, transforms and alpha-tested foliage.
HDR IBL
Environment cubemap, irradiance and prefiltered specular response.
Compute grass
Physics, visibility compaction and indirect submission remain on the GPU.
Tessellation LOD
Bezier blades generate fewer segments as projected importance falls.
Two cullers
CPU scene AABBs and GPU blade tests target different workload shapes.
Static batches
Material and spatial compatibility reduce state changes and draw overhead.
Caster filtering
A separate light-space test reduces unnecessary shadow map submissions.
GPU timestamps
Pass-level timings expose the real cost of shadow and main rendering.
GPU GRASS SYSTEM
VULKAN · COMPUTE SHADERS · TESSELLATION
A responsive real-time grass renderer built from Bézier blades. Compute shaders simulate wind and recovery forces while orientation, frustum and distance culling plus adaptive LOD keep more than half a million blades interactive.