Going 3D: Perspective, Depth & Meshes

01From 2D to 3D

A sprite renderer draws flat quads in a fixed order; a 3D scene has objects at every distance, overlapping in any order. Four changes turn the sprite renderer into a 3D one. The instance, device, swapchain, and synchronization stay as they are.

1. Orthographic → perspective. The projection now produces a non-unit w, and the GPU's perspective divide gives foreshortening: distant things shrink.
2. The depth buffer becomes mandatory. In 2D, back-to-front draw order sufficed (the 2D renderer's painter's approach); in 3D, arbitrary overlap needs per-pixel depth (the depth test).
3. Vertices gain Z and a normal. Position is a vec3; a normal rides along for lighting later.
4. A model matrix per object. 2D pushed one view-projection; 3D needs an M per object, which forces the question of how to feed many matrices to the GPU.

02Perspective projection

In a 3D game, a crate 20 m away should look half the size of the same crate at 10 m. The perspective matrix maps a view frustum (defined by vertical FOV, aspect, near, and far) into clip space such that the later divide by w produces foreshortening. The 3D Math tutorial derives the matrix; here are the result and the Vulkan-specific deltas that bite.

After the divide by w, a view-space point (x, y, z), with the camera looking down −z, lands at:

In words: scale the point by the lens's focal factor, squeeze x for the screen's aspect, and divide both by the distance in front of the camera. Twice as far means half the size on screen. The projection matrix stores the distance in w so the GPU's divide does this. Hover any term to see what it stands for.

The widget shows the frustum from the side and the projected result next to it:

// define BEFORE including glm: GLM_FORCE_RADIANS, GLM_FORCE_DEPTH_ZERO_TO_ONE
glm::mat4 projection = glm::perspective(glm::radians(60.0f), aspect, 0.1f, 1000.0f);
projection[1][1] *= -1.0f;                       // flip Y for Vulkan's Y-down NDC (depth macro does NOT do this)
glm::mat4 view = glm::lookAt(cameraPos, cameraTarget, glm::vec3(0,1,0));
glm::mat4 clipFromModel = projection * view * model;   // P * V * M, column vectors

// glam: perspective_rh already targets 0..1 depth (perspective_rh_gl is the -1..1 one)
let mut projection = Mat4::perspective_rh(60.0_f32.to_radians(), aspect, 0.1, 1000.0);
projection.y_axis.y *= -1.0;                          // flip Y for Vulkan's Y-down NDC
let view = Mat4::look_at_rh(camera_pos, camera_target, Vec3::Y);
let clip_from_model = projection * view * model;      // P * V * M

03The camera & MVP

The player moves the camera, and every object in the world has to move the opposite way on screen. The view matrix is the inverse of the camera's world transform; lookAt(eye, center, up) builds it directly. Two cameras cover most needs: an orbit camera (spherical coordinates around a target) and a free-fly camera (position plus yaw/pitch, WASD and mouse).

The full MVP transform, for column vectors, reads right to left: model, then view, then projection (the 3D Math convention).

