Computer Graphics | Semester 6 Complete Core Notes

Semester 6 - Page 3: Computer Graphics. 25 numbered topics, highlighted rules, worked pixel/transform/curve examples, answered exam questions, diagrams, comparison tables and three complete Python demos. General common-core guide, not an official syllabus or GUI renderer.

Previous: Semester 6 - Page 2, Compiler DesignSemester indexNext: Semester 6 - Page 4, Information Security

Run each Python block separately: Python 3, standard library only. These programs print coordinates and arithmetic, not a drawn GUI. The raster walk checks 169 bounded destinations for endpoint, length and adjacency properties; that is not a proof of every geometric raster error bound. Coordinate, rounding, color and depth conventions must be stated in a real graphics implementation.

Topic map

1. Graphics, raster and vector representation
2. Pipeline and coordinate spaces
3. Pixels, frame buffers and storage
4. Color, alpha and blending
5. DDA raster line and rounding
6. Bresenham line and integer error
7. Midpoint circle and symmetry
8. Polygon filling and scan conversion
9. Translation, scaling and homogeneous matrices
10. Rotation, pivot, reflection and shear
11. 3D transforms and normals
12. Camera and viewing
13. Orthographic and perspective projection
14. Clipping and viewport mapping
15. Line and polygon clipping methods
16. Meshes, interpolation and curves
17. Bezier curves and B-spline concepts
18. Visibility and depth precision
19. Lighting and material response
20. Flat, Gouraud and Phong shading
21. Textures, UVs, filtering and mipmaps
22. Aliasing and anti-aliasing
23. Animation, double buffering and performance
24. Rasterization, ray tracing and realism
25. Exam and practical verification

1. Graphics, raster and vector representation

Graphics turns geometric and appearance data into images. Raster stores sampled pixels; vector representation stores shape descriptions that can be rasterized.

Worked example: A triangle's vertices specify geometry; rasterization decides coverage and shading computes appearance.

Exam question: Does a vector description already specify every final display pixel?
Answer: No. Rendering/sampling and display choices affect the final grid.

2. Pipeline and coordinate spaces

A typical pipeline transforms geometry, assembles primitives, clips, rasterizes, shades and applies visibility/blending rules. Exact hardware/API stages vary.

Worked example: Model coordinates become world/view/clip coordinates, then normalized coordinates and viewport pixels.

Exam question: Does projecting a point alone prove it is visible?
Answer: No. Clipping, occlusion, coverage and rendering rules remain.

Model -> world -> view -> clip
 -> clipping -> perspective divide
 -> viewport -> raster samples
 -> shading/depth/blending

Teaching pipeline map. Clipping and occlusion are different checks.

3. Pixels, frame buffers and storage

A pixel is a sample; resolution is dimensions, not physical size. Raw storage depends on channels, bit depth, padding and format; compressed file size is different.

Worked example: 800x 600 RGB at 8 bits/channel uses 1440000 bytes before padding; RGBA uses 1920000 bytes.

Exam question: Can JPEG file size be calculated by raw RGB byte count alone?
Answer: No. Compression and metadata alter stored size.

4. Color, alpha and blending

RGB channels describe color under a stated color space. Alpha commonly describes opacity/coverage; straight and premultiplied alpha require matching blend conventions.

Worked example: For straight-alpha source-over on opaque background, color=alpha*source+(1-alpha)*background under the chosen representation.

Exam question: Does numeric RGB arithmetic always correspond to linear light?
Answer: No. Color encoding/gamma affects physically meaningful blending.

5. DDA raster line and rounding

DDA samples incremental coordinates along a line. Rounding and endpoint policy determine exact pixel choices; floating-point steps can introduce rounding effects.

Worked example: Line(0, 0) to(4, 2) with positive half-up ties selects(0, 0), (1, 1), (2, 1), (3, 2), (4, 2).

Exam question: Must every line algorithm choose identical pixels at ties?
Answer: No. State and use a consistent tie convention.

6. Bresenham line and integer error

Bresenham chooses grid steps using an integer error accumulator. General implementations handle octants, signs and endpoint reversal with explicit tie rules.

Worked example: Our demo prints a slope 1/2 line and checks adjacency/endpoints for 169 bounded destinations.

Exam question: Does integer arithmetic alone prove a rasterizer is correct for every edge case?
Answer: No. Test vertical, negative, steep, zero-length and boundary/tie behavior.

Integer raster walk and bounded adjacency checks

