CG SET common mistakes
CG SET · Understand the traps and how to avoid them.
Computing the normal matrix as the same 3x3 upper-left block used for transforming positions, then using it to transform normals under non-uniform scaling or shear.
Candidates memorize 'normals transform like vectors' and forget that normals are covectors; under non-uniform scale the inverse-transpose is required, and a scaled normal silently tilts surfaces so lighting looks plausible but wrong.
What to do instead
Derive the requirement once: for a tangent vector t with n·t=0, the transformed normal must be (M^-1)^T n. Practice a worked example with scale (2,1,1) showing the naive transform fails the orthogonality test, and always test n·t≈0 after transforming.
Treating the viewport transform and perspective divide as commutative, dividing by w before the viewport/scissor stage or forgetting that clipping must happen in homogeneous space before division.
The pipeline is usually learned as a list of stages without the invariant that clipping precedes the divide; candidates then clip in NDC and get artifacts for geometry crossing the near plane, or misplace the depth range mapping.
What to do instead
Write the pipeline as a single chain of matrices and explicitly annotate where w is still meaningful: clip space (before divide) → NDC (after divide) → window. Do a numerical check with a vertex behind the eye to confirm the divide would flip signs and that clipping must precede it.
Applying the rendering equation but dropping the cosine or the 1/pi normalization for Lambertian BRDFs, or double-counting the cosine in both the BRDF and the integral.
Textbooks vary in whether the cosine is folded into the BRDF or left in the integral; candidates mix conventions across shading models and get energy that is off by factors of pi, which is hard to spot visually.
What to do instead
Adopt one convention explicitly (cosine in the integral, BRDF = albedo/pi) and verify with the white-furnace test: integrate a constant environment over the hemisphere and confirm the result equals albedo. Re-derive the diffuse BRDF normalization from the requirement that it integrates to albedo.
Assuming mipmap level selection is a function of distance to camera rather than of screen-space derivative of texture coordinates, and ignoring anisotropic footprints.
Introductory material often phrases mipmapping as 'farther = blurrier', so candidates never connect the LOD formula to du/dx and dv/dy, and cannot explain over-blur at grazing angles.
What to do instead
Memorize LOD = log2(max(|du/dx|,|dv/dy|)·textureSize) and hand-compute it for a floor plane at a grazing angle to see the max() over-blur. Then state how anisotropic filtering and EWA address the elongated footprint.
Claiming a B-spline interpolates its control points, or confusing degree with number of control points when computing knot vector size and continuity.
Bezier curves do interpolate endpoints, and candidates overgeneralize; the terminology (order vs degree, knot multiplicity vs continuity) is dense and rarely practiced numerically.
What to do instead
Fix the facts with a small table: for a degree-p B-spline with n+1 control points, the knot vector has n+p+2 entries; continuity at a knot of multiplicity m is C^(p-m). Verify with a quadratic example and check endpoint interpolation only for clamped knots.
Integrating rigid-body motion with explicit Euler and a fixed timestep, then asserting the simulation is stable because the result 'looks fine' at the chosen step size.
Candidates conflate accuracy with stability and never analyze the update's amplification factor; explicit Euler on a spring is unstable for any step above the stability limit regardless of visual plausibility.
What to do instead
Derive the stability condition for the damped spring: explicit Euler requires h < 2/omega (undamped) and is unconditionally unstable for negative damping. Demonstrate with a stiffness sweep, then compare semi-implicit Euler and implicit integration.
Describing the GPU pipeline as fully programmable, or placing the rasterizer and depth test inside the shader stages when reasoning about where work happens.
API-level shader writing hides the fixed-function stages, and candidates never build a mental model of the order of primitive assembly, clipping, rasterization, and per-fragment operations.
What to do instead
Draw the pipeline from vertex fetch to framebuffer with fixed-function stages marked, and place early-Z, blending, and stencil explicitly. Then trace one triangle through it and state which stages are programmable in a modern API.
Performing lighting math in sRGB-encoded values, or converting gamma incorrectly by applying the 2.2 power to the wrong side of the operation.
Textures and framebuffers are usually stored encoded, and candidates treat the stored numbers as linear; the direction of the encode/decode is easy to invert and errors look like 'slightly washed out' rather than obviously broken.
What to do instead
State the convention: decode sRGB to linear before lighting (approximately x^2.2), encode on output (approximately x^(1/2.2)). Test with mid-gray 0.5: linear ≈ 0.214, and confirm a white-furnace render of a 0.5 albedo surface returns 0.5 after encoding.
Treating a student's incorrect but working-looking render as a code bug and rewriting the student's implementation instead of diagnosing the underlying misconception.
Studio and teaching candidates default to debugging mode; fixing the artifact removes the evidence and leaves the conceptual error (for example, a transposed matrix) intact for the next assignment.
What to do instead
Use a diagnostic sequence: ask the student to predict the output for a minimal case, have them compare prediction to result, and locate the divergence. Only then address the concept, and require the student to make the correction themselves.
Reusing a downloaded shader, model, or texture in coursework or a portfolio piece without checking its license, or citing a tutorial rather than the original source.
Asset pipelines make copying frictionless and licenses are rarely surfaced in the UI; candidates assume 'freely available' means 'freely reusable' and do not distinguish code licenses from asset licenses.
What to do instead
Keep an asset provenance log recording source URL, author, license, and any modification for every non-original asset. Before submission, verify each license permits the intended use and attribution format, and replace anything unclear with original work.