<story><title>Clip control on the Apple GPU</title><url>https://rosenzweig.io/blog/asahi-gpu-part-6.html</url></story><parent_chain><item><author>bob1029</author><text>Clip space is the bane of my existence. I&amp;#x27;ve been building a software rasterizer from scratch and implementing vertex&amp;#x2F;triangle clipping has turned into one of the hardest aspects. It took me about 50 hours of reading various references before I learned you cannot get away with doing this in screen space or any time after perspective divide.&lt;p&gt;It still staggers me that there is not 1 coherent reference for how to do all of this. Virtually every reference about clipping winds up with something like &amp;quot;and then the GPU waves its magic wand and everything is properly clipped &amp;amp; interpolated :D&amp;quot;. Every paper I read has some &amp;quot;your real answer is in another paper&amp;quot; meme going on. I&amp;#x27;ve got printouts of Blinn &amp;amp; Newell, Sutherland &amp;amp; Hodgman, et. al. littered all over my house right now. About 4 decades worth of materials.&lt;p&gt;Anyone who works on the internals of OGL or the GPU stack itself has the utmost respect from me. I cannot imagine working in that space full-time. About 3 hours of this per weekend is about all my brain can handle.</text></item></parent_chain><comment><author>joakleaf</author><text>Not sure if you got through clipping, but it was one of those things I had to go through first at some point in the mid 90s myself. I feel your pain, but after having implemented it about 5-10 times in various situations, variants and languages, I can promise it gets a lot easier.&lt;p&gt;In my experience it is most elegant to clip against the 6 planes of the view-frustrum in succession (one plane at a time). Preferably clipping against the near-plane first, as that reduces the set of triangles the most for subsequent clips.&lt;p&gt;Your triangles can turn into convex polygons after a clip. So it is convenient to start with a generic convex polygon vs. plane-clipping algorithm; The thing to be careful about here is that points can (and will) lie on the plane.&lt;p&gt;Use the plane equation (f(x,y,z)=ax+by+cz+d) to determine if a point is on one side, on the plane, or the other side.&lt;p&gt;It is convenient to use a &amp;quot;mask&amp;quot; to designate the side a point v=(x,y,z) is on. 
So:
  1 := inside_plane (f(x,y,z)&amp;gt;eps)
  2 := outside_plane (f(x,y,z)&amp;lt;-eps)
  3 := on_plane (f(x,y,z)&amp;gt;=eps &amp;amp;&amp;amp; f(x,y,z)&amp;lt;=eps)
Let m(v_i) be the mask of v_i.&lt;p&gt;When you go through each edge of the convex polygon (v_i-&amp;gt;v_{i+1}), you can check if you should clip the edge using the mask. I.e.:&lt;p&gt;if (m(v_i)&amp;amp;m(v_{i+1})==0 the points are on opposite side =&amp;gt; clip [determine intersection point].&lt;p&gt;Since you are just clipping to the frustrum, just return a list of the points that are inside or on the plane (i.e. m(v_i)&amp;amp;1==1) and the added intersection points.&lt;p&gt;There are lots of potential for optimization, of course, but I wouldn&amp;#x27;t worry about that. There are lots of other places to optimize a software rasterizer with more potential, in my experience.</text></comment>
<story><title>Clip control on the Apple GPU</title><url>https://rosenzweig.io/blog/asahi-gpu-part-6.html</url></story><parent_chain><item><author>bob1029</author><text>Clip space is the bane of my existence. I&amp;#x27;ve been building a software rasterizer from scratch and implementing vertex&amp;#x2F;triangle clipping has turned into one of the hardest aspects. It took me about 50 hours of reading various references before I learned you cannot get away with doing this in screen space or any time after perspective divide.&lt;p&gt;It still staggers me that there is not 1 coherent reference for how to do all of this. Virtually every reference about clipping winds up with something like &amp;quot;and then the GPU waves its magic wand and everything is properly clipped &amp;amp; interpolated :D&amp;quot;. Every paper I read has some &amp;quot;your real answer is in another paper&amp;quot; meme going on. I&amp;#x27;ve got printouts of Blinn &amp;amp; Newell, Sutherland &amp;amp; Hodgman, et. al. littered all over my house right now. About 4 decades worth of materials.&lt;p&gt;Anyone who works on the internals of OGL or the GPU stack itself has the utmost respect from me. I cannot imagine working in that space full-time. About 3 hours of this per weekend is about all my brain can handle.</text></item></parent_chain><comment><author>Sharlin</author><text>I also implemented clipping in my software rasterizer a while ago and can definitely sympathize! (Although I&amp;#x27;ve written several simple scanline rasterizers in my life, this was the first time I actually bothered to implement proper clipping. I actually reinvented Sutherland–Hodgman from scratch which was pretty fun.) The problematic part is actually only the near plane due to how projective geometry works. At z=0 there&amp;#x27;s a discontinuity in real coordinates after z division, which means there can be no edges that cross from negative to positive z. Z division turns such an edge [a0, a1] into an &amp;quot;inverse&amp;quot; edge (-∞, a0&amp;#x27;] ∪ [a1&amp;#x27;, ∞) which naturally makes rendering a bit tricky. In projective&amp;#x2F;homogenous coordinates, however, it is fine, because the space &amp;quot;wraps around&amp;quot; from positive to negative infinity. All the other planes you can clip against in screen space &amp;#x2F; NDC space if you wish, but I&amp;#x27;m not sure there are good reasons to split the job like that.</text></comment>