15 selected computer graphics interview questions grouped by seniority level. Use them to review fundamentals, practical trade-offs, and senior-level production reasoning.
1Describe linear blend skinning and how bone matrices are applied to a vertex with multiple influences.
Linear Blend Skinning (LBS) is a geometric deformation technique used to animate 3D meshes based on an underlying skeletal hierarchy. In skeletal animation, each animated bone moves relative to its reference configuration (the bind pose). To transform a vertex influenced by multiple bones: 1. The vertex's original position in mesh space is transformed into each bone's local space by multiplying by the bone's Inverse Bind Pose Matrix ($B_i^{-1}$). 2. The vertex is then transformed from the bone's local space into the current animated pose space using the bone's Animated Bone Matrix ($M_i$). The composite transformation $S_i = M_i \cdot B_i^{-1}$ is the skinning palette matrix. 3. The final skinned vertex position is computed as the linear weighted sum across all influencing bones: $$v' = \sum_{i=1}^{k} w_i \cdot (M_i \cdot B_i^{-1} \cdot v)$$ where the scalar bone weights $w_i$ must be normalized (i.e., $\sum w_i = 1.0$). On the GPU, this is typically executed in the vertex shader (or a compute skinning pre-pass) by fetching the precomputed bone palette from a uniform/structured buffer using vertex bone index attributes, and linearly blending the positions. Vertex normals and tangents are transformed using the rotational part of the blended skinning matrix and re-normalized.
#version 450
layout(location = 0) in vec3 inPosition;
layout(location = 1) in vec3 inNormal;
layout(location = 2) in uvec4 inBoneIndices; // Up to 4 bone influences
layout(location = 3) in vec4 inBoneWeights; // Normalized: sum to 1.0
layout(set = 0, binding = 0) uniform BonePalette {
mat4 boneMatrices[128]; // Pre-multiplied: M_i * B_i^-1
};
layout(location = 0) out vec3 outNormal;
void main() {
mat4 skinMatrix = inBoneWeights.x * boneMatrices[inBoneIndices.x] +
inBoneWeights.y * boneMatrices[inBoneIndices.y] +
inBoneWeights.z * boneMatrices[inBoneIndices.z] +
inBoneWeights.w * boneMatrices[inBoneIndices.w];
vec4 skinnedPosition = skinMatrix * vec4(inPosition, 1.0);
gl_Position = u_ViewProjection * skinnedPosition;
// Transform normal with rotational part of skinMatrix and normalize
outNormal = normalize(mat3(skinMatrix) * inNormal);
}
2Describe GPU instancing and what per-instance data and layouts make rendering many similar objects efficient.
GPU instancing is a rendering technique that draws multiple copies of the same base geometry (sharing vertex and index buffers) in a single draw call (e.g., DrawIndexedInstanced in Direct3D or glDrawElementsInstanced in OpenGL), drastically reducing CPU-GPU driver overhead and API draw call counts. Per-Instance Data: To ensure instances look and behave distinctly, per-instance data is provided, commonly including: - Transform data: World matrix, or packed position/rotation/scale. - Material properties: Color tints, UV offsets/scales, or material ID indices. - Dynamic parameters: Animation phase, lightmap offsets, or visibility flags. Data Layouts and Access Methods: 1. Instanced Vertex Buffers: A dedicated vertex buffer bound with per-instance step rate (e.g., `D3D11_INPUT_PER_INSTANCE_DATA`). The GPU automatically advances the buffer per instance. 2. StructuredBuffer / Uniform Buffer (SSBO / Constant Buffer): Instance data is uploaded into a buffer array, and the vertex shader indexes into it using the built-in system instance identifier (`SV_InstanceID` in HLSL, `gl_InstanceID` in GLSL). Keeping per-instance data compact (e.g., 3x4 affine matrices or position + quaternion instead of full 4x4 matrices, and packed FP16/uint32 colors) minimizes GPU memory bandwidth and optimizes cache utilization.
3Explain frustum culling, occlusion culling, and back-face culling and where each typically occurs in a renderer.
Frustum culling, occlusion culling, and back-face culling are three complementary visibility techniques that discard non-visible primitives at different stages and granularities in a rendering pipeline: 1. Frustum Culling: Discards geometry lying completely outside the camera's view frustum. It is typically performed on coarse bounding volumes (like AABBs or bounding spheres) on the CPU before draw submission, or on the GPU via compute shaders in GPU-driven rendering pipelines. 2. Occlusion Culling: Discards objects or primitives that are inside the frustum but hidden behind other opaque geometry. It can occur on the CPU (using software rasterization or precomputed visibility) or on the GPU (using hardware occlusion queries, GPU compute Hi-Z depth buffer tests, or meshlet culling) prior to full rasterization. 3. Back-Face Culling: Discards individual polygons whose surface normals face away from the camera. This is traditionally performed automatically by fixed-function hardware during triangle setup/rasterization on the GPU based on screen-space winding order, though it can also be evaluated coarsely on cluster normal cones (e.g., in mesh shaders).
struct Plane { glm::vec3 normal; float distance; };
struct Sphere { glm::vec3 center; float radius; };
bool isSphereInsideFrustum(const Sphere& sphere, const Plane frustumPlanes[6]) {
for (int i = 0; i < 6; ++i) {
// Signed distance from plane to sphere center
float dist = glm::dot(frustumPlanes[i].normal, sphere.center) + frustumPlanes[i].distance;
if (dist < -sphere.radius) {
return false; // Completely outside
}
}
return true; // Inside or intersecting
}
4How do spline curves such as Bézier, B-spline, and Catmull-Rom generate smooth paths or geometry strips?
Spline curves provide parametric formulations $\mathbf{P}(t)$ to define smooth 3D paths, camera tracks, and extruded geometry strips (such as ribbons, roads, or tubes). 1. **Curve Types & Properties:** - **Bézier Curves:** Formulated with Bernstein polynomials. They interpolate only the endpoints; intermediate control points define tangent handles. Connecting segments with $C^1$ continuity requires collinear tangent handles. - **B-splines:** Constructed using basis functions over a knot vector. They provide local control and high parametric continuity ($C^2$ for cubic), but generally do not pass through interior control points. - **Catmull-Rom Splines:** A class of interpolating splines that pass directly through all interior control points while ensuring $C^1$ continuity automatically, making them ideal for user-authored paths. 2. **Path & Geometry Generation:** - Evaluating the spline at parameter $t$ produces position $\mathbf{P}(t)$ and tangent vector $\mathbf{T}(t) = \mathbf{P}'(t)$. - To extrude 3D ribbons or tubes, an orthogonal coordinate frame (Normal $\mathbf{N}(t)$ and Binormal $\mathbf{B}(t)$) is needed along the curve. - Standard Frenet-Serret frames fail or flip at inflection points where curvature $\kappa = 0$. To prevent unnatural ribbon twisting, **Parallel Transport Frames (Bishop Frames)** propagate a reference orientation smoothly along the curve by minimizing rotational torsion.
5What is a command buffer, and why does multi-threaded command recording matter in high-end engines?
A command buffer (or command list in Direct3D 12) is a data structure in memory where graphics, compute, and transfer commands—such as setting pipeline state, binding descriptors, issuing draw calls, and recording pipeline barriers—are recorded on the CPU for subsequent submission and asynchronous execution on a GPU queue. Multi-threaded command recording is critical in high-end engines because CPU-side draw call preparation, state binding, and culling have traditionally been primary bottlenecks. By removing single-threaded context constraints, explicit APIs allow an engine to divide a frame into independent rendering tasks across multiple CPU worker threads. For example, shadow passes, G-buffer chunks, and post-processing can be recorded simultaneously. Modern APIs facilitate this via primary and secondary command buffers (Vulkan) or command lists and bundles (D3D12). Secondary command buffers and bundles allow worker threads to record subsets of draw commands that can be executed inside a primary command buffer on the submission thread, maximizing multi-core CPU utilization and minimizing GPU queue stalls.
6How do push constants or root constants differ from uniform/constant buffers, and when should they be used?
Push constants (in Vulkan) and root constants (in DirectX 12) provide a mechanism to pass small amounts of uniform data inline directly within the command buffer or root signature, bypassing the overhead of allocating, updating, and binding descriptor-backed GPU buffer resources. In contrast, Uniform Buffers (UBOs) or Constant Buffers (CBOs) are backed by dedicated GPU memory allocations that are bound to the pipeline via descriptors, descriptor tables, or descriptor sets. Because push/root constants are embedded into the command stream itself, they are ideal for high-frequency, per-draw data that changes frequently (such as object transform matrices, material/mesh indices, time values, or dynamic offsets). However, they have strict size limits (e.g., Vulkan guarantees a minimum limit of only 128 bytes, and D3D12 root signature space is capped at 64 DWORDs shared with root descriptors and tables). Uniform/constant buffers should be used when the data payload exceeds push constant size limits, when data is shared across multiple draws (such as per-frame camera/view matrices, global scene lighting, or environment settings), or when persistent storage across passes is needed.
7Walk through the coordinate spaces a vertex travels through from model space to screen space in a real-time renderer.
In a real-time rendering pipeline, a vertex typically transitions through several coordinate spaces: Model (Local) Space, World Space, View (Camera) Space, Clip Space, Normalized Device Coordinates (NDC), and Screen (Viewport/Window) Space. The vertex begins in Model Space relative to the asset's local origin. Multiplying by the Model/World matrix places and orients it in the shared World Space. Multiplying by the View matrix transforms it into View Space, where the camera is at the origin looking down a standard viewing direction. Next, multiplying by the Projection matrix transforms coordinates into 4D Clip Space $(x_c, y_c, z_c, w_c)$, where geometry is clipped against the view volume. Following clipping, the fixed-function hardware performs the perspective divide (dividing $x_c, y_c, z_c$ by $w_c$) to produce 3D Normalized Device Coordinates (NDC). Finally, the Viewport Transform maps NDC coordinates to 2D Screen Space pixel coordinates and depth buffer values.
8Compare linear blend skinning with dual-quaternion skinning in deformation quality, artifacts, and engineering complexity.
Linear Blend Skinning (LBS) and Dual-Quaternion Skinning (DQS) represent two distinct approaches to skeletal mesh deformation: 1. Deformation Quality and Artifacts: - LBS computes transformed vertices via linear interpolation of bone transformation matrices. While fast, LBS suffers from volume loss during severe rotations and twisting, notably the 'candy-wrapper' artifact where cylindrical geometry collapses along the twist axis. - DQS represents rigid bone transformations as unit dual quaternions (combining rotation and translation). When blended (e.g., using Dual Linear Blending), DQS naturally preserves volume and eliminates candy-wrapper twisting artifacts. However, DQS introduces its own artifacts, such as bulging or pinching at extreme joint bends. 2. Engineering and Implementation Complexity: - LBS natively supports full affine transformations (translation, rotation, and non-uniform scale or shear) using standard 4x4 matrix pipelines. - DQS only handles rigid transformations natively. Handling scaling (especially non-uniform scale) requires multi-pass deformation, polar decomposition, or scale-shear separation. Additionally, DQS requires antipodality handling during blending (checking dot products of dual quaternions to take the shortest rotation path and avoid mesh flipping/collapsing), making the shader math and asset pipeline more complex.
9Animated characters deform incorrectly on only some meshes. What asset and shader data would you inspect?
When animated characters deform incorrectly on only a subset of meshes, the issue typically stems from data mismatches across the asset pipeline, vertex layout, or shader constants. A systematic inspection should cover: 1. Vertex Layout and Bone Index Bounds: Ensure vertex bone indices do not exceed the skeleton's bone count or overflow their packed data type (e.g., using uint8/ubyte4 when the skeleton has >256 bones, causing index wrap-around). 2. Bone Weight Normalization: Verify that the sum of bone weights per vertex equals 1.0. Non-normalized weights cause vertices to shrink toward or pull away from the skeleton. 3. Inverse Bind Pose Matrices (IBMs): Confirm that the mesh's inverse bind matrices match the skeleton's rest pose and coordinate space. Mismatched bind poses cause the mesh to explode or offset incorrectly. 4. Maximum Influences per Vertex: Check whether the DCC exporter exported more bone influences per vertex (e.g., 8 influences) than the vertex buffer layout or shader supports (e.g., 4 influences), dropping weights without re-normalization. 5. Skeleton Hierarchy and Palette Indexing: Validate that bone index mappings in the mesh match the bone matrix palette uploaded to constant/structured buffers.
struct SkinVertex {
float position[3];
uint8_t boneIndices[4];
uint8_t boneWeights[4]; // UNORM8
};
void ValidateMeshSkinData(const std::vector<SkinVertex>& vertices, uint32_t maxBoneCount)
{
for (size_t i = 0; i < vertices.size(); ++i)
{
const auto& v = vertices[i];
int weightSum = 0;
for (int b = 0; b < 4; ++b)
{
assert(v.boneIndices[b] < maxBoneCount && "Bone index exceeds palette size!");
weightSum += v.boneWeights[b];
}
assert(std::abs(weightSum - 255) <= 1 && "Bone weights do not normalize to 1.0!");
}
}
10What are morph targets or blend shapes, and how are they combined with skeletal skinning for facial animation?
Morph targets (blend shapes) represent geometric deformations stored as per-vertex delta offsets (delta positions, delta normals, and optionally delta tangents) relative to a base rest-pose mesh. Each morph target is controlled by a scalar weight (typically 0.0 to 1.0), and the deformed vertex attributes are calculated as: `Morphed_Attribute = Base_Attribute + Sum(Weight_i * Delta_i)`. When combining morph targets with skeletal skinning (e.g., for facial animation): 1. Evaluation Order: Morph target deltas must be evaluated in the neutral/bind pose model space before skeletal skinning is applied. 2. Skinning Pass: The morphed positions and normals are subsequently transformed by the skeletal skinning bone matrices. Applying morphing prior to skinning ensures facial expressions deform naturally with head turns and jaw joint rotations. From a performance and bandwidth standpoint, naively storing and reading full mesh copies for dozens of blend shapes causes heavy memory bandwidth pressure. Practical implementations store sparse deltas (only non-zero vertices), compress delta formats (e.g., FP16 or quantized integers), or use GPU compute shader pre-passes to calculate morphed vertices once before multiple render passes.
struct VertexInput {
float3 position : POSITION;
float3 normal : NORMAL;
uint4 boneIndices : BLENDINDICES;
float4 boneWeights : BLENDWEIGHT;
};
// 1. Accumulate morph deltas in local rest space
float3 morphedPos = input.position;
float3 morphedNorm = input.normal;
for (int i = 0; i < activeMorphCount; ++i) {
morphedPos += morphDeltasPos[i] * morphWeights[i];
morphedNorm += morphDeltasNorm[i] * morphWeights[i];
}
morphedNorm = normalize(morphedNorm);
// 2. Skin morphed geometry to world space
float4 skinnedPos = 0;
float3 skinnedNorm = 0;
for (int b = 0; b < 4; ++b) {
float4x4 boneMat = BoneMatrices[input.boneIndices[b]];
skinnedPos += mul(boneMat, float4(morphedPos, 1.0)) * input.boneWeights[b];
skinnedNorm += mul((float3x3)boneMat, morphedNorm) * input.boneWeights[b];
}
11Explain geometric LOD selection, mesh simplification, and transition strategies that balance visual stability, attribute preservation, and performance.
Geometric Level of Detail (LOD) optimizes rendering performance by reducing mesh complexity as objects recede from the camera, balancing visual fidelity and frame rate. 1. LOD Selection: LODs should be selected using screen-space metrics (such as projected bounding sphere diameter, screen-height percentage, or projected pixel error) rather than static world-space distance to account for camera FOV and resolution changes. To prevent rapid oscillation between LODs at distance boundaries ('LOD thrashing'), hysteresis is applied by maintaining separate thresholds for switching up versus switching down. 2. Mesh Simplification: Offline generation commonly relies on Quadric Error Metrics (QEM) via iterative edge collapses. To maintain visual quality, simplification algorithms must preserve boundary silhouettes and penalize geometric distortion, as well as preserve vertex attributes (UV seams, normal splits, vertex colors, and skinning weights) by incorporating attribute error terms into the quadric metric. 3. Transition Strategies: To prevent abrupt visual 'popping', engines employ: - Dithered Crossfading / Screen-Door Stippling: Discards pixels in the pixel shader using an interleaved dither pattern (e.g., Bayer matrix), smoothly fading between LODs without requiring alpha blending or breaking early-Z. - Geomorphing: Interpolates vertex positions between adjacent LOD meshes on the GPU over a short transition window.
12What is index-buffer or vertex-cache optimization, and why does triangle order affect post-transform cache efficiency?
Vertex-cache (or index-buffer) optimization reorders the triangle indices and vertex data in a mesh to maximize hit rates in the GPU's hardware vertex caches. GPUs have two main vertex caches: 1. Post-Transform Cache: A small FIFO/LRU cache storing transformed vertex shader outputs (positions, attributes). When adjacent triangles share vertices, referencing those vertices closely in the index stream allows the GPU to reuse cached shader outputs instead of running the vertex shader multiple times for the same vertex. 2. Pre-Transform Cache: The GPU's L1/L2 memory cache for raw vertex buffer data. Reordering vertex buffer data to match the first-access order of optimized indices maximizes spatial locality and memory bandwidth efficiency. Triangle order directly determines the access sequence in the post-transform cache. Optimization algorithms (such as Tom Forsyth's algorithm or Tipsify) assign dynamic reuse scores to vertices based on valence and cache position, prioritizing triangles that complete remaining references to recently cached vertices to minimize the Average Cache Miss Ratio (ACMR).
float calculateVertexScore(int cachePosition, int remainingValence) {
if (remainingValence == 0) return -1.0f;
float score = 0.0f;
if (cachePosition >= 0) {
if (cachePosition < 3) {
score = 0.75f; // Recent vertex in cache (bonus for immediate reuse)
} else {
score = std::pow(1.0f - (cachePosition - 3) / 29.0f, 1.5f); // Gradual falloff
}
}
// Bonus for vertices with few remaining triangles (clearing valence faster)
score += 2.0f * std::pow(remainingValence, -0.5f);
return score;
}
13What occlusion culling approaches avoid CPU-GPU stalls and incorrect popping?
Traditional hardware occlusion queries cause synchronous CPU-GPU readback stalls if the CPU waits for visibility results within the same frame. Delaying readbacks by one frame avoids stalls but introduces temporal latency, causing visible popping when newly visible objects are not rendered immediately. To avoid both CPU-GPU stalls and visual popping, modern production architectures use: 1. Two-Phase GPU-Driven Hi-Z Occlusion Culling: The GPU tests bounding boxes against a Hierarchical-Z (Hi-Z) depth pyramid generated from the previous frame. Objects known to be visible are drawn in Phase 1 (generating the current frame's initial depth). Previously occluded objects are re-tested against the updated current-frame Hi-Z buffer in Phase 2; any newly revealed objects are rendered immediately before lighting and post-processing, eliminating popping with zero CPU readbacks. 2. CPU Software Rasterization: A low-resolution depth buffer is rasterized purely on CPU worker threads (using SIMD) from simplified occluder meshes. The CPU tests bounding boxes synchronously without needing GPU queries or incurring GPU-to-CPU transfer latency. 3. Conservative Bounding and Temporal Hysteresis: Expanding bounding volumes or delaying visibility state demotions avoids premature culling during rapid camera movement.
// Phase 1: Render instances visible in the previous frame
[numthreads(64, 1, 1)]
void Phase1_CullCS(uint id : SV_DispatchThreadID) {
if (id >= totalInstances) return;
Instance inst = instances[id];
if (wasVisibleLastFrame[id] && TestHiZ(inst.bounds, prevFrameHiZ)) {
AppendDraw(phase1DrawBuffer, inst);
currentVisibility[id] = true;
}
}
// [Phase 1 draws -> depth buffer written -> Hi-Z updated for current frame]
// Phase 2: Test previously occluded objects against updated Hi-Z to avoid popping
[numthreads(64, 1, 1)]
void Phase2_CullCS(uint id : SV_DispatchThreadID) {
if (id >= totalInstances) return;
if (!currentVisibility[id] && TestHiZ(instances[id].bounds, currentFrameHiZ)) {
AppendDraw(phase2DrawBuffer, instances[id]);
currentVisibility[id] = true;
}
}
14Describe a typical asset processing pipeline from authored mesh to runtime GPU buffers, including tangent generation, quantization, validation, and optimization.
A standard asset processing pipeline transforms raw authored DCC meshes (FBX, glTF, USD) into high-performance, GPU-ready binary formats through five main stages: 1. Ingestion and Validation: The source mesh is sanitized by removing duplicate or unused vertices, discarding degenerate/zero-area triangles, verifying manifold geometry, handling NaNs, and splitting multi-material meshes into distinct sub-meshes. 2. Tangent Space Generation: Tangents and bitangents are computed using standardized algorithms (primarily MikkTSpace) to guarantee visual parity with normal baking tools. This properly accounts for UV seams and mirrored UV charts (storing handedness in tangent.w). 3. Optimization: Indices are reordered for post-transform vertex cache efficiency (e.g., Forsyth/Tipsify), vertex buffers are reordered for pre-transform vertex fetch locality, and LOD levels or meshlets are generated. 4. Quantization and Attribute Packing: Vertex attributes are quantized to reduce memory footprint and memory bandwidth: positions to 16-bit half/unorm or normalized integers, normals and tangents to 8-bit SNORM or octahedral encodings (Oct16/Oct32), and UVs to 16-bit floats/unorm. Attributes may be interleaved (AoS) or split into multiple streams (SoA, e.g., position-only for depth pre-passes). 5. Cooking and Serialization: Buffers, bounding volumes (AABBs/spheres), and LOD tables are serialized into flat binary files requiring zero runtime pointer patching, enabling fast DMA upload to GPU buffers via staging memory.
// Compress a float3 normal into 2D octahedral coordinates (8-bit SNORM each)
vec2 OctEncode(vec3 n) {
n /= (abs(n.x) + abs(n.y) + abs(n.z));
vec2 oct = (n.z >= 0.0) ? n.xy : (1.0 - abs(n.yx)) * sign(n.xy);
return oct * 0.5 + 0.5;
}
// Stored as 2x 8-bit unorm/snorm (2 bytes vs 12 bytes float3)
15Explain meshlets, cluster culling, mesh shaders, and dense micro-geometry pipelines for large static scenes.
Meshlet pipelines and dense micro-geometry architectures (such as Unreal's Nanite) replace large index-buffered draw calls with small, bounded geometry clusters called 'meshlets'. 1. Meshlets: A meshlet is a cluster of geometry typically constrained to 32–128 vertices and up to 128–256 triangles. Each meshlet contains local vertex indices, attribute streams, and precomputed bounding data (a bounding sphere and a normal cone). 2. Mesh and Amplification Shaders: They replace the fixed-function vertex, primitive assembly, and geometry shader pipeline. Amplification (Task) Shaders evaluate cluster-level frustum, occlusion, and normal-cone back-face culling across groups of meshlets. Surviving meshlets dispatch Mesh Shaders, where a threadgroup cooperatively transforms vertices in on-chip Shared Memory (LDS) and directly outputs primitive indices to the rasterizer. 3. Dense Micro-Geometry Pipelines: High-density geometry produces sub-pixel triangles that suffer from severe quad-overdraw (where standard hardware rasterizes 2x2 pixel helper quads, executing full pixel shaders for only 1 covered pixel). Modern dense micro-geometry systems use hierarchical cluster LOD structures (DAGs) to dynamically select cluster LODs ensuring ~1-pixel edge lengths, and often combine hardware rasterization for large polygons with custom compute software rasterizers for sub-pixel micro-polygons.
#define MAX_VERTS 64
#define MAX_PRIMS 128
struct MeshletPayload { uint meshletIndices[32]; };
[outputtopology("triangle")]
[numthreads(32, 1, 1)]
void MainMS(
in uint gtid : SV_GroupThreadID,
in uint gid : SV_GroupID,
in payload MeshletPayload payloadData,
out vertices VertexOutput outVerts[MAX_VERTS],
out indices uint3 outIndices[MAX_PRIMS]
) {
uint meshletId = payloadData.meshletIndices[gid];
Meshlet m = meshlets[meshletId];
SetMeshOutputCounts(m.vertexCount, m.primitiveCount);
// Cooperatively transform vertices
for (uint v = gtid; v < m.vertexCount; v += 32) {
outVerts[v] = TransformVertex(m.vertexOffset + v);
}
// Output local triangle indices
for (uint p = gtid; p < m.primitiveCount; p += 32) {
outIndices[p] = GetMeshletTriangle(m.triangleOffset + p);
}
}