<p><em>&quot;Go not to the CG Elves for counsel for they will say both no and yes&quot;.</em></p>
<p>Yes and No. As noted in another post, these issues don't exist with ray tracing but I'll assume you are interested in standard rasterisation.</p>
<ul>
<li><p>It's possible to dispose of near clipping by using homogeneous rendering but that can introduce additional cost. (e.g more expensive triangle set up, more difficulty in identifying which screen regions are covered in tile-based renderers)</p>
</li>
<li><p>You could eliminate XY clipping by using float representations for the X and Y coordinates in the rasteriser <em>but</em> that can lead to catastrophic cancellation when computing triangle determinants which, AFAICS, is a necessary step. In my experience, hardware rasterisers* usually work in fixed-point so that everything is 'exact'.</p>
</li>
<li><p>As a compromise to XY clipping, guard-band clipping was introduced so that clipping only needs to be done on triangles that extend a 'long'** way off screen. Culling, however, is still be done with the standard frustum planes to eliminate those that are trivially off-screen.</p>
</li>
</ul>
<p>*Dreamcast being a notable exception.</p>
<p>**for certain definitions of 'long', e.g. a small integer multiple of the screen width/height.</p>

CC BY-SA 3.0
2016-09-22T18:42:19.030Z
Since comments were cleared theres nolonger a link.
joojaa
CC BY-SA 3.0
2016-09-22T22:16:47.903Z
@joojaa even after the comment was auto-deleted, the linked question still shows in the "linked" section at the top right of this page. Since that's easy to miss I've added a comment with the link too.
trichoplax is on Codidact now
CC BY-SA 3.0
2016-09-23T04:00:45.753Z
I still don't know how I can deal with internal register overflow problem. For example, we adopt a world window whose x coordinate from 0~1023, that's a 10 digits binary. While scanning, a line whose x coordinates exceeds the 1023 will have more than 10 digits, then the extra part will be ignored,  right? So this line will be display in 0~1023 area. How can I deal with this ?
zfb
CC BY-SA 3.0
2016-09-23T08:11:59.063Z
@zfb Just as an aside, typically  HW rasterisers will have, say, an additional 4 to 8 bits of sub-pixel precision to allow smoother animation.  As for raster scanning, you'd only start/end on pixels inside the window. Out of curiosity are you writing a software rasteriser?
Simon F
CC BY-SA 3.0
2016-09-23T13:20:25.837Z
I am still studying this, no creation...
zfb
CC BY-SA 3.0
2016-09-22T12:56:43.040Z
2016-09-22T12:56:43.040Z
2020-06-18T08:32:12.800Z
Simon F
<p>I know in computer graphic, we can set a world window in world coordinate system, and then mapping it to viewport which is the display window. Things that are not in the world window should not be displayed and we can do this through Clipping (like in OpenGL). I have a question that do we have alternative methods?  </p>

CC BY-SA 3.0
2016-09-22T22:15:20.343Z
[Related](http://computergraphics.stackexchange.com/questions/2310/could-we-dispense-the-near-clipping-plane)
trichoplax is on Codidact now
<clipping>
Alternatives to Clipping in avoiding display problem
zfb
# Alternatives to Clipping in avoiding display problem

(Asked by: username_0 on 2016-09-20)

I know in computer graphic, we can set a world window in world coordinate system, and then mapping it to viewport which is the display window. Things that are not in the world window should not be displayed and we can do this through Clipping (like in OpenGL). I have a question that do we have alternative methods?

**Tags:** clipping

> **Comments:**
> **username_1**: [Related](http://computergraphics.stackexchange.com/questions/2310/could-we-dispense-the-near-clipping-plane)  

---

## 1 answers

### Answer by username_2 on 2016-09-22. Score: 4

*"Go not to the CG Elves for counsel for they will say both no and yes".*

Yes and No. As noted in another post, these issues don't exist with ray tracing but I'll assume you are interested in standard rasterisation.

* It's possible to dispose of near clipping by using homogeneous rendering but that can introduce additional cost. (e.g more expensive triangle set up, more difficulty in identifying which screen regions are covered in tile-based renderers)
* You could eliminate XY clipping by using float representations for the X and Y coordinates in the rasteriser *but* that can lead to catastrophic cancellation when computing triangle determinants which, AFAICS, is a necessary step. In my experience, hardware rasterisers\* usually work in fixed-point so that everything is 'exact'.
* As a compromise to XY clipping, guard-band clipping was introduced so that clipping only needs to be done on triangles that extend a 'long'\*\* way off screen. Culling, however, is still be done with the standard frustum planes to eliminate those that are trivially off-screen.

\*Dreamcast being a notable exception.

\*\*for certain definitions of 'long', e.g. a small integer multiple of the screen width/height.

> **Comments:**
> **username_3**: Since comments were cleared theres nolonger a link.  
> **username_1**: @username_3 even after the comment was auto-deleted, the linked question still shows in the "linked" section at the top right of this page. Since that's easy to miss I've added a comment with the link too.  
> **username_0**: I still don't know how I can deal with internal register overflow problem. For example, we adopt a world window whose x coordinate from 0~1023, that's a 10 digits binary. While scanning, a line whose x coordinates exceeds the 1023 will have more than 10 digits, then the extra part will be ignored,  right? So this line will be display in 0~1023 area. How can I deal with this ?  
> **username_2**: @username_0 Just as an aside, typically  HW rasterisers will have, say, an additional 4 to 8 bits of sub-pixel precision to allow smoother animation.  As for raster scanning, you'd only start/end on pixels inside the window. Out of curiosity are you writing a software rasteriser?  
> **username_0**: I am still studying this, no creation...  

---

