Computer graphics processing and selective visual display system – Computer graphics processing – Three-dimension
Reexamination Certificate
2001-06-08
2004-02-24
Tung, Kee M. (Department: 2671)
Computer graphics processing and selective visual display system
Computer graphics processing
Three-dimension
C345S473000
Reexamination Certificate
active
06697064
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to computer graphics, and more particularly to vertex processing in a graphics pipeline.
BACKGROUND OF THE INVENTION
Conventional vertex processing for three-dimensional (3-D) graphics programming application program interfaces (APIs) such as Open Graphics Library (OpenGL®) and D3D™ provide support for per-vertex lighting, position transformation, and texture coordinate generation. The computations provided by such conventional vertex processing are routinely implemented by 3-D graphics hardware that greatly accelerates these operations.
One drawback of the aforementioned conventional vertex processing is that it is configurable, but not programmable. When using conventional vertex processing, an application can enable and disable various options, set transformation matrices, lighting, and texture coordinate generation parameters. However, such applications are limited to the set of computations provided by the conventional vertex processing feature set.
While the feature set has been gradually extended over time to support multiple texture units, and more texture coordinate generation modes and vertex blending schemes, the conventional vertex processing model is still fundamentally configurable, not programmable.
Conventional vertex processing assigns names to per-vertex quantities such as “position”, “color”, and “surface normal”. These names convey a sense of how the quantities are processed by conventional vertex processing. For example, surface normals are used for lighting vertices. The quantities' meaning is directly tied to the operations performed with the quantity by conventional vertex processing. Similarly, other quantities such as “light position”, “light color”, and “modelview matrix” are named to convey how these quantities are used by conventional vertex processing.
Existing applications use API commands named based on the conventions of conventional vertex processing. For example, a vertex may be set in the manner shown in Table 1.
TABLE 1
glNormal3f(xnor, ynor, znor);
glColor3f(red, green, blue);
glVertex3f(xpos, ypos, zpos);
Named 4×4 matrix transforms are specified and manipulated in the manner shown in Table 1A, in accordance with conventional vertex processing conventions.
TABLE 1A
glMatrixMode(GL_MODELVIEW);
glLoadMatrix(matrix);
glRotatef(degrees, x, y, z);
glTranslatef(xtrans, ytrans, ztrans);
In contrast with conventional vertex processing, application-programmable vertex processing has no pre-existing meaning for the quantities used to process vertices. Instead, there is simply a predetermined amount of numbered per-vertex quantities (per-vertex variables) and a predetermined amount of state numbered quantities (per-vertex constants). How these quantities are used to process the vertices depends on the application-supplied vertex program's instruction sequence.
For example, a vertex may be set in the manner set forth in Table 1B.
TABLE 1B
glVertexAttrib3fNV(2, xnor, ynor, znor);
glVertexAttrib3fNV(3, red, green, blue);
glVertexAttrib3fNV(0, xpos, ypos, zpos);
A 4×4 matrix cannot be loaded as a single entity, but rather can be loaded as 4 rows of 4-element vectors. Note Table 1C.
TABLE 1C
glVetexParameterfvNV(20, row0);
glVetexParameterfvNV(21, row1);
glVetexParameterfvNV(22, row2);
glVetexParameterfvNV(23, row3);
The fact that vertex attribute “2” represents a normal and vertex parameter “21” represents row “1” of a matrix is determined by the instruction sequence of the application-supplied vertex program.
3-D applications use 4×4 matrices to transform positions, normals, and other quantities. The matrices are typically manipulated in a hierarchical scheme using a matrix stack. The OpenGL® API provides commands for manipulating matrices and controlling various matrix stacks.
For example, to render a motorcycle, an application may manipulate the modelview matrix as set forth in Table 1D.
TABLE 1D
glMatrixMode(GL_MODELVIEW);
glPushMatrix( );
glTranslatef(car.xtrans, car.ytrans, car.ztrans);
glRotatef(car.angle, car.xdir, car.ydir,
car.zdir);
renderMotorCycleWithoutWheels( );
glPushMatrix( );
glTranslatef(frontWheel .xtrans, frontWheel .ytrans,
frontWheel. ztrans);
renderWheel( );
glPopMatrix( );
glpushMatrix( );
glTranslatef(backWheel .xtrans, backWheel .ytrans,
backWheel.ztrans);
renderWheel( );
aglPopMatrix( );
glPopMatrix( );
A software developer may want to adapt the rendering routine (renderMotorCycleWithoutWheels & renderWheel) to use application-programmable vertex processing. Conventional vertex processing always uses the current modelview matrix state to transform vertex positions. However, with application-programmable vertex processing, it is up to the vertex program to transform the vertices by the appropriate numbered vertex program parameters containing the modelview matrix values.
While application-programmable vertex processing provides tremendous flexibility in comparison to conventional vertex processing, 3D applications such as the example of Table 1D may, however, assign their own meaning to vertex processing quantities rather than have meanings assigned by the conventions of conventional vertex processing. This distinction between convention-specified and program-specified semantics for vertex processing quantities presents a significant hurdle to integrating application-programmable vertex processing into existing applications.
There is thus a need for a set of API features that facilitate combining application-programmable vertex processing with existing 3D applications originally authored to use conventional vertex processing.
There is a further need for API features that reduce the effort required to augment an existing 3D application to use application-programmable vertex processing.
DISCLOSURE OF THE INVENTION
A system, method and computer program product are provided for tracking a matrix during vertex processing. Initially, a request is received to track a matrix. Such matrix is identified in the request. The identified matrix is then tracked for vertex processing. In one aspect of the present embodiment, a version, type, and/or name of the matrix is identified in the request.
Also provided is a data structure stored in memory for tracking a matrix during vertex processing in the foregoing manner. Such data structure includes a command for requesting a matrix to be tracked. Further, the command includes an identifier for identifying the matrix. In use, the identified matrix is tracked for vertex processing upon execution of the command.
In various aspects of the present embodiment, the command may include a version identifier for identifying a version of the matrix. Such version may include an inverse version, a transpose version, and/or an inverse-transpose version. Still yet, the command may include a type identifier for identifying a type of the matrix. Such type may include a modelview type, a projection type, a texture type, and/or a color type. As an option, the command may further include an address identifier for identifying an address to be used while tracking of the matrix, and/or a program identifier for allowing the matrix tracking to be used during various types of graphics-related programmability beyond vertex processing.
In use, vertex data is received after which a state of at least one matrix is tracked. As such, the vertex data may be processed with a current state of the matrix. In one aspect of the present embodiment, the tracking may include assigning an identifier to each of a plurality of states associated with the matrix. As such, the identifier assigned to the current state may be indicated prior to the vertex processing.
As an option, the tracking may be selectively disabled. Further, the vertex data may be conditionally tracked based on whether the tracking is disabled. In one aspect, the state of the matrix may be maintained as a last-tracked state if the tracking is disabled. Further, the matrix may be tracked row-wise utilizing a plurality of registers.
REFERENCES:
patent: 4996666 (1991-02-01), Duluk, Jr.
paten
Glanville Robert Steven
Gold Michael I.
Kilgard Mark J.
Lindholm John Erik
Cao Huedung X.
Cooley & Godward LLP
Nvidia Corporation
Tung Kee M.
LandOfFree
System, method and computer program product for matrix... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System, method and computer program product for matrix..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System, method and computer program product for matrix... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3351931