🔒 Locked

Point Sprites

Started by cody Jan 25, 2003 at 9:54 AM 9 replies 450+ views

Original Post

Jan 25, 2003 at 9:54 AM

i have a problem with NV_point_sprite: i can see the sprite but when im moving my camera away from it it doesnt get smaller. i do this: glPointParameterfEXT( GL_POINT_SIZE_MIN_EXT, 1.0f ); glPointParameterfEXT( GL_POINT_SIZE_MAX_EXT, maxSize );//maxsize is 63 on geforce float attenuation[] = { 1.0f, 0.0f, 0.01f }; glPointParameterfvEXT( GL_DISTANCE_ATTENUATION_EXT, attenuation ); then i render my sprites with glVertex() but it never changes its size. am i doing something wrong or is it not possible to resize the sprites based on distance? i have the code from a tutorial but there i cant really tell if the sprites get smaller.

Basiror

Jan 25, 2003 at 10:57 AM

argh that might be a stupid question now but can you cover those points with textures?

that shouldbe incredible fast in comparsion to the quad method

cody

Jan 25, 2003 at 11:03 AM

just enable texturing and then do this for your texture unit:

glTexEnvf( GL_POINT_SPRITE_NV, GL_COORD_REPLACE_NV, GL_TRUE );

thats it.

...and yes, it is fast. but on geforce3 you have to use texture unit 3 or it wont be hardware accelerated. read this:
http://oss.sgi.com/projects/ogl-sample/registry/NV/point_sprite.txt

[edited by - cody on January 25, 2003 12:05:46 PM]

Basiror

Jan 25, 2003 at 11:12 AM

wow thats that make really nice looking flamethrowers or clouds very fast no more function call overhead

zedzeek

Jan 25, 2003 at 1:58 PM

>>that shouldbe incredible fast in comparsion to the quad method<<

no it shouldnt, on all ALL t+l hardware gf1-gf4, radeon etc
fillrate is the problem with sprites not number of vertices

http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

Basiror

Jan 25, 2003 at 3:08 PM

draw all your sprites with quads and 3 glvertex functions and then compare the speed

youll get a function call overhead for sure

Yann L

Jan 25, 2003 at 3:13 PM

quote:

draw all your sprites with quads and 3 glvertex functions and then compare the speed

youll get a function call overhead for sure

Do it using VAR and a vertex program to create the 4 quad vertices. Compare the speed again. Actually, this is pretty much what NV_point_sprite does, BTW. Still, it is a nice and convenient extension, I agree. To bad about the NV infront of it.

Basiror

Jan 25, 2003 at 6:46 PM

exactly but what when you have 12000 particles and have to update the 4 points of the quads for each of them every frame?
impossible and unnecessary

ati supports it as well


NVIDIA Implementation Details

    This extension was first supported for GeForce4 Ti only in NVIDIA''s
    Release 25 drivers.  Future drivers will support this extension on
    all GeForce products.

    However, the extension is only hardware-accelerated on the GeForce3
    and GeForce4 Ti platforms.  In addition, there are restrictions on
    the cases that are accelerated on the GeForce3.

    In order to ensure that you get hardware acceleration on GeForce3,
    make sure that:

    1. The point sprite R mode is set to GL_ZERO.  (This is the default.)
    2. Coordinate replacement is turned on for texture unit 3 and for no
       other texture units.  This is non-obvious; using texture unit zero
       will _not_ be accelerated.  Also, if coordinate replacement is off
       for _all_ texture units, that''s also unaccelerated.

    So, in the typical usage case where you just want a single texture on
    some points, you should enable TEXTURE_2D on unit 3 but disable it on
    unit zero.

    The GeForce4 Ti platform supports point sprites as large as 8192, but
    the spacing between sizes becomes larger as the size increases.  All
    other platforms do not support point sprite sizes above 64.

ATI Implementation Details

    This extension is supported on the Radeon 8000 series and later
    platforms.

    In order to ensure that Radeon 8000 series will accelerate point
    sprite rendering using TCL hardware, make sure that the point sprite
    R mode is set to GL_ZERO.  (This is the default.)

    Radeon 8000 series can render points as large as 2047.

Revision History

    June 4, 2002 - Added implementation details section.  Fixed a typo in
    the overview.  Changed behavior of point sizes so that fractional
    sizes are allowed and so that implementations can support large point
    sprites or use floating-point point size representations.
    Significant rewrite of spec language to cover this new point size
    behavior.

    July 5, 2002 - Finished GLX protocol.
[/CODE]

zedzeek

Jan 25, 2003 at 10:46 PM

>>exactly but what when you have 12000 particles and have to update the 4 points of the quads for each of them every frame?
impossible<<

impossible? doing the math on 12000 particles to calculate the 4 corners is very very quick.

the major problem with point_sprite is that the particles have no rotation WRT the z axis of the screen. unfortunatly for most particle systems eg fire,explosion,smoke etc have the particles rotate is very desirable

http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

Basiror

Jan 28, 2003 at 4:27 AM

not sure if thats what you mean but the point sprite seems to rescale when the distance between the camera and the sprite location changes

other than that i didn t encounter any rotation problems

[edited by - Basiror on January 28, 2003 5:27:45 AM]

zedzeek

Jan 28, 2003 at 12:22 PM

i meant usually u want your particles to also rotate, this is something that point_sprites doesnt allow u to do

http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.