In words: multiply the vertex by model first (place it in the world), then view (move it into the camera's frame), then projection (apply perspective). With column vectors the matrices sit on the left and apply right-to-left, so the chain is written in the reverse of the order it runs. P and V are the same for every vertex in a frame; M changes per object, which is the next problem. Hover any symbol to see what it stands for.

(Row-vector libraries such as DirectXMath write it position · M · V · P; follow whichever convention your math library uses.)

04The depth buffer

Without a depth buffer, whatever is drawn last ends up on top, so a wall drawn after a character covers it even when the character is in front. This is the densest delta over the color-only triangle. Four steps: pick a supported depth format, create the depth image and view, enable depth in the pipeline, and wire the depth attachment into dynamic rendering^[1].

• Query the format with vkGetPhysicalDeviceFormatProperties, checking VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT against candidates D32_SFLOAT, D32_SFLOAT_S8_UINT, D24_UNORM_S8_UINT. Don't assume a format is available.
• Create the depth image + view (usage DEPTH_STENCIL_ATTACHMENT, aspect DEPTH, device-local), and recreate it on swapchain resize.
• Enable depth in the pipeline: depthTestEnable and depthWriteEnable true, depthCompareOp = LESS (or GREATER for reversed-Z).
• Wire dynamic rendering: set depthAttachmentFormat at pipeline creation, and add a depth VkRenderingAttachmentInfo with loadOp = CLEAR^[9].

Two shapes overlap; the cube is nearer but drawn first:

// pipeline creation: add the depth format alongside the color format (the delta over the triangle)
let color_formats = [swapchain_format];                   // named so the borrow outlives this statement
let mut rendering = vk::PipelineRenderingCreateInfo::default()
    .color_attachment_formats(&color_formats)
    .depth_attachment_format(depth_format);              // NEW
let depth_stencil = vk::PipelineDepthStencilStateCreateInfo::default()
    .depth_test_enable(true).depth_write_enable(true)
    .depth_compare_op(vk::CompareOp::LESS);              // GREATER for reversed-Z

// record time: a depth attachment beside the color one, cleared each frame
let depth_attachment = vk::RenderingAttachmentInfo::default()
    .image_view(depth_image_view)
    .image_layout(vk::ImageLayout::DEPTH_ATTACHMENT_OPTIMAL)
    .load_op(vk::AttachmentLoadOp::CLEAR)                // MUST clear, or garbage occlusion
    .store_op(vk::AttachmentStoreOp::DONT_CARE)
    .clear_value(vk::ClearValue { depth_stencil: vk::ClearDepthStencilValue { depth: 1.0, stencil: 0 } });  // 0.0 for reversed-Z
let rendering_info = vk::RenderingInfo::default()
    .color_attachments(&color_attachments)
    .depth_attachment(&depth_attachment);

05The 3D vertex

Lighting later needs to know which way each point on the surface faces, and textures need to know which part of the image goes where. The vertex grows to position (vec3), normal (vec3), and UV (vec2). The vertex input description gains two attributes:

struct Vertex { glm::vec3 position; glm::vec3 normal; glm::vec2 uv; };
VkVertexInputBindingDescription binding{ 0, sizeof(Vertex), VK_VERTEX_INPUT_RATE_VERTEX };
VkVertexInputAttributeDescription attrs[3] = {
    { 0, 0, VK_FORMAT_R32G32B32_SFLOAT, offsetof(Vertex, position) },
    { 1, 0, VK_FORMAT_R32G32B32_SFLOAT, offsetof(Vertex, normal)   },
    { 2, 0, VK_FORMAT_R32G32_SFLOAT,    offsetof(Vertex, uv)       },
};

#[repr(C)]
struct Vertex { position: [f32; 3], normal: [f32; 3], uv: [f32; 2] }
let binding = vk::VertexInputBindingDescription::default()
    .binding(0).stride(size_of::<Vertex>() as u32).input_rate(vk::VertexInputRate::VERTEX);
let attrs = [
    vk::VertexInputAttributeDescription::default().location(0).format(vk::Format::R32G32B32_SFLOAT).offset(0),
    vk::VertexInputAttributeDescription::default().location(1).format(vk::Format::R32G32B32_SFLOAT).offset(12),
    vk::VertexInputAttributeDescription::default().location(2).format(vk::Format::R32G32_SFLOAT).offset(24),
];

The normal needs the inverse-transpose of the model's upper-3×3 under non-uniform scale (the 3D Math tutorial covers why). The lighting that uses it lands in the next module; here the vertex just carries it.

06Loading a mesh

Hand-typed cubes run out fast; real geometry comes from an artist's tool, through a file format your loader has to understand. Prove the pipeline with a hardcoded cube (24 vertices for per-face normals, 36 indices in an index buffer), then load real geometry. The standard interchange format is glTF 2.0, "the JPEG of 3D": a runtime-ready, royalty-free format that shipping engines and viewers load^[5].

Two loaders do the parsing: cgltf, a single-file C library, and the gltf crate in Rust^[7].

let (document, buffers, _images) = gltf::import("model.gltf")?;   // resolves .bin / GLB
for mesh in document.meshes() {
    for primitive in mesh.primitives() {
        let reader = primitive.reader(|b| Some(&buffers[b.index()]));
        let positions: Vec<[f32; 3]> = reader.read_positions().unwrap().collect();
        let normals:   Vec<[f32; 3]> = reader.read_normals().unwrap().collect();
        let indices:   Vec<u32>     = reader.read_indices().unwrap().into_u32().collect();
        // normals and indices are optional in glTF: a real loader handles None instead of unwrapping
        // upload positions/normals (read_tex_coords(0) gives uvs) into a vertex buffer, indices into an index buffer
    }
}

// cgltf: single-file C99 loader
cgltf_options options = {0};
cgltf_data* data = NULL;
cgltf_parse_file(&options, "model.gltf", &data);
cgltf_load_buffers(&options, data, "model.gltf");   // reads .bin, decodes data URIs
// walk data->meshes[i].primitives[j].attributes[k].data (accessor) -> buffer_view -> buffer
cgltf_free(data);

07Per-object data

A scene with a thousand props needs a thousand model matrices on the GPU each frame. One object: push the model matrix (or premultiplied MVP) as a push constant: a 64-byte mat4 fits in the 128-byte guaranteed minimum (the 2D renderer did this). Many objects need more room, and there's a ladder.

• UBO: one uniform buffer (std140 layout), bound by a descriptor.
• Dynamic UBO: one buffer, a per-object offset (UNIFORM_BUFFER_DYNAMIC) that must be a multiple of minUniformBufferOffsetAlignment^[8].
• SSBO: a storage buffer (std430), indexed by gl_InstanceIndex or a draw ID; the usual choice in GPU-driven renderers.

08Culling & winding

A closed mesh like a character has as many triangles facing away from the camera as toward it, and drawing the hidden half is wasted work. Back-face culling skips triangles facing away: cullMode = BACK plus a frontFace winding. glTF declares counter-clockwise front faces. How that interacts with Vulkan's Y-down framebuffer decides whether the model renders correctly, inside-out, or not at all.

09The scene graph

A character holds a sword. When the character turns, the sword has to turn with it, without anyone updating the sword's position by hand. Objects rarely live in world space directly; they hang off a hierarchy, the scene graph. Each node has a local transform; its world transform is computed by traversing parents before children. glTF's node tree maps straight onto this; Sascha Willems's glTF samples build each node's matrix by walking up its parents^[10].

In words: a node's place in the world is its parent's world transform composed with its own local one. Because parent.world is on the left, the parent must be computed first; walk the tree top-down (parents before children) and every node sees a finished parent. Flip the two factors and the child orbits the world origin instead of its parent, the classic bug the widget shows.

The optimization is dirty flags: recompute a node's world transform only when it or an ancestor moved. The widget shows a parent driving its children, and the cost of recomputing everything versus just the dirty subtree:

Wrong answers, and why: Vulkan's NDC is right-handed (the symptoms are the Y-down framebuffer and the 0-to-1 range, not handedness or format); and an inside-out model is a winding and culling mismatch, not a depth or index-width issue.

10Pitfalls

11What's next

There's a lit-ready mesh on screen with correct depth. Next is making it look good: PBR Materials & Lighting uses the normal the vertex now carries and the metallic-roughness textures to shade the surface physically, then shadows, then deferred rendering. The full 3D path is on the series hub.

1. Khronos. Vulkan Tutorial, "Depth Buffering." docs.vulkan.org. The format query, the depth image/view, the depth-stencil state, and the dynamic-rendering depth attachment with clear.
2. Nathan Reed. "Depth Precision Visualized." reedbeta.com. The 1/z precision problem and reversed-Z with a float depth buffer.
3. glam (Rust). docs.rs/glam. perspective_rh (0 to 1) vs perspective_rh_gl (−1 to 1), and look_at_rh. (Cite by API; glam moves fast across minor versions.)
4. AnKi 3D Engine. "Vulkan's coordinate system." anki3d.org. Right-handed NDC with Y down, 0-to-1 depth, the negative viewport height, and the opposite frontFace AnKi uses when rendering offscreen without it.
5. The Khronos Group. glTF 2.0 Specification. registry.khronos.org. The runtime interchange format: right-handed, +Y up, meters, CCW front faces, and the buffer/bufferView/accessor model.
6. The Khronos Group. glTF Tutorial, "Buffers, BufferViews, Accessors." github.khronos.org. The three-level data model, explained plainly.
7. cgltf (github.com/jkuhlmann/cgltf, single-file C) and the gltf crate (docs.rs/gltf, Rust). The loaders: cgltf_parse_file/cgltf_load_buffers and gltf::import + the primitive reader.
8. The Khronos Group. Vulkan guide, "Shader Memory Layout" and "Descriptor Dynamic Offset." docs.vulkan.org. std140 alignment (vec3→16, mat4→64) and dynamic-UBO offset alignment.
9. The Khronos Group. Vulkan Specification, VkPipelineRenderingCreateInfo. registry.khronos.org. The depthAttachmentFormat for dynamic rendering, which must match the bound depth view.
10. Sascha Willems. Vulkan glTF scene rendering and Vulkan-glTF-PBR. github.com/SaschaWillems. The production reference for a glTF-to-engine loader and per-object data: node matrices are composed by walking up the parent chain and pushed per node.
11. Sascha Willems. "Flipping the Vulkan viewport." 2019. saschawillems.de. OpenGL-style CCW data renders upside down with its front faces culled in Vulkan; a negative viewport height fixes both with unchanged vertex data and shaders.