Hi, I’m doing a bit of testing with NV_point_sprites. Now as I understand it, GL_POINTS dont scale properly with distance, unless you setup the distance attenuation quadratic like;
Now I have tried all sorts of values, and I can’t for the life of me get my points to scale as if it was normal geometry. Anyone got any clues? I’ve looked at the nv point parameter extension docs, but can’t make head nor tail of it.
Basically what I want, is to be able to setup the size of the points with glPointSize, so that say a value of 2, it would be the same as a GL_QUAD of dimensions 2 units, and scales in the same way, when moving away from the camera.
Any help much obliged.
the equation goes so right
a + b * d + c * d^2
heres how to do linear (some word i forget the term)
static float point_end_distance_squared = SQUAREDLENGTHOFVECTOR(VECTOR(60,60,60));
static float point_start_distance_squared = SQUAREDLENGTHOFVECTOR(VECTOR(25,25,25));
float amount_equation_bottom = point_end_distance_squared - point_start_distance_squared;
float point_dist = SQUAREDLENGTHOFVECTOR( pointpos - camPOS );
float amount_equation_top = ( point_end_distance_squared - point_dist );
float amount = amount_equation_top / amount_equation_bottom;
i ripped that out of my game (so it does work)
So what exactly do I pass over for a, b and c ?
sorry about that (of course it has nothing to do with it, ild just woken up is my excuse)
i dont know if it is possible to emulate it,
to get close though from A,B,C
A u would ignore (cause it doesnt take into account distance)
- u would use either B or C (not both)
try A = 0.0 B=0.1 C=0.0
of course FOV etc play there part (quite what u will have to figure out)
I spent some time on this extension in order to replace my quad based particle system rendering routine.
Actually I faced the same problem. Why the hell do we have to specify such attenuation parameters ? This is good for lights, not geometry. I tried to find a formula to convert the projection matrix to attenuation factors, without success. Moreover on my GeForce1 the point size is limited to 64 pixels. And no tutorial on the web about how to use those extensions !
Baaaaaaah, I forgot it and kept my quad rendering routine Maybe a vertex program would be the solution :-p
yep, suggestion one: use a vertexprogram, i think you should be able to get it quite simple with it… dunno a,b,c = (0,1,0) should fit perfectly actually…
second: look up opengl.org, somewhere they had an example explaining how to get GL_ARB_point_parameters working, wich is basically the same, except without texture.
another approach: create two planes parallel to the y plane, and render the pointsprite into its middle. move it front and back and check it does only touch the planes, but never intersects… i still think a,b,c = (0,1,0) should fit best…
the more i think about it the more it seems as if u cant do it perfectly
with GL_POINTS it doesnt matter where on the screen u are they appear the same size, but with normal perspective drawing objects appear distorted (more with a high FOV) on the edges of the screen.
i dont think points take into account this (then again there may be some extension that helps eg like the fog radial extension (so fog is thicker on the sides of the screen))
personally i find the point_sprite extension to be of little use (for particle systems, cause 85% of particle u want to spin eg fire,smoke,explosions etc).
a better bet of doing points is the first method i posted ( a lot more flexible)
I’ll stick with my VP billboards then.
whats the matter? with vp you can take into account the distortion… and if you have spherical particles, meaning a spherical texture, you can still rotate the texture on the point sprite… (i think, at least, thats how i read it last time… never used or tried them)…
oh, and i don’t think they are for big particles, but more for doing zillions of tiniest particles a little more detailed… like a point with detailmap
You cant rotate textures on point sprites. Unless the texture matrix is accounted for. Which I think it isn’t. But if it is, thats still not usuefull enuff, cos in particle systems you often want random rotation per particle, and changing this in the texture matrix will be mega slow.
The texture coords for the point_sprites are fixed. You only have control of R. Although you could make a 3d texture of the same texture rotated at different R values, and animate through them I supppose…
I’m aware that VP’s are quite fast too, but the amount of information you have to send over is like 8 times more than points sprites. Just thought it would be nice to get it working. But I want them to scale properly also.
still i think the speedboost is quite useful if you do something with small particles, where you use thousands of pointlike particles instead of some big ones… and you don’t actually need a texture, but you only need the coords in the pixelshader, and there you can do what you want (rendering a circular “glow”-dot i’ve done on my gf2… was 3 times faster as doing with a texture…)
use r as a 1d texture lookup into a luminance-alpha map storing sine and cosine, or so, or an rgba map storing a rotational matrix, or what ever… and like that rotate per particle
i think they are useful, but not a simple replacement to billboards… they are point sprites. nothing more… sprites on points…