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"