def line(x0, y0, x1, y1):
    points = []
    dx, dy = abs(x1-x0), -abs(y1-y0)
    sx, sy = (1 if x0 < x1 else -1), (1 if y0 < y1 else -1)
    error = dx + dy
    while True:
        points.append((x0,y0))
        if (x0,y0) == (x1,y1): return points
        twice = 2*error
        if twice >= dy: error += dy; x0 += sx
        if twice <= dx: error += dx; y0 += sy
print("line:", line(0,0,4,2))
checked = 0
for x in range(-6,7):
    for y in range(-6,7):
        points = line(0,0,x,y)
        assert points[0] == (0,0) and points[-1] == (x,y)
        assert len(points) == max(abs(x),abs(y))+1
        assert all(max(abs(a-c),abs(b-d)) == 1 for (a,b),(c,d) in zip(points,points[1:]))
        checked += 1
print("destinations checked:", checked)
print("Checks endpoints/length/adjacency, not every geometric error bound.")

Checked output:

line: [(0, 0), (1, 1), (2, 1), (3, 2), (4, 2)]
destinations checked: 169
Checks endpoints/length/adjacency, not every geometric error bound.

7. Midpoint circle and symmetry

Midpoint methods exploit circle symmetry to choose nearby pixels using a decision parameter. Mirror arc points across axes/diagonals and deduplicate symmetry coincidences.

Worked example: A point(x, y) can contribute up to eight symmetric points; x=0 or x=y gives duplicates.

Exam question: Why not count eight unique pixels for every generated circle point?
Answer: Special axis/diagonal points coincide under symmetry.

8. Polygon filling and scan conversion

Polygon fill rules decide interior coverage; scanline methods intersect edges and fill spans. Vertex handling and edge inclusion must be consistent.

Worked example: A shared triangle edge needs a defined coverage rule to avoid gaps/double coverage in rasterization.

Exam question: Can boundary equality be chosen independently for each adjacent triangle?
Answer: Not safely. Inconsistent rules can create seams or double processing.

9. Translation, scaling and homogeneous matrices

Homogeneous coordinates let translation share matrix composition with affine transforms. State row/column-vector convention; transform order is not commutative.

Worked example: Using column vectors, rotation then translation is T*R*p; the rightmost matrix acts first.

Exam question: Does writing the same matrices in reverse preserve the result?
Answer: Generally no. Composition order changes geometry.

10. Rotation, pivot, reflection and shear

Rotation about origin uses sine/cosine; pivot rotation translates to origin, rotates, then translates back. Reflection and shear have different matrices/effects.

Worked example: Rotate(2, 1) +90 degrees counterclockwise to(-1, 2), then translate(3, 4) to(2, 6); reversed order gives(-5, 5).

Exam question: Does a screen y-axis pointing down preserve visual CCW interpretation unchanged?
Answer: No. Coordinate conventions change the displayed angle direction.

Point (2,1)
 R90 -> (-1,2)
 T(3,4) -> (2,6)
Reverse: (2,1) -> (5,5) -> (-5,5)

Rotation and translation do not generally commute.

Exact 90-degree transform order and Bezier midpoint

def rotate90(point): return (-point[1], point[0])
def translate(point, shift): return (point[0]+shift[0], point[1]+shift[1])
point, shift = (2,1), (3,4)
print("rotate then translate:", translate(rotate90(point),shift))
print("translate then rotate:", rotate90(translate(point,shift)))
p0,p1,p2 = (0,0),(2,2),(4,0)
t = 0.5
midpoint = tuple((1-t)**2*a+2*(1-t)*t*b+t*t*c for a,b,c in zip(p0,p1,p2))
print("Bezier midpoint:", midpoint)
print("raw RGB bytes:", 800*600*3)
print("raw RGBA bytes:", 800*600*4)

Checked output:

rotate then translate: (2, 6)
translate then rotate: (-5, 5)
Bezier midpoint: (2.0, 1.0)
raw RGB bytes: 1440000
raw RGBA bytes: 1920000

11. 3D transforms and normals

Model/view transforms position geometry; normals require appropriate transformation, especially under nonuniform scale. Normalize directions used by lighting models.

Worked example: Nonuniform scaling can make transformed tangent directions incompatible with a naive same-matrix normal transform; inverse-transpose is used under suitable invertible transforms.

Exam question: Can every normal be transformed exactly like a position vector?
Answer: No. Normal direction constraints and homogeneous translation handling differ.

12. Camera and viewing

A view transform expresses the scene relative to camera position/orientation. Camera movement and object movement must follow the chosen coordinate conventions.

