| Name |
| |
| NV_evaluators |
| |
| Name Strings |
| |
| GL_NV_evaluators |
| |
| Contact |
| |
| Matt Craighead, NVIDIA Corporation (mcraighead 'at' nvidia.com) |
| Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) |
| |
| Notice |
| |
| Copyright NVIDIA Corporation, 2000, 2001. |
| |
| IP Status |
| |
| NVIDIA Proprietary. |
| |
| Status |
| |
| Discontinued. |
| |
| NVIDIA no longer supports this extension in driver updates after |
| November 2002. Instead, use conventional OpenGL evaluators or |
| tessellate surfaces within your application. |
| |
| Version |
| |
| NVIDIA Date: January 3, 2003 |
| $Date$ $Revision$ |
| $Id: //sw/main/docs/OpenGL/specs/old/GL_NV_evaluators.txt#2 $ |
| |
| Number |
| |
| 225 |
| |
| Dependencies |
| |
| Written based on the wording of the OpenGL 1.2.1 specification. |
| |
| Assumes support for the ARB_multitexture extension. |
| |
| NV_vertex_program affects the definition of this extension. |
| |
| Overview |
| |
| OpenGL evaluators provide applications with the capability to |
| specify polynomial or rational curves and surfaces using control |
| points relative to the Bezier basis. The curves and surfaces are |
| then drawn by evaluating the polynomials provided at various values |
| for the u parameter of a curve or the (u,v) parameters of a surface. |
| A tensor product formulation is used for the surfaces. |
| |
| For various historical reasons, evaluators have not been |
| particularly popular as an interface for drawing curves and surfaces. |
| This extension proposes a new interface for surfaces that provides a |
| number of significant enhancements to the functionality provided by |
| the original OpenGL evaluators. |
| |
| Many implementations never optimized evaluators, so applications |
| often implemented their own algorithms instead. This extension |
| relaxes some restrictions that make it difficult to optimize |
| evaluators. |
| |
| Also, new vertex attributes have been added to OpenGL through |
| extensions, including multiple sets of texture coordinates, a |
| secondary color, a fog coordinate, a vertex weight, and others. |
| The extensions which added these vertex attributes never bothered |
| to update the functionality of evaluators, since they were used so |
| little in the first place. In turn, evaluators have become more and |
| more out of date, making it even less likely that developers will |
| want to use them. Most of the attributes are not a big loss, but |
| support for multiple sets of texture coordinates would be absolutely |
| essential to developers considering the use of evaluators. |
| |
| OpenGL evaluators only support rectangular patches, not triangular |
| patches. Although triangular patches can be converted into |
| rectangular patches, direct support for triangular patches is likely |
| to be more efficient. |
| |
| The tessellation algorithm used is too inflexible for most purposes; |
| only the number of rows and columns can be specified. Adjacent |
| patches must then have identical numbers of rows and columns, or |
| severe cracking will occur. Ideally, a number of subdivisions could |
| be specified for all four sides of a rectangular patch and for all |
| three of a triangular patch. This extension goes one step further |
| and allows those numbers to be specified in floating-point, providing |
| a mechanism for smoothly changing the level of detail of the surface. |
| |
| Meshes evaluated with EvalMesh are required to match up exactly |
| with equivalent meshes evaluated with EvalCoord or EvalPoint. |
| This makes it difficult or impossible to use optimizations such as |
| forward differencing. |
| |
| Finally, little attention is given to some of the difficult problems |
| that can arise when multiple patches are drawn. Depending on the |
| way evaluators are implemented, and depending on the orientation of |
| edges, numerical accuracy problems can cause cracks to appear between |
| patches with the same boundary control points. This extension makes |
| guarantees that an edge shared between two patches will match up |
| exactly under certain conditions. |
| |
| Issues |
| |
| * Should one-dimensional evaluators be supported? |
| |
| RESOLVED: No. This extension is intended for surfaces only. |
| |
| * Should we support triangular patches? |
| |
| RESOLVED: Yes. Otherwise, applications will have to convert |
| them to rectangular patches themselves. We can do this more |
| efficiently. |
| |
| * What domain should triangular patches be defined on? |
| |
| RESOLVED: (0,0),(1,0),(0,1). |
| |
| * What memory layout should we use for triangular patch control |
| points? |
| |
| RESOLVED: Both a[i][j], where i+j <= n, and a packed format are |
| supported. |
| |
| * Is it worth it to have "evaluator objects"? |
| |
| RESOLVED: No. We will leave these out for now. |
| |
| * Should we support the original evaluators' ability to specify |
| a map from an arbitrary (u1,v1) to an arbitrary (u2,v2)? |
| |
| RESOLVED: No. Maps will always extend from (0,0) to (1,1) |
| and will always be evaluated from (0,0) to (1,1). |
| |
| * Should the new interface support an EvalCoord-like syntax? |
| |
| RESOLVED: No. We are only interested in evaluating an entire |
| mesh at once. |
| |
| * Should we support the "mode" parameter to the existing EvalMesh2, |
| which allows the mesh to be tessellated in wireframe or as points? |
| |
| RESOLVED: No. We will leave in the parameter and require that |
| it be FILL, though, to leave room for a future extension. |
| |
| * Should there be a new interface to specify control points or should |
| Map2{fd} be reused? |
| |
| RESOLVED: A new interface. There are enough changes compared to |
| the original evaluators that we can't reuse the old interface |
| without causing more problems. For example, the target |
| parameter of Map2{fd} is really a cross of target and index |
| in MapControlPointsNV, and so it ends up creating an excessive |
| number of enumerants. |
| |
| * How should grids be specified? |
| |
| RESOLVED: A MapParameter command. This is better than a new |
| MapGrid- style command because it can be extended to include |
| new parameter types. |
| |
| * Should there be any rules about the order of generation of |
| primitives within a single patch? |
| |
| RESOLVED: No. The tessellation algorithm itself is not even |
| specified, so it makes no sense to do this. Applications must |
| not depend on the order in which the primitives are drawn. |
| |
| * Should the stride for MapControlPointsNV be specified in basic |
| machine units (i.e. unsigned bytes) or in floats/doubles? |
| |
| RESOLVED: ubytes. Most of the rest of OpenGL (vertex arrays, |
| pixel path, etc.) uses ubytes; evaluators are actually |
| inconsistent. |
| |
| * How much leeway should implementations be given to choose their own |
| algorithm for tessellation? |
| |
| RESOLVED: The integral tessellation scheme will require a |
| specific tessellation of the boundary edges of the patch, but the |
| interior tessellation is implementation-specific. The fractional |
| tessellation scheme will only require a minimum number of segments |
| along each edge. In either case, a minimum number of triangles |
| for the entire patch is specified. |
| |
| * Should there be rules to ensure that the triangles will be |
| oriented in a consistent fashion? |
| |
| RESOLVED: Yes. This is essential for features such as backface |
| culling to work properly. The rule given ensures that the |
| orientation will be identical to the orientation used for the |
| original evaluators. |
| |
| * Should there be a separate MAX_EVAL_ORDER for rational surfaces? |
| |
| RESOLVED: Yes. Rational surfaces require additional calculation to |
| be done by the implementation, especially if AUTO_NORMAL is |
| enabled. Furthermore, the most useful rational surfaces are of low |
| order. For example, all the conic sections are quadratic rational |
| surfaces. |
| |
| * Should there be enables similar to AUTO_NORMAL that generate |
| partials of U (tangents), partials of V, and/or binormals? |
| |
| RESOLVED: No. The application is responsible for configuring |
| the evaluators appropriately. |
| |
| The auto normal functionality is supported because it is fairly |
| complicated and was already a core part of OpenGL for evaluators. |
| Plus there is already a "normal" vertex attribute for it to |
| automatically generate. |
| |
| The partials of U and partials of V are fairly straightforward |
| to evaluate (just take the derivative of the bivariate polynomial |
| in terms of either U or V) plus there is not a particular vertex |
| attribute associated with each of these. |
| |
| New Procedures and Functions |
| |
| void MapControlPointsNV(enum target, uint index, enum type, |
| sizei ustride, sizei vstride, |
| int uorder, int vorder, |
| boolean packed, |
| const void *points) |
| |
| void MapParameterivNV(enum target, enum pname, const int *params) |
| void MapParameterfvNV(enum target, enum pname, const float *params) |
| |
| void GetMapControlPointsNV(enum target, uint index, enum type, |
| sizei ustride, sizei vstride, |
| boolean packed, void *points) |
| |
| void GetMapParameterivNV(enum target, enum pname, int *params) |
| void GetMapParameterfvNV(enum target, enum pname, float *params) |
| void GetMapAttribParameterivNV(enum target, uint index, enum pname, |
| int *params) |
| void GetMapAttribParameterfvNV(enum target, uint index, enum pname, |
| float *params) |
| |
| void EvalMapsNV(enum target, enum mode) |
| |
| New Tokens |
| |
| Accepted by the <target> parameter of MapControlPointsNV, |
| MapParameter[if]vNV, GetMapControlPointsNV, GetMapParameter[if]vNV, |
| GetMapAttribParameter[if]vNV, and EvalMapsNV: |
| |
| EVAL_2D_NV 0x86C0 |
| EVAL_TRIANGULAR_2D_NV 0x86C1 |
| |
| Accepted by the <pname> parameter of MapParameter[if]vNV and |
| GetMapParameter[if]vNV: |
| |
| MAP_TESSELLATION_NV 0x86C2 |
| |
| Accepted by the <pname> parameter of GetMapAttribParameter[if]vNV: |
| |
| MAP_ATTRIB_U_ORDER_NV 0x86C3 |
| MAP_ATTRIB_V_ORDER_NV 0x86C4 |
| |
| Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, |
| and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, |
| and GetDoublev: |
| |
| EVAL_FRACTIONAL_TESSELLATION_NV 0x86C5 |
| |
| EVAL_VERTEX_ATTRIB0_NV 0x86C6 |
| EVAL_VERTEX_ATTRIB1_NV 0x86C7 |
| EVAL_VERTEX_ATTRIB2_NV 0x86C8 |
| EVAL_VERTEX_ATTRIB3_NV 0x86C9 |
| EVAL_VERTEX_ATTRIB4_NV 0x86CA |
| EVAL_VERTEX_ATTRIB5_NV 0x86CB |
| EVAL_VERTEX_ATTRIB6_NV 0x86CC |
| EVAL_VERTEX_ATTRIB7_NV 0x86CD |
| EVAL_VERTEX_ATTRIB8_NV 0x86CE |
| EVAL_VERTEX_ATTRIB9_NV 0x86CF |
| EVAL_VERTEX_ATTRIB10_NV 0x86D0 |
| EVAL_VERTEX_ATTRIB11_NV 0x86D1 |
| EVAL_VERTEX_ATTRIB12_NV 0x86D2 |
| EVAL_VERTEX_ATTRIB13_NV 0x86D3 |
| EVAL_VERTEX_ATTRIB14_NV 0x86D4 |
| EVAL_VERTEX_ATTRIB15_NV 0x86D5 |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| MAX_MAP_TESSELLATION_NV 0x86D6 |
| MAX_RATIONAL_EVAL_ORDER_NV 0x86D7 |
| |
| Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation) |
| |
| None. |
| |
| Additions to Chapter 3 of the 1.2 Specification (Rasterization) |
| |
| None. |
| |
| Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations |
| and the Frame Buffer) |
| |
| None. |
| |
| Additions to Chapter 5 of the 1.2 Specification (Special Functions) |
| |
| -- NEW Section 5.7 "General Evaluators" |
| |
| "General evaluators are similar to evaluators in that they can |
| be used to evaluate polynomial and rational mappings, but general |
| evaluators have several new features that the original evaluators |
| do not. First, they support triangular surfaces in addition to |
| (quadrilateral) tensor product surfaces. Second, the tessellation |
| can be varied continuously as well as in integral steps. Finally, |
| general evaluators can evaluate all vertex attributes, not just the |
| vertex, color, normal, and texture coordinates. |
| |
| Several elements of the original evaluators have been removed in |
| the general evaluators interface. The general evaluators always |
| evaluate four components in parallel, whereas the original evaluators |
| might evaluate between 1 and 4 (see the "k" column in Table 5.1 on |
| page 165). The original evaluators can map on an arbitrary domain |
| and can map grids on an arbitrary region, whereas the general |
| evaluators only use the [0,1] range. Support for 1D evaluators, |
| an EvalCoord-style interface, and the "mode" parameter of EvalMesh* |
| has also been removed from the general evaluators. |
| |
| The command |
| |
| void MapControlPointsNV(enum target, uint index, enum type, |
| sizei ustride, sizei vstride, |
| int uorder, int vorder, boolean packed, |
| const void *points); |
| |
| specifies control points for a general evaluator map. target |
| is the type of evaluator map and can be either EVAL_2D_NV or |
| EVAL_TRIANGULAR_2D_NV. index is the number of the vertex attribute |
| register the map will be used to evaluate for; these are the same |
| indices used in the GL_NV_vertex_program extension. Table X.1 |
| shows the relationship between these indices and the conventional |
| per-vertex attributes for implementations that do not support |
| GL_NV_vertex_program. |
| |
| Vertex |
| Attribute Conventional Conventional |
| Register Per-vertex Conventional Component |
| Number Parameter Per-vertex Parameter Command Mapping |
| --------- --------------- -------------------------------------- ------------ |
| 0 vertex position Vertex x,y,z,w |
| 1 vertex weights VertexWeightEXT w,0,0,1 |
| 2 normal Normal x,y,z,1 |
| 3 primary color Color r,g,b,a |
| 4 secondary color SecondaryColorEXT r,g,b,1 |
| 5 fog coordinate FogCoordEXT fc,0,0,1 |
| 6 - - - |
| 7 - - - |
| 8 texture coord 0 MultiTexCoordARB(GL_TEXTURE0_ARB, ...) s,t,r,q |
| 9 texture coord 1 MultiTexCoordARB(GL_TEXTURE1_ARB, ...) s,t,r,q |
| 10 texture coord 2 MultiTexCoordARB(GL_TEXTURE2_ARB, ...) s,t,r,q |
| 11 texture coord 3 MultiTexCoordARB(GL_TEXTURE3_ARB, ...) s,t,r,q |
| 12 texture coord 4 MultiTexCoordARB(GL_TEXTURE4_ARB, ...) s,t,r,q |
| 13 texture coord 5 MultiTexCoordARB(GL_TEXTURE5_ARB, ...) s,t,r,q |
| 14 texture coord 6 MultiTexCoordARB(GL_TEXTURE6_ARB, ...) s,t,r,q |
| 15 texture coord 7 MultiTexCoordARB(GL_TEXTURE7_ARB, ...) s,t,r,q |
| |
| Table X.1: Aliasing of vertex attributes with conventional per-vertex |
| parameters. |
| |
| type is either FLOAT or DOUBLE. ustride and vstride are the numbers |
| of basic machine units (typically unsigned bytes) between control |
| points in the u and v directions. uorder and vorder have the same |
| meaning they do in the Map2{fd} command. The error INVALID_VALUE |
| is generated if either uorder or vorder is less than one or greater |
| than MAX_EVAL_ORDER. The error INVALID_OPERATION is generated if |
| target is EVAL_TRIANGULAR_2D_NV and uorder is not equal to vorder. |
| |
| points is a pointer to an array of control points. If target is |
| EVAL_2D_NV, there are uorder*vorder control points in the array, |
| and if it is EVAL_TRIANGULAR_2D_NV, there are uorder*(uorder+1)/2 |
| points in the array. If packed is FALSE, control point i,j is |
| located |
| |
| (ustride)i + (vstride)j |
| |
| basic machine units from points. If target is EVAL_2D_NV, i ranges |
| from 0 to uorder-1, and j ranges from 0 to vorder-1. If target is |
| EVAL_TRIANGULAR_2D_NV, i and j range from 0 to uorder-1, and i+j |
| must be less than or equal to uorder-1. |
| |
| If packed is TRUE and target is EVAL_2D_NV, control point i,j is |
| located |
| |
| (ustride)(j*uorder + i) |
| |
| basic machine units from points. If packed is TRUE and target is |
| EVAL_TRIANGULAR_2D_NV, control point i,j is located |
| |
| (ustride)(j*uorder + i - j*(j-1)/2) |
| |
| basic machine units from points. |
| |
| The error INVALID_OPERATION is generated if index is 0, one of the |
| control points' fourth components is not equal to 1, and either uorder |
| of vorder is greater than MAX_RATIONAL_EVAL_ORDER_NV. |
| |
| The evaluation of a 2D tensor product map is performed in the same |
| way as for the original evaluators. The exact coordinates produced |
| by the original evaluators may differ from those produced by the |
| general evaluators, since different algorithms may be used. |
| |
| A triangular map may be evaluated as follows. Let Ri,j be the |
| 4-component vector for control point i,j and n be the degree of the |
| patch (i.e. uorder-1). Then: |
| |
| --- |
| \ (n) (n-i) i j n-i-j |
| p_t(u,v) = / (i) ( j ) u v (1-u-v) Ri,j |
| --- |
| i,j >= 0 |
| i+j <= n |
| |
| evaluates the point p_t(u,v) on the triangular patch at parameter |
| values (u,v). (The notation on the left indicates "n choose i" and |
| "n minus i choose j", i.e., binomial coefficients.) |
| |
| The evaluation of any particular attribute can be enabled or disabled |
| with Enable and Disable using one of the EVAL_VERTEX_ATTRIBi_NV |
| constants. |
| |
| If AUTO_NORMAL is enabled (see section 5.1), analytically computed |
| normals are evaluated as well. The formula for the normal is the same |
| as the one in section 5.1, except that the magnitude of the normals is |
| undefined. These normals should be renormalized by enabling NORMALIZE, |
| or by normalizing them in a vertex program. The w of the normal |
| vertex attribute will always be 1. |
| |
| The commands |
| |
| void MapParameter{if}vNV(enum target, enum pname, T params); |
| |
| can be used to specify the level of tessellation to evaluate, |
| where target is EVAL_2D_NV or EVAL_TRIANGULAR_2D_NV and pname is |
| MAP_TESSELLATION_NV. If target is EVAL_2D_NV, params contains the |
| four values [nu0,nu1,nv0,nv1], and if it is EVAL_TRIANGULAR_2D_NV, |
| params contains the three values [n1,n2,n3]. The state for each |
| target is independent of the other. These values are clamped to |
| the range [1.0, MAX_MAP_TESSELLATION_NV]. |
| |
| The use of a fractional tessellation algorithm can be |
| enabled or disabled with Enable and Disable using the |
| EVAL_FRACTIONAL_TESSELLATION_NV constant. The fractional tessellation |
| algorithm allows the tessellation to smoothly morph without popping |
| as the tessellation parameters are varied by small amounts. |
| |
| The command |
| |
| void EvalMapsNV(enum target, enum mode); |
| |
| evaluates the currently enabled maps. target is either EVAL_2D_NV |
| or EVAL_TRIANGULAR_2D and specifies which set of maps to evaluate. |
| mode must be FILL. If EVAL_VERTEX_ATTRIB0_NV is not enabled, the |
| error INVALID_OPERATION results. |
| |
| If EVAL_FRACTIONAL_TESSELLATION_NV is disabled, tensor product maps |
| are evaluated such that the boundaries of the mesh are divided into |
| ceil(nu0) segments on the edge from (0,0) to (1,0), ceil(nu1) segments |
| on the edge from (0,1) to (1,1), ceil(nv0) segments on the edge from |
| (0,0) to (0,1), and ceil(nv1) segments on the edge from (1,0) to |
| (1,1). These segments must be evaluated at equal spacings in (u,v) |
| parameter space. |
| |
| Triangular maps are evaluated such that the boundary of the mesh from |
| (0,0) to (1,0) has ceil(n1) equally-spaced segments, the boundary |
| from (1,0) to (0,1) has ceil(n2) equally-spaced segments, and the |
| boundary from (0,1) to (0,0) has ceil(n3) equally-spaced segments. |
| |
| If EVAL_FRACTIONAL_TESSELLATION_NV is enabled, each edge must be |
| tessellated with no fewer the number of segments that would be used in |
| the non- fractional case for any values of the tessellation parameters. |
| Furthermore, the tessellation of each edge must vary smoothly with the |
| parameters; that is, a small change in any or all of the parameters |
| must cause a small change in the tessellation. Whenever a new vertex |
| is introduced into the tessellation, it must be coincident with another |
| vertex, and whenever a vertex is removed, it must have been coincident |
| with a different vertex. The parameter-space position of any vertex |
| must be a continuous function of the tessellation parameters. |
| |
| The same minimum triangle requirements apply to fractional |
| tessellations as to integral tessellations. |
| |
| A tensor product patch must always be tessellated with no fewer than |
| |
| 2 * ceil((nu0+nu1)/2) * ceil((nv0+nv1)/2) |
| |
| triangles in total. |
| |
| A triangular patch must always be tessellated with no fewer than |
| |
| ceil((n1+n2+n3)/3)^2 |
| |
| triangles in total. |
| |
| If a triangle is formed by evaluating the maps at the three |
| coordinates (u1,v1), (u2,v2), and (u3,v3), it must be true that |
| |
| (u3-u1)*(v2-v1) - (u2-u1)*(v3-v1) >= 0 |
| |
| to ensure that all triangles in a patch have a consistent |
| orientation. |
| |
| The current value of any vertex attribute for which the evaluation |
| of a map is enabled becomes undefined after an EvalMapsNV command. |
| If AUTO_NORMAL is enabled, the current normal becomes undefined as |
| well. |
| |
| If AUTO_NORMAL is enabled, the analytically computed normals take |
| precedence over the currently enabled map for vertex attribute 2 |
| (the normal). |
| |
| To prevent cracks, certain rules must be established for performing |
| the evaluations. The goal of these rules is to ensure that no |
| matter what order control points are specified in and what the |
| tessellation parameters are, so long as the control points on any edge |
| exactly match the control points of an adjacent edge, and so long as |
| the subdivision parameter for that edge is the same for the adjacent |
| patch, there will be no cracking artifacts between the two patches. |
| These requirements are completely independent of numerical precision. |
| In particular, we will require that these shared vertices' positions |
| be equal. Furthermore, there must be no cracking inside the geometry |
| of any patch, and normals must not change in a discontinuous fashion |
| so that there are no discontinuities in lighting or other effects |
| that use the normal. |
| |
| Let two patches share an edge of equal order (the order of an edge is |
| the order of the patch in that direction for a tensor product patch, |
| or the order of the patch for a triangular patch). Then this edge is |
| said to be consistent if all the vertex control points (vertex |
| attribute 0) are identical on each edge (although they may be specified |
| in the opposite direction, or even in a different coordinate; one may |
| an edge in the u direction, and one may be an edge in the v direction). |
| |
| If an edge is consistent, and if each of the two patches are |
| tessellated with identical tessellation parameters for that edge, |
| then the vertex coordinates given to vertex processing must be |
| exactly equal for each of the vertices. |
| |
| The vertex coordinates given to vertex processing for the corner |
| vertices of any patch must be exactly equal to the values of the |
| corner control points of that patch, regardless of the patch's |
| order, type, tessellation parameters, the state of the AUTO_NORMAL or |
| EVAL_FRACTIONAL_TESSELLATION_NV enables, the control points, order, |
| or enable of any other associated map, or any other OpenGL state. |
| |
| The vertex coordinates and normals given to vertex processing for |
| any vertex of a patch must be exactly equal each time that vertex |
| is evaluated during the tessellation of a patch. Since each vertex |
| is shared between several triangles in the patch, any variation in |
| these coordinates and normals would result in cracks or lighting |
| discontinuities. |
| |
| The state required for the general evaluators consists of a bit |
| indicating whether fractional tessellation is enabled or disabled, 16 |
| bits indicating whether the evaluation of each vertex attribute is |
| enabled or disabled, four floating-point map tessellation values for |
| tensor product patches, three floating-point map tessellation values |
| for triangular patches, and a map specification for a tensor product |
| patch and a triangular patch for each vertex attribute. A map |
| specification consists of two integers indicating the order of the |
| map in u and v and a two-dimensional array of vectors of four |
| floating-point values containing the control points for that map. |
| The initial state of fractional tessellation is disabled. The initial |
| state of evaluation of vertex attribute 0 is enabled, and the initial |
| state of evaluation for any other vertex attribute is disabled. The |
| initial value of the tessellation parameters is 1.0. The initial order |
| of each map specification is an order of 1 in both u and v and a |
| single control point of [0,0,0,1]." |
| |
| Additions to Chapter 6 of the 1.2 Specification (State and State Requests) |
| |
| -- NEW Section 6.1.13 "General Evaluator Queries" |
| |
| "The commands |
| |
| void GetMapParameterivNV(enum target, enum pname, int *params); |
| void GetMapParameterfvNV(enum target, enum pname, float *params); |
| |
| obtain the parameters for a map target. target may be one of |
| EVAL_2D_NV or EVAL_TRIANGULAR_2D_NV. pname must be MAP_TESSELLATION_NV. |
| The map tessellation is placed in params. |
| |
| The commands |
| |
| void GetMapAttribParameterivNV(enum target, uint index, enum pname, |
| int *params); |
| void GetMapAttribParameterfvNV(enum target, uint index, enum pname, |
| float *params); |
| |
| obtain parameters for a single map. target may be one of EVAL_2D_NV |
| or EVAL_TRIANGULAR_2D_NV. index is the number of the vertex attribute |
| register the map is used for evaluating. If pname is |
| MAP_ATTRIB_U_ORDER_NV, the u order of the map is placed in params. If |
| pname is MAP_ATTRIB_V_ORDER_NV, the v order of the map is placed in |
| params. |
| |
| The command |
| |
| void GetMapControlPointsNV(enum target, uint index, enum type, |
| sizei ustride, sizei vstride, boolean packed, |
| void *points); |
| |
| obtains the control points of a map. target may be one of EVAL_2D_NV |
| or EVAL_TRIANGULAR_2D_NV. index is the number of the vertex attribute |
| register the map is used for evaluating. type is either FLOAT or |
| DOUBLE. ustride and vstride are the numbers of basic machine units |
| (typically unsigned bytes) between control points in the u and v |
| directions. points is a pointer to an array where the control points |
| are to be written. If target is EVAL_2D_NV, there are uorder*vorder |
| control points in the array, and if it is EVAL_TRIANGULAR_2D_NV, there |
| are uorder*(uorder+1)/2 points in the array. If packed is FALSE, |
| control point i,j is located |
| |
| (ustride)i + (vstride)j |
| |
| basic machine units from points. If packed is TRUE and target is |
| EVAL_2D_NV, control point i,j is located |
| |
| (ustride)(j*uorder + i) |
| |
| basic machine units from points. If packed is TRUE and target is |
| EVAL_TRIANGULAR_2D_NV, control point i,j is located |
| |
| (ustride)(j*uorder + i - j*(j-1)/2) |
| |
| basic machine units from points. If target is EVAL_2D_NV, i ranges |
| from 0 to uorder-1, and j ranges from 0 to vorder-1. If target is |
| EVAL_TRIANGULAR_2D_NV, i and j range from 0 to uorder-1, and i+j |
| must be less than or equal to uorder-1." |
| |
| Additions to the GLX Specification |
| |
| Nine new GL commands are added. |
| |
| The following three rendering commands are sent to the sever |
| as part of a glXRender request: |
| |
| MapParameterivNV |
| 2 12+4*n rendering command length |
| 2 ???? rendering command opcode |
| 4 ENUM target |
| 4 ENUM pname |
| 0x86C2 GL_MAP_TESSELLATION_NV |
| n=3 if (target == GL_EVAL_TRIANGULAR_2D_NV) |
| n=4 if (target == GL_EVAL_2D_NV) |
| else n=0 command is erroneous |
| 4*n LISTofINT32 params |
| |
| |
| MapParameterfvNV |
| 2 12+4*n rendering command length |
| 2 ???? rendering command opcode |
| 4 ENUM target |
| 4 ENUM pname |
| 0x86C2 GL_MAP_TESSELLATION_NV |
| n=3 if (target == GL_EVAL_TRIANGULAR_2D_NV) |
| n=4 if (target == GL_EVAL_2D_NV) |
| else n=0 command is erroneous |
| 4*n LISTofFLOAT32 params |
| |
| |
| EvalMapsNV |
| 2 12 rendering command length |
| 2 ???? rendering command opcode |
| 4 ENUM target |
| 4 ENUM mode |
| |
| The following rendering command is potentially large and can be sent |
| in a glXRender or glXRenderLarge request: |
| |
| MapControlPointsNV |
| 2 24+m rendering command length |
| 2 ???? rendering command opcode |
| 4 ENUM target |
| 4 CARD32 index |
| 4 CARD32 type |
| 4 INT32 uorder |
| 4 INT32 vorder |
| m (see below) points |
| |
| Determine m from the table below; n depends on the target. If the |
| target is GL_EVAL_2D_NV, then n = uorder*vorder. If the target |
| is GL_EVAL_TRIANGULAR_2D_NV, then n = uorder * (uorder+1)/2. |
| The points data is packed such that when unpacked by the server, |
| the value of ustride is 16 for GL_FLOAT typed data and 32 for |
| GL_DOUBLE typed data. |
| |
| type encoding of type type of lists m (bytes) |
| --------- ---------------- ------------- --------- |
| GL_FLOAT 0x1406 LISTofFLOAT32 n*4 |
| GL_DOUBLE 0x140A LISTofFLOAT64 n*8 |
| |
| If the command is encoded in a glXRenderLarge request, the command |
| opcode and command length fields above are expanded to 4 bytes each: |
| |
| 4 28+m rendering command length |
| 4 ???? rendering command opcode |
| |
| The remaining five commands are non-rendering commands. These commands |
| are sent separately (i.e., not as part of a glXRender or glXRenderLarge |
| request), using the glXVendorPrivateWithReply request: |
| |
| GetMapParameterivNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 5 request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 INT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofINT32 params |
| |
| GetMapParameterfvNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 5 request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 FLOAT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofFLOAT32 params |
| |
| GetMapAttribParameterivNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 6 request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 CARD32 index |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 INT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofINT32 params |
| |
| GetMapAttribParameterfvNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 6 request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 CARD32 index |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 FLOAT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofFLOAT32 params |
| |
| GetMapControlPointsNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 6 request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 CARD32 index |
| 4 ENUM type |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m |
| 4 unused |
| 4 CARD32 uorder |
| 4 CARD32 vorder |
| 12 unused |
| |
| if type == 0x1406 (GL_FLOAT) and target == 0x86C0 |
| (GL_EVAL_2D_NV), m = 4*uorder*vorder and the packed control |
| points follow assuming ustride = 16 |
| |
| m*4 LISTofFLOAT32 params |
| |
| if type == 0x140A (GL_DOUBLE) and target == 0x86C0 |
| (GL_EVAL_2D_NV), m = 4*uorder*vorder and the packed control |
| points follow asssuming ustride = 32 |
| |
| m*8 LISTofFLOAT64 params |
| |
| if type == 0x1406 (GL_FLOAT) and target == 0x86C1 |
| (GL_EVAL_TRIANGULAR_2D_NV), m = 4*uorder*(uorder+1)/2 and |
| the packed control points follow assuming ustride = 16 |
| |
| m*4 LISTofFLOAT32 params |
| |
| if type == 0x140A (GL_DOUBLE) and target == 0x86C1 |
| (GL_EVAL_TRIANGULAR_2D_NV), m = 4*uorder*(uorder+1)/2 and |
| the packed control points follow asssuming ustride = 32 |
| |
| m*8 LISTofFLOAT64 params |
| |
| otherwise m = 0 and nothing else follows. |
| |
| Errors |
| |
| The error INVALID_VALUE is generated if MapControlPointsNV, |
| GetMapControlPointsNV, or GetMapAttribParameter{if}v is called where |
| index is greater than 15. |
| |
| The error INVALID_VALUE is generated if MapControlPointsNV |
| or GetMapControlPointsNV is called where ustride or vstride is |
| negative. |
| |
| The error INVALID_VALUE is generated if MapControlPointsNV is |
| called where uorder or vorder is less than one or greater than |
| MAX_EVAL_ORDER. |
| |
| The error INVALID_OPERATION is generated if MapControlPointsNV is |
| called where target is EVAL_TRIANGULAR_2D_NV and uorder is not equal |
| to vorder. |
| |
| The error INVALID_OPERATION is generated if MapControlPointsNV is |
| called where index is 0, one of the control points' fourth |
| components is not equal to 1, and either uorder of vorder is greater |
| than MAX_RATIONAL_EVAL_ORDER_NV. |
| |
| The error INVALID_OPERATION is generated if EvalMapsNV is called |
| where EVAL_VERTEX_ATTRIB0_NV is disabled. |
| |
| New State |
| |
| (add to table 6.22, page 212) |
| |
| Get Value Type Get Command Initial Value Description Sec Attribute |
| ------------------------------- ----------- ------------------------ ---------------- -------------- ----- --------- |
| EVAL_FRACTIONAL_TESSELLATION_NV B IsEnabled False fractional 5.7 eval/enable |
| tess. enable |
| EVAL_VERTEX_ATTRIBi_NV Bx16 IsEnabled True if i=0, attrib eval 5.7 eval/enable |
| false otherwise enable |
| |
| EVAL_2D_NV R4x16x8*x8* GetMapControlPointsNV [0,0,0,1] control points 5.7 - |
| EVAL_TRIANGULAR_2D_NV R4x16x8*x8* GetMapControlPoints [0,0,0,1] control points 5.7 - |
| |
| MAP_TESSELLATION_NV R4,R3 GetMapParameter*NV all 1.0 level of 5.7 eval |
| tessellation |
| |
| MAP_ATTRIB_U_ORDER_NV Z8*x16x2 GetMapAttribParameter*NV 1 map order in 5.7 - |
| U direction |
| MAP_ATTRIB_V_ORDER_NV Z8*x16x2 GetMapAttribParameter*NV 1 map order in 5.7 - |
| V direction |
| New Implementation Dependent State |
| |
| (add to table 6.24/6.25, page 214) |
| |
| Get Value Type Get Command Minimum Value Description Sec Attribute |
| ------------------------ ---- ------------ ------------- ----------- ----- --------- |
| MAX_MAP_TESSELLATION_NV Z+ GetIntegerv 256 maximum level 5.7 - |
| of tessellation |
| MAX_RATIONAL_EVAL_ORDER_NV Z+ GetIntegerv 4 maximum order 5.7 - |
| of rational |
| surfaces |
| |
| Revision History |
| |
| 1/3/2003 changed status to "discontinued" |