3D clipping is automatically enabled all the time. There are two modes which can be adjusted for performance and appearance: ClipRatio and NearClipping. Please see Section 12.3.1, “Scissoring.”
3D clipping is expensive and should be avoided. Methods employed by the host application which can reduce the amount of geometry that gets clipped are a good idea. Crude visibility determination algorithms, geometric level-of-detail, and careful scene construction can help improve clipping performance dramatically.
The clipping algorithm is sensitive to large numbers and overflows. Refer to the Note on Coordinate Systems and Big Numbers in the Matrix State section for notes on how to avoid clipping problems.
Clip Ratio
The Clip Ratio feature helps the application to clip less.
Generally (when ClipRatio is set to FRUSTRATIO_1) the RSP clips to the clipping frustrum which is defined by the projection and viewing matrices (often created using guPerspective and guLookAt respectively). This is the area which is mapped by the gSPViewport command and usually corresponds to the entire frame buffer. Objects outside this area are scissored by the RDP, so clipping them is not neccessary.
The ClipRatio command can set the area which is clipped between 1 and 6 times the size of the viewing frustrum. Polygons which are completely on the screen are drawn without clipping. Polygons which are partially onscreen but completely within the enlarged frustrum are drawn without clipping (the extra portions are scissored away). Polygons which are entirely offscreen are trivially rejected (whether they are inside or outsid the frustrum). The only polygons which are clipped are the large polygons which stretch all the way from onscreen to outside the enlarged clipping boundary. There is some overhead for drawing sections of polygons which are then scissored away, but it is much smaller than the time to draw actual onscreen pixels and is usually faster than clipping.
Different values of ClipRatio can be tried to obtain the best performance. High values of ClipRatio are suspected to be associated with “texture shuffle” bugs, so if you see the texture shuffling you could try lower values of ClipRatio.
To set the ClipRatio so that the clipping frustrum is 3x the size of the screen:
gsSPClipRatio(FRUSTRATIO_3),
You can use values of FRUSTRATIO_1, FRUSTRATIO_2, ..., FRUSTRATIO_6
Near Clipping and gspF3DNoN microcode
3D clipping causes geometry which is outside of a 3D box called the “clipping Frustrum” to be clipped away (ie not rendered). The left, right, top and bottom of this clipping frustrum box correspond to the left, right, top, and bottom of the screen.
However the side facing towards the viewer and the side facing away from the viewer do not correspond to physical parts of the screen. The “far plane” is the side of the box farthest from the viewer. Objects which are farther away than this plane are not rendered. Likewise the “near plane” is the side of the box closest to the viewer.
Objects which are closer to the viewer than this plane are not rendered. The near and far clipping planes can cause visual problems. Objects which get too far away will suddenly dissappear as the cross the far clipping plane. Also, objects which get too close to the viewer will suddenly dissappear as the cross the near clipping plane.
There is a solution to these problems. The near plane problem can be partially solved by using the gspF3DNoN microcode (which is an acronym for Fast 3D No Near clipping). The gspF3DNoN microcode will not clip objects between the viewer and the near clipping plane (objects which would have been clipped away by the gspFast3D microcode). However, Z buffering will not work correctly in this area. Objects between the viewer and the near plane will hide objects which are behind the near plane, but objects between the viewer and the near plane will not correcly hide other objects between the viewer and the near plane. For this reason it is important for the application to ensure that only one object at a time comes closer to the viewer than the near plane.
There is a solution to the far plane problem too. Objects which get farther away from the viewer than the far plane visually “pop” out of view, and objects approaching the viewer “pop” into view. The Fog effect can be used to make objects gradually fade into a distant fog, or slowly appear through a distant fog, instead of popping into and out of view. Please see Section 11.8, "Vertex Fog State" for details.
Back-Face Polygon Culling
The geometry engine of the RSP implements a flexible polygon culling algorithm; either the front-facing, the back-facing, neither, or both types of polygons can be culled before rasterization.
This offers the programmer the most database flexibility. Geometry can be ordered in any direction or re-used with different culling flags in order to achieve effects such as interior surfaces, 2-sided polygons, etc.
Table 1 gsSPSetGeometryMode(unsigned int n)
| Parameter |
Values |
| n |
G_CULL_FRONT
G_CULL_BACK
G_CULL_BOTH
|
Table 2 gsSPClearGeometryMode(unsigned int n)
| Parameter |
Values |
| n |
G_CULL_FRONT
G_CULL_BACK
G_CULL_BOTH |
Volume Culling
The RCP can perform volume culling. The volume of an object is described to the RCP and the RCP only draws the object if the described volume is entirely or partially onscreen. If the volume is entirely offscreen then the display list is quickly skipped.
The volume of an object is described with a number of vertices surrounding the object. The vertices may be part of the object or not. They can be 4 vertices describing a pyramidal volume, 8 points describing a cube, or any other convex shape. These vertices should be sent to the RCP using a gSPVertex command just like regular vertices (note: you may want to turn lighting and fog off when these vertices are sent for better performance). Then the gsSPCullDisplayList command is sent. If the volume is entirely off the screen then the command acts like gsSPEndDisplayList and the rest of the display list is skipped. Otherwise the command acts as a NOOP and the display list processing continues.
Copyright © 1999
Nintendo of America Inc. All Rights Reserved
Nintendo and N64 are registered trademarks of Nintendo
Last Updated January, 1999
|