Worked example: Moving the camera right changes how a fixed object appears in view coordinates; it does not rewrite the object's world identity.

Exam question: Is view transform identical to projection?
Answer: No. Viewing positions/orients the scene; projection maps the view volume.

13. Orthographic and perspective projection

Orthographic projection lacks depth-based scale change; perspective divides by a homogeneous depth-related coordinate under its convention. API depth/sign ranges differ.

Worked example: For a simple positive-z camera f=2, (4, 2, 8) projects to(1, 0.5). This toy convention is not every API's projection matrix.

Exam question: Can division by zero/behind-camera points be ignored safely?
Answer: No. Clipping and valid-view conventions must handle them.

Simple positive-z camera
x_screen = f*x/z
y_screen = f*y/z
(4,2,8), f=2 -> (1,0.5)

One toy projection convention. Actual APIs use specified clip/depth conventions.

14. Clipping and viewport mapping

Clipping trims/rejects primitives outside a chosen region; viewport mapping turns normalized coordinates into screen locations. Clipping differs from occlusion.

Worked example: A segment from(-2, 2) to(6, 2) clipped to 0..4 by 0..4 becomes(0, 2) to(4, 2).

Exam question: Does clipping only vertices correctly retain every partly visible primitive?
Answer: No. Intersections/primitive geometry must be handled.

15. Line and polygon clipping methods

Cohen-Sutherland uses region codes; Liang-Barsky constrains a parametric interval; polygon clipping handles successive boundaries under assumptions..

Worked example: The offline Liang-Barsky demo handles crossing, outside and degenerate inside segments for an axis-aligned rectangle.

Exam question: Do all clipping methods support every self-intersecting polygon identically?
Answer: No. Geometry and algorithm assumptions need explicit treatment.

Liang-Barsky clipping with degenerate-segment handling

def clip(a, b, bounds):
    xmin,ymin,xmax,ymax = bounds
    if xmin > xmax or ymin > ymax: raise ValueError("invalid bounds")
    dx,dy = b[0]-a[0], b[1]-a[1]
    low,high = 0.0,1.0
    for p,q in [(-dx,a[0]-xmin),(dx,xmax-a[0]),(-dy,a[1]-ymin),(dy,ymax-a[1])]:
        if p == 0:
            if q < 0: return None
            continue
        ratio = q/p
        if p < 0: low = max(low,ratio)
        else: high = min(high,ratio)
        if low > high: return None
    return ((a[0]+low*dx,a[1]+low*dy),(a[0]+high*dx,a[1]+high*dy))
for a,b in [((-2,2),(6,2)),((-2,5),(6,5)),((2,2),(2,2))]:
    print(a,b,"->",clip(a,b,(0,0,4,4)))

Checked output:

(-2, 2) (6, 2) -> ((0.0, 2.0), (4.0, 2.0))
(-2, 5) (6, 5) -> None
(2, 2) (2, 2) -> ((2.0, 2.0), (2.0, 2.0))

16. Meshes, interpolation and curves

Meshes use vertices/edges/faces, often triangles. Curves use control data and basis functions; interpolation/approximation are different promises.

Worked example: A quadratic Bezier interpolates its endpoints but generally not its middle control point.

Exam question: Does a control point always lie on the curve?
Answer: No. It can shape the curve without being interpolated.

17. Bezier curves and B-spline concepts

Quadratic Bezier uses(1-t)^2 P 0+2(1-t)t P 1+t^2 P 2. B-spline bases offer different local support/continuity under knot choices.

Worked example: For(0, 0), (2, 2), (4, 0), t=.5 gives(2, 1), not the middle control point(2, 2).

Exam question: Does changing one Bezier control point affect only one tiny local segment?
Answer: For a single Bezier segment it influences the whole segment's shape.

18. Visibility and depth precision

A depth buffer compares per-fragment depths under configured conventions. Precision, coplanar geometry and near/far setup can cause z-fighting; not every renderer uses a less-is-near test.

Worked example: Two nearly coplanar surfaces can alternate which wins due to precision; changing draw order alone is not a universal fix.

Exam question: Does a Z-buffer automatically solve every transparency problem?
Answer: No. Alpha/blending order needs additional treatment.

19. Lighting and material response

Simple ambient/diffuse/specular terms are teaching approximations. Lambert diffuse uses max(0, N dot L) for normalized directions; materials and light units/conventions matter.

Worked example: Dot product.8 with coefficient.5 gives diffuse contribution.4 before other terms.

Exam question: Can unnormalized N and L be used without changing the interpretation?
Answer: No. Their magnitudes distort the intended angular term.

