Name

    OES_point_sprite

Name Strings

    GL_OES_point_sprite

Contact

    Aaftab Munshi (amunshi@ati.com)

Notice

    Copyright (c) 2004-2013 The Khronos Group Inc. Copyright terms at
        http://www.khronos.org/registry/speccopyright.html

Status

    Ratified by the Khronos BOP, Aug 5, 2004.

IP Status

    No known IP issues.

Version

    Last Modified Date: August 5, 2004

Number

    OpenGL ES Extension #15

Dependencies

    OpenGL ES 1.0 is required

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_OES 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.

Issues

    The following are the list of issues as discussed in the
    ARB_point_sprite extension.  I've deleted issues that are not related
    to OpenGL ES such as vertex shader programs etc.

    Tokens that use _ARB names are modified to use _OES.

    *   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
              O--------------->

        Applications using a single texture for both point sprites and other
        geometry need to account for the fixed coordinate mapping of point
        sprites.

    *   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
        sizes?

        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_OES enable is global.  The
        COORD_REPLACE_OES 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?

        RESOLVED: COORD_REPLACE_OES.

    *   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 this extension interact with the point size attenuation
        functionality in OES_point_parameters and OpenGL 1.4?

        RESOLVED:  Point sprites sizes are attenuated just like the sizes of
        non-sprite points.

    *   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.

New Procedures and Functions

    None

New Tokens

    Accepted by the <cap> parameter of Enable, Disable, and by the
    <target> parameter of TexEnvf, TexEnvfv, TexEnvx, TexEnvxv:

        POINT_SPRITE_OES                               0x8861

    When the <target> parameter of TexEnvf, TexEnvfv, TexEnvx, TexEnvxv,
    is POINT_SPRITE_OES, then the value of <pname> may be:

        COORD_REPLACE_OES                              0x8862

    When the <target> and <pname> parameters of TexEnvf, TexEnvfv,
    TexEnvx, TexEnvxv, are POINT_SPRITE_OES and COORD_REPLACE_OES
    respectively, then the value of <param> or the value pointed
    to by <params> may be:

        FALSE
        TRUE


Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)

    None.

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_OES.  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{ixf}(enum target, enum pname, T param)
      void TexEnv{ixf}v(enum target, enum pname, const T *params)

    where target is POINT_SPRITE_OES and pname is COORD_REPLACE_OES.  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
    70):

    "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_OES 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,
    respectively.

    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_OES is disabled, or
    a square with side equal to the current point width if
    POINT_SPRITE_OES 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_OES 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_OES is disabled.
    The set of point sizes supported is equivalent to those for point
    sprites without multisample when POINT_SPRITE_OES is enabled."

Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
Operations and the Frame Buffer)

    None.

Additions to Chapter 5 of the OpenGL 1.4 Specification (Special
Functions)

    None.

Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
State Requests)

    None.    

Errors

    None.

New State

(table 6.12, p. 220)

Get Value                Type    Get Command     Initial Value   Description 
---------                ----    -----------     -------------   -----------
POINT_SPRITE_OES         B       IsEnabled       False           point sprite enable

(table 6.17, p. 225)

Get Value                Type    Get Command     Initial Value   Description
---------                ----    -----------     -------------   -----------
COORD_REPLACE_OES        2* x B  GetTexEnviv     False           coordinate replacement
                                                                 enable

Revision History