From: terje.mathisen@nospicedham.tmsw.no   
      
   R.Wieser wrote:   
   > Terje,   
   >   
   >> but in my own code I had the special case that frustrum would always be   
   >> rectangular   
   >   
   > Thats what I'm having.   
   >   
   >> so the code was simple enough:   
   > [snip]   
   >   
   > Which is pretty-much what I ended up with too.   
   >   
   >> An alternative is to classify each coordinate into one of 9 bins,   
   >   
   > And thats pretty-much the problem : what does it give that a simple "if (x1   
   > < Left and x2 < Left) or (x1 > Right and ....") comparision doesn't provide.   
      
   One key issue is that you can generate all those classifications in   
   parallel, so it could all be done in a cycle or two, replacing a bunch   
   of distributed/replicated if (a <= b) tests.   
   >   
   >> For the remaining cases apply the parts of the first algorithm that makes   
   >> sense for each case, i.e. only the full diagonals (from 0 to 8 or 2 to 6)   
   >> need all the clipping operations   
   >   
   > So, trying to skip certain checks depending on which zones the start and   
   > endpoints are in ?   AFAICS that won't work, as the exact clipping action is   
   > dependant on where, in those corner zones, the start and endpoints are.   
      
   Absolutely right, but it still helps: If we number the zones from 0 to   
   8, top left to bottom right, and neither end point is in the first   
   (0..2) row, then we can skip all clip tests against the top of the   
   frustrum. Similarly with any other side of the target zone.   
      
   When both end points are in the same row or column we get to either   
   trivially discard, or limit clipping to one dimension.   
   >   
   > Assuming a diagonal line than if it starts above the clipwindow diagonal the   
   > top-boundary clip should be taken.  If it starts below the diagonal the   
   > left-boundary should be taken.    It gets complicated when a line is not at   
   > a diagonal angle, or when only the start or endpoints are in those corner   
   > zones ...   
      
   I believe my own code ignores the order clips should occur in, i.e. a   
   diagonal line passing the top and right boundaries can be clipped   
   against those two lines in arbitrary order and still come out correct,   
   we don't need to figure out up front if anything will be visible or not.   
   >   
   > I have got zero proof, but somehow I get the feeling that such checks could   
   > easily become more expensive than a duplicated clipping or two.   
      
   I agree.   
   >   
   >   
   > tl;dr:   
   > The thing is that the Cohen-Sutherland algorithm seems to make the whole   
   > thing more complicated (and costly in the sense of total instructions - even   
   > in pseudo-code) than what you and I ended up with. And that does not make   
   > any sense.  As such I came to the conclusion I must be missing something in   
   > that algorithm.  The question is, what ?   
      
   I'm assuming this was intended for HW implementation where it is easy to   
   have enough parallel resources to perform all those operations more or   
   less at the same time.   
      
   With modern SIMD hardware we also want as many of the comparisons to   
   happen at the same time as we can manage.   
      
   Terje   
      
   --   
   -    
   "almost all programming can be viewed as an exercise in caching"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)