20. Flat, Gouraud and Phong shading

Flat uses a face-level result; Gouraud interpolates vertex colors; Phong interpolates normals and evaluates lighting per fragment. Phong shading and the Phong reflectance model are distinct.

Worked example: A narrow specular highlight between vertices can be missed by vertex-color interpolation.

Exam question: Does Phong naming establish physically based rendering?
Answer: No. It refers to particular interpolation/lighting ideas, not full physical fidelity.

21. Textures, UVs, filtering and mipmaps

Textures map samples through coordinates; minification/magnification filtering handle different sampling scales. Mipmaps trade memory/preprocessing for reduced high-frequency aliasing.

Worked example: A distant checkerboard can shimmer without proper minification filtering and level selection.

Exam question: Does storing a higher-resolution texture alone remove distant shimmer?
Answer: No. Sampling/filtering still matters.

22. Aliasing and anti-aliasing

Aliasing occurs when sampling cannot represent high-frequency detail. Supersampling and multisampling address selected errors with extra work; they do not solve every shading/texture artifact equally.

Worked example: More coverage samples help edges, while texture minification also needs filtering.

Exam question: Does MSAA guarantee every pixel shader's internal detail is anti-aliased?
Answer: No. Its benefits and sampling behavior are specific to the pipeline.

23. Animation, double buffering and performance

Animation updates state over time; use suitable elapsed-time integration and presentation synchronization. Double buffering separates drawing from displayed buffer under the system's rules.

Worked example: Fixed movement per rendered frame runs faster at higher frame rate unless time is accounted for.

Exam question: Can measured frames per second alone establish smooth user experience?
Answer: No. Frame-time variation, latency and display synchronization matter.

24. Rasterization, ray tracing and realism

Rasterization projects primitives into samples; ray tracing follows ray-scene intersections with chosen light transport approximations. Both have accuracy/performance tradeoffs.

Worked example: A renderer can combine rasterized primary visibility and ray-based effects; a realistic-looking picture is not a measurement of physical accuracy.

Exam question: Does using ray tracing automatically remove every artifact?
Answer: No. Sampling, models, geometry and numerical issues remain.

25. Exam and practical verification

State coordinate axes, vector/matrix order, rounding/tie rule, color/depth conventions and input assumptions. Test arithmetic and inspect actual rendered pixels for visual work.

Worked example: Verify transform noncommutativity, clipping endpoints and curve samples; numeric console output is not proof of a GUI drawing.

Exam question: What belongs with every raster algorithm answer?
Answer: A trace, exact convention, example pixels, checks and limitations.

Projection and visibility

Concept	Meaning	Common error
Orthographic	No depth-size scaling	Calling it perspective
Perspective	Depth-related homogeneous divide	Ignoring zero/behind-camera handling
Clipping	Trim outside region	Confusing with hidden surfaces
Depth test	Resolve sampled visibility	Assuming all APIs use same comparison
Viewport	Map coordinates to pixels	Ignoring axis/sign convention

Worked arithmetic

Question	Calculation	Result
800x600 RGB	800*600*3	1440000 raw bytes
800x600 RGBA	800*600*4	1920000 raw bytes
Quadratic Bezier at0.5	.25P0+.5P1+.25P2	(2,1) for stated controls
Lambert example	.8*.5	0.4 before other terms
Perspective example	2*4/8, 2*2/8	(1,0.5)

Shading and sampling

Method	Idea	Limit
Flat	Face-level result	Faceted appearance
Gouraud	Interpolate vertex colors	May miss narrow between-vertex highlight
Phong shading	Interpolate normals; fragment lighting	Not automatically physically based
Mipmaps/filtering	Match texture sampling scale	Extra storage/work and conventions
MSAA	Multiple coverage samples	Not every shading artifact

Revision and practical checklist

State coordinate axes, vector/matrix convention, composition order, tie handling and color/depth rules. Calculate pixels and clipping endpoints, then inspect actual render pixels for any GUI claim. Numeric console output alone does not verify a visual renderer.

Resources and sources

Graphics tutorials support the pipeline, transforms, textures, lighting and depth rules. All diagrams and Python coordinate examples here are original.

• LearnOpenGL: coordinate systems and transforms
• transformations
• Back to semester-wise notes
• Computer Graphics Lab File: 12 tested Python programs
• Online Compiler
• Basic lighting
• Depth testing
• Textures

Previous: Semester 6 - Page 2, Compiler DesignSemester indexNext: Semester 6 - Page 4, Information Security