back  Return to list

homeprevnext Name
homeprevnext Name Strings
homeprevnext Contact
    Matt Craighead, NVIDIA Corporation (mcraighead 'at'  
    Mark Kilgard, NVIDIA Corporation (mjk 'at'  
    Pat Brown, NVIDIA Corporation (pbrown 'at'  
homeprevnext IP Status
    No known IP issues.  
homeprevnext Status
    Approved by the ARB on July 24, 2003.  
homeprevnext Version
    Last Modified Date:  July 22, 2003  
    Revision:            7  
homeprevnext Number
    ARB Extension #35  
homeprevnext Dependencies
    Written based on the wording of the OpenGL 1.4 specification.  
    NV_point_sprite affects the definition of this extension.  
homeprevnext Overview
    Applications such as particle systems have tended to use OpenGL quads  
    rather than points to render their geometry, since they would like  
    to use a custom-drawn texture for each particle, rather than the  
    traditional OpenGL round antialiased points, and each fragment in  
    a point has the same texture coordinates as every other fragment.  
    Unfortunately, specifying the geometry for these quads can be  
    expensive, since it quadruples the amount of geometry required, and  
    may also require the application to do extra processing to compute  
    the location of each vertex.  
    The purpose of this extension is to allow such applications to use  
    points rather than quads.  When GL_POINT_SPRITE_ARB is enabled,  
    the state of point antialiasing is ignored.  For each texture unit,  
    the app can then specify whether to replace the existing texture  
    coordinates with point sprite texture coordinates, which are  
    interpolated across the point.  
homeprevnext Issues
    *   Should this spec say that point sprites get converted into quads?  
        RESOLVED: No, this would make the spec much uglier, because then  
        we'd have to say that polygon smooth and stipple get turned off,  
        etc.  Better to provide a formula for computing the texture  
        coordinates and leave them as points.  
    *   How are point sprite texture coordinates computed?  
        RESOLVED: They move smoothly as the point moves around on the  
        screen, even though the pixels touched by the point do not.  The  
        exact formula is given in the spec below.    
        A point sprite can be thought of as a quad whose upper-left corner has  
        (s,t) texture coordinates of (0,0) and whose lower-right corner has  
        texture coordinates of (1,1), as illustrated in the following figure.  
        In the figure "P" is the center of the point sprite, and "O" is the  
        origin (0,0) of the window coordinate system.  Note that the y window  
        coordinate increases from bottom-to-top but the t texture coordinate  
        of point sprites increases from top-to-bottom.  
            +y| (0,0)  
              |   +-----+  
              |   |     |     
              |   |  P  |     
              |   |     |  
              |   +-----+  
              |       (1,1)  
              |              +x  
        Applications using a single texture for both point sprites and other  
        geometry need to account for the fixed coordinate mapping of point  
    *   Is the ARB specification different from the NV version?  
        RESOLVED:  Yes.  The point sprite R mode has been removed.  The  
        wording has also been updated to reflect version 1.4 of the core  
        OpenGL specification however.  The enumerant values are unchanged.  
    *   How do point sizes for point sprites work?  
        RESOLVED: This specification treats point sprite sizes like  
        antialiased point sizes, but with more leniency.  Implementations  
        may choose to not clamp the point size to the antialiased point  
        size range.  The set of point sprite sizes available must be  
        a superset of the antialiased point sizes.  However, whereas  
        antialiased point sizes are all evenly spaced by the point size  
        granularity, point sprites can have an arbitrary set of sizes.  
        This lets implementations use, e.g., floating-point sizes.  
    *   Should there be a way to query the list of supported point sprite  
        RESOLVED: No.  If an implementation were to use, say, a single-  
        precision IEEE float to represent point sizes, the list would be  
        rather long.  
    *   Do mipmaps apply to point sprites?  
        RESOLVED: Yes.  They are similar to quads in this respect.  
    *   What of this extension's state is per-texture unit and what  
        of this extension's state is state is global?  
        RESOLVED: The GL_POINT_SPRITE_ARB enable is global.  The  
        COORD_REPLACE_ARB state is per-texture unit (state set by TexEnv is  
        per-texture unit).  
    *   Should there be a global on/off switch for point sprites, or  
        should the per-unit enable imply that switch?  
        RESOLVED: There is a global switch to turn it on and off.  This  
        is probably more convenient for both driver and app, and it  
        simplifies the spec.  
    *   What should the TexEnv mode for point sprites be called?  
    *   What is the interaction with multisample points, which are round?  
        RESOLVED: Point sprites are rasterized as squares, even in  
        multisample mode.  Leaving them as round points would make the  
        feature useless.  
    *   How does the point sprite extension interact with fragment  
        program extensions (ARB_fragment_program, NV_fragment_program,  
        RESOLVED: The primary issue is how the interpolated texture  
        coordinate set appears when fragment attribute variables  
        (ARB terminology) or fragment program attribute registers (NV  
        terminology) are accessed.  
        When point sprite is enabled and the GL_COORD_REPLACE_ARB state for  
        a given texture unit is GL_TRUE, the texture coordinate set for  
        that texture unit is (s,t,0,1) where the point sprite-overridden  
        s and t are described in the amended Section 3.3 below.  The  
        important point is that r and q are forced to 0 and 1, respectively.   
        For fragment program extensions, r and q correspond to the z and w  
        components of the respective fragment attribute.  
    *   How does this extension interact with PolygonMode?  
        RESOLVED:  If a polygon is rendered in point mode and POINT_SPRITE_ARB  
        is enabled, its vertices will be rendered as point sprites.  
    *   How does this extension interact with the point size attenuation  
        functionality in ARB_point_parameters and OpenGL 1.4?  
        RESOLVED:  Point sprites sizes are attenuated just like the sizes of  
        non-sprite points.  
    *   What push/pop attribute bits control the state of this extension?  
        RESOLVED:  POINT_BIT for all the state.  Also ENABLE_BIT for  
        the POINT_SPRITE_ARB enable.  
    *   How are point sprites clipped?  
        RESOLVED:  Point sprites are transformed as points, and standard point  
        clipping operations are performed.  This can cause point sprites that  
        move off the edge of the screen to disappear abruptly, in the same way  
        that regular points do.  As with any other primitive, standard  
        per-fragment clipping operations (scissoring, window ownership test)  
        still apply.  
homeprevnext New Procedures and Functions
homeprevnext New Tokens
    Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by  
    the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and  
    GetDoublev, and by the <target> parameter of TexEnvi, TexEnviv,  
    TexEnvf, TexEnvfv, GetTexEnviv, and GetTexEnvfv:  
        POINT_SPRITE_ARB                               0x8861  
    When the <target> parameter of TexEnvf, TexEnvfv, TexEnvi, TexEnviv,  
    GetTexEnvfv, or GetTexEnviv is POINT_SPRITE_ARB, then the value of  
    <pname> may be:  
        COORD_REPLACE_ARB                              0x8862  
    When the <target> and <pname> parameters of TexEnvf, TexEnvfv,  
    TexEnvi, or TexEnviv are POINT_SPRITE_ARB and COORD_REPLACE_ARB  
    respectively, then the value of <param> or the value pointed to by  
    <params> may be:  
homeprevnext Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
homeprevnext Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
    Insert the following paragraphs after the second paragraph of section  
    3.3 (page 66):  
    "Point sprites are enabled or disabled by calling Enable or Disable  
    with the symbolic constant POINT_SPRITE_ARB.  The default state is for  
    point sprites to be disabled.  When point sprites are enabled, the  
    state of the point antialiasing enable is ignored.  
    The point sprite texture coordinate replacement mode is set with one  
    of the commands  
      void TexEnv{if}(enum target, enum pname, T param)  
      void TexEnv{if}v(enum target, enum pname, const T *params)  
    where target is POINT_SPRITE_ARB and pname is COORD_REPLACE_ARB.  The  
    possible values for param are FALSE and TRUE.  The default value for  
    each texture unit is for point sprite texture coordinate replacement  
    to be disabled."  
    Replace the first two sentences of the second paragraph of section  
    3.3.1 (page 67) with the following:  
    "The effect of a point width other than 1.0 depends on the state of  
    point antialiasing and point sprites.  If antialiasing and point  
    sprites are disabled, ..."  
    Replace the first sentences of the fourth paragraph of section 3.3.1  
    (page 68) with the following:  
    "If antialiasing is enabled and point sprites are disabled, ..."  
    Insert the following paragraphs at the end of section 3.3.1 (page  
    "When point sprites are enabled, then point rasterization produces a  
    fragment for each framebuffer pixel whose center lies inside a square  
    centered at the point's (x_w, y_w), with side length equal to the  
    current point size.  
    All fragments produced in rasterizing a point sprite are assigned the  
    same associated data, which are those of the vertex corresponding to  
    the point, with texture coordinates s, t, and r replaced with s/q,  
    t/q, and r/q, respectively.  If q is less than or equal to zero, the  
    results are undefined.  However, for each texture unit where  
    COORD_REPLACE_ARB is TRUE, these texture coordinates are replaced  
    with point sprite texture coordinates.  The s coordinate varies  
    from 0 to 1 across the point horizontally left-to-right, while  
    the t coordinate varies from 0 to 1 vertically top-to-bottom.  
    The r and q coordinates are replaced with the constants 0 and 1,  
    The following formula is used to evaluate the s and t coordinates:  
      s = 1/2 + (x_f + 1/2 - x_w) / size  
      t = 1/2 - (y_f + 1/2 - y_w) / size  
    where size is the point's size, x_f and y_f are the (integral) window  
    coordinates of the fragment, and x_w and y_w are the exact, unrounded  
    window coordinates of the vertex for the point.  
    The widths supported for point sprites must be a superset of those  
    supported for antialiased points.  There is no requirement that these  
    widths must be equally spaced.  If an unsupported width is requested,  
    the nearest supported width is used instead."  
    Replace the text of section 3.3.2 (page 70) with the following:  
    "The state required to control point rasterization consists of the  
    floating-point point width, three floating-point values specifying  
    the minimum and maximum point size and the point fade threshold size,  
    three floating-point values specifying the distance attenuation  
    coefficients, a bit indicating whether or not antialiasing is  
    enabled, a bit indicating whether or not point sprites are enabled,   
    and a bit for the point sprite texture coordinate replacement mode  
    for each texture unit."  
    Replace the text of section 3.3.3 (page 70) with the following:  
    "If MULTISAMPLE is enabled, and the value of SAMPLE_BUFFERS is one,  
    then points are rasterized using the following algorithm, regardless  
    of whether point antialiasing (POINT_SMOOTH) is enabled or disabled.  
    Point rasterization produces a fragment for each framebuffer pixel  
    with one or more sample points that intersect a region centered at  
    the point's (x_w, y_w).  This region is a circle having diameter  
    equal to the current point width if POINT_SPRITE_ARB is disabled, or  
    a square with side equal to the current point width if  
    POINT_SPRITE_ARB is enabled.  Coverage bits that correspond to sample  
    points that intersect the region are 1, other coverage bits are 0.  
    All data associated with each sample for the fragment are the data  
    associated with the point being rasterized, with the exception of  
    texture coordinates when POINT_SPRITE_ARB is enabled; these texture  
    coordinates are computed as described in section 3.3.  
    Point size range and number of gradations are equivalent to those  
    supported for antialiased points when POINT_SPRITE_ARB is disabled.  
    The set of point sizes supported is equivalent to those for point  
    sprites without multisample when POINT_SPRITE_ARB is enabled."  
homeprevnext Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment Operations and the Frame Buffer)
homeprevnext Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
homeprevnext Additions to Chapter 6 of the OpenGL 1.4 Specification (State and State Requests)
homeprevnext Interactions with NV_point_sprite
    ARB_point_sprite is a functional subset of NV_point_sprite.    
    The only functional difference between the extensions is that  
    NV_point_sprite provides the POINT_SPRITE_R_MODE_NV control.  This mode  
    allows applications to specify how the r texture coordinates for point  
    sprites are replaced.  The r coordinate can be replaced with the  
    corresponding s texture coordinate ("S" mode), left unchanged ("R" mode),  
    or replaced with the constant zero ("ZERO" mode).  ARB_point_sprite always  
    replaces r texture coordiantes of point sprites with zero.  
    Since ARB_point_sprite is functionally compatible with the default r mode  
    from NV_point_sprite, the two extensions can coexist nicely.  Enumerant  
    values from NV_point_sprite are reused.  
    If NV_point_sprite is supported, the language describing the replacement  
    of r coordinates for point sprites (forced to zero) is replaced with the  
    corresponding language from NV_point_sprite (controlled by  
homeprevnext Errors
homeprevnext New State
(table 6.12, p. 220)  
Get Value                Type    Get Command     Initial Value   Description             Sec    Attribute  
---------                ----    -----------     -------------   -----------             ------ ---------  
POINT_SPRITE_ARB         B       IsEnabled       False           point sprite enable     3.3    point/enable  
(table 6.17, p. 225)  
Get Value                Type    Get Command     Initial Value   Description             Sec    Attribute  
---------                ----    -----------     -------------   -----------             ------ ---------  
COORD_REPLACE_ARB        2* x B  GetTexEnviv     False           coordinate replacement  3.3    point  
homeprevnext Revision History
    Initially based on the NV_point_sprite specification but updated for  
    OpenGL 1.4.  
    Rev.    Date    Author    Changes  
    ----  --------  --------  --------------------------------------------  
    7     07/22/03  pbrown    Marked point parameter issue resolved.  
    6     07/18/03  pbrown    Removed POINT_SPRITE_R_MODE_CONTROL.    
                              Expanded on spec issue documenting the inversion  
                              of the "t" texture coordinate relative to the  
                              "y" window coordinate.  Added issues on  
                              interaction with PolygonMode, clipping, and  
                              point parameters.  Documented interaction with  
                              NV_point_sprite.  Removed now unneeded point  
                              parameter interaction section and GLX protocol.  
                              parameter interaction section and GLX protocol.  
Valid XHTML 1.1! Valid CSS! Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.