hckrnws

Yes, exactly this -- it's a fast and convenient way for my code to just write the pixels into a spot in RAM (the CPU's RAM, not VRAM) and have those pixels end up on screen. On modern architectures this nearly always goes through a GPU, so even if you're not using the GPU to accelerate your 3D rendering/math, you gotta deal with it just to put pixels on a screen at the end of the day. So that's what wgpu does for me.

You do often need a graphics context to create the surface that displays the framebuffer.

How many hours a day over the couple months?

I also learnt with the second edition, I own the last one from 2013, it is alright.

The languages have evolved across editions, from Pascal, to C, to C and C++, and a bit of C# as well on the last one.

Naturally it misses on several new concepts, however I would assert it has quite valuable content.

You only need to clip triangles is you're worried about attribute interpolation for very large triangles. There's two ways to handle this: (1) discard (fast but not a great user experience); or, (2) primitive synthesis. Just frustum clipping is enabled by point picking in the local tile. Primitive synthesis requires some FP kung fu; but, is easiest done in barycentric space against a reverse transformed clipping rectangle. This lets you carefully control clip rounding error using either doubles or (better) fixed point. Abrash likes to use integer fixed point, but that is historical — modern fixed point can be handled with careful control of the fp unit in the mantissa. The major issue is regenerating the Z and the 1/Z values for the new vertices of the synthesized primitives. Everything else should flow down the pipe naturally, assuming a deferred attribute synthesis rasterizer.

There are examples in the open source version of my rasterizer: OpenSWR.org.

My renderer attempts always got stuck on the "should implement clipping" phase too, until I finally bit the bullet and managed to write a working one without much effort, independently "rediscovering" the Sutherland–Hodgman algorithm [1] as I found out later (googling it beforehand would've been cheating, of course).

The algorithm itself is fairly straightforward and intuitive, I think the biggest mental block is the weirdness of the projective space and working with homogeneous coordinates (actually the only frustum plane that you have to clip against in P₃(ℝ) is the front plane, the rest could be clipped after the perspective division, but no reason not to do it all at the same time while you're at it). The plane equations in the clip space are super simple, basically the six equations of the form ax + by + cz = w simplify to

  x = ±w 
  y = ±w 
  z = ±w.

Meaning, for example, that if the x coordinate of your vertex is greater than the w coordinate, that vertex is outside the right clipping plane. The Sutherland–Hodgman itself goes something like this:

  # Returns true if point is inside the half-space defined by plane
  def point_inside_plane(point, plane) -> bool:
    # single dot product, can be further simplified

  # Returns t such that the edge (p1, p2) intersects plane at lerp(t, p1, p2)
  def edge_intersect_plane(edge: (Point, Point), plane) -> float:
    # single dot product, can be further simplified

  # Given the vertices of a simple polygon and a plane,
  # returns the part of the polygon fully inside the plane 
  def clip_against_plane(poly: [Vertex], plane):
    let result: [Vertex] = []
    let [(v_1, v_2), (v_2, v_3), ..., (v_n, v_1)] = poly.edges()
    for each (v_i, v_j) of the edges:
      let i_inside = point_inside_plane(v_i, plane)
      let j_inside = point_inside_plane(n_j, plane)

      if i_inside and j_inside:
        # v_j will be pushed on the next iteration!
        result.push(v_i) 
      else if not i_inside and not j_inside:
        pass # Nothing to do!
      else:
        # One is inside, the other is not, we have to clip
        let t = edge_intersect_plane((v_i.pos, v_j.pos), plane)
        # Synthetize a new vertex straddling the plane
        let v_new = Vertex(
          pos = lerp(t, v_i.pos, v_j.pos),
          # For each vertex attribute
          attrib = lerp(t, v_i.attrib, v_j.attrib)
        )
        if i_inside:
          result.push(v_i); result.push(v_new) # discard v_j
        else:
          result.push(v_new); result.push(v_j) # discard v_i
      
   return result

Then you just call this for all the planes so that the output of one call becomes the input for the next call! The end result of this process is a convex polygon (of at most nine vertices for a triangle against six planes), which can be trivially triangulated. You can make the whole process faster by precomputing so-called outcodes which allow you to avoid clipping triangles known to be entirely outside at last one plane, or entirely inside every plane.

[1]: I. Sutherland and G. Hodgman. 1974. "Reentrant polygon clipping." Communications of the ACM, Volume 17, Issue. Available: https://dl.acm.org/doi/10.1145/360767.360802

> I jumped when the first image loaded on the page.. didn't expect that.

mbappe'?

Hey! Gustavo here. Thanks for the mention. The 3D software renderer course is still one of my favorites, even though it was one of the first ones I've published. I recently re-recorded the chapter on perspective projection matrix.

Gustavo's lectures are great! I work through his Compiler lectures now and I bought the 3D renderer course too.

Irfanview?

https://zserge.com/posts/fenster/ is what I used when I wanted "basic graphics" in a cross-platform way.

But of course that's X11 and much simpler.

> If anyone knows of a library that takes a rectangle of memory, a pixel format and places it onscreen regardless of the display environment I'd like to hear about it.

I've used SDL for this in the past.

> Not sure about Linux, too many stacks involved.

Wayland: wl_shm and that’s it for the “stack”.

Cross-platform support can be more difficult in that case, but yes it is possible.

My own knowledge of GPU rasterization may be dated, but IIRC GPUs tend to rely on guard band clipping up to a guard band threshold before using geometric clipping. The guard band clipping involves rejecting 2D coarse rasterization blocks that are fully outside of the scissor rect. This is just a quick rectangle check, but the tradeoff is that a larger guard band means more GPU time lost in over-rasterization and potential higher precision requirements for rasterization values (which could be fixed point). Beyond the guard band, the triangles are clipped in floating point against the frustum clip planes.