Convert figure images to markdown
This commit is contained in:
parent
307b59584f
commit
77a95ec319
115 changed files with 218 additions and 403 deletions
8
66-02.md
8
66-02.md
|
|
@ -61,8 +61,7 @@ be drawn, as shown in Figure 66.2. This may sound a lot like z-buffering
|
|||
fine for smaller moving objects, as described earlier), but there are
|
||||
crucial differences.
|
||||
|
||||
\
|
||||
**Figure 66.1** *Span generation.*
|
||||

|
||||
|
||||
By contrast with z-buffering, only visible portions of visible spans are
|
||||
scanned out pixel by pixel (although all polygon edges must still be
|
||||
|
|
@ -112,9 +111,8 @@ spans encountered thus far, always with no overlap. This approach
|
|||
involves generating all spans for each polygon in turn, with each span
|
||||
immediately being sorted, clipped, and added to the appropriate bucket.
|
||||
|
||||
\
|
||||
**Figure 66.2** *Two sets of spans sorted and clipped against one
|
||||
another.*
|
||||

|
||||
|
||||
With edge-sorting, edges are stored in x-sorted, linked list buckets
|
||||
according to their start scan line. Each polygon in turn is decomposed
|
||||
|
|
|
|||
Loading…
Reference in a new issue