# What instead of point_sprites ?

This topic is 4835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

So I found this thread, in which posters come to a conclusion that point_sprites should not be used. What can I use instead? Quads done by hand? So let's say I will. I have to support gl with texture coordinates, which are the same for every quad. Is there a way to avoid this. Some tricky array pointers parameters, like 0-stride, or something similar maybe? Cheers. /def

##### Share on other sites
Quote:

Yep, thats pretty much what point sprites are- just plain old quads that are aligned to the screen. It isn't that much harder using hand drawn quads, just write some rendering code that takes in a point sprite size as an argument and creates the appropriate vertices based on the size. That way you can have any size of point sprite. These points will also be around the origin so you can rotate them around to face the camera without the quad going off into god knows where.. Then after that just translate the rotated quad to wherever the particle is in the world. Job done..

Quote:
 Original post by defferSo let's say I will.I have to support gl with texture coordinates, which are the same for every quad. Is there a way to avoid this.Some tricky array pointers parameters, like 0-stride, or something similar maybe?Cheers./def

0-Stride is what you would normally use when drawing from VAs or VBOs, it simply means that your elements are tightly packed together and there are no spaces between them. This is the easiest method of retrieving data from VAs / VBOs.

Concerning avoiding passing in texture coordinates- i don't think its avoidable really... You could reduce the overhead however by passing in bytes instead of floats for texture coordinates. Another thing might also be to somehow decide on a texture coordinate based on the vertexs position- again probably a lot more trouble than its worth, and may even lead to worse performance.

##### Share on other sites
Really, if they just changed it so that point sprites had 4 clip vertices (somehow) they wouldnt be so bad at all. Course that could remove any speed benifits it had... But it would really simplify the submission of the sprites.

anywho, just use billboards, they'll serve you well

This is the code I use to create billboards, note my matrix and vertex structures are something like this:

struct vec3
{
float x, y, z;
};

struct vec4
{
float x, y, z, w;
};

struct mat4
{
vec4 x, y, z, w;
};

so mat4::x is the x basis vector and so on

void	BuildBillboard(BillboardData * Billboard, void * inVertices, size_t Stride){	vec3		Modx(Engine.glState.Modelview.x.x, Engine.glState.Modelview.y.x, Engine.glState.Modelview.z.x);	vec3		Mody(Engine.glState.Modelview.x.y, Engine.glState.Modelview.y.y, Engine.glState.Modelview.z.y);	vec3		Offset	= Modx * Billboard->Offset.x						+ Mody * Billboard->Offset.y;	vec3		x		= Modx * Billboard->Size.x;	vec3		y		= Mody * Billboard->Size.y;	vec3		*		Vertices[4];	Vertices[0] = reinterpret_cast <vec3 *> (reinterpret_cast <char *> (inVertices)	+ (Stride	*	0));	Vertices[1]	= reinterpret_cast <vec3 *> (reinterpret_cast <char *> (inVertices) + (Stride	*	1));	Vertices[2] = reinterpret_cast <vec3 *> (reinterpret_cast <char *> (inVertices) + (Stride	*	2));	Vertices[3] = reinterpret_cast <vec3 *> (reinterpret_cast <char *> (inVertices) + (Stride	*	3));	*Vertices[0]		=	Billboard->Position + Offset + (x * -0.5f) + (y * 0.5f);	*Vertices[1]		=	*Vertices[0] + x;	*Vertices[2]		=	*Vertices[1] + (y * -1.0f);	*Vertices[3]		=	*Vertices[2] + (x * -1.0f);}

hope that helps
cheers
-Dan

##### Share on other sites
Thanks for the input.

I didn't bother with those sprites and just sat down for a couple of hours and wrote it. And it works [no just have to sleep, it's 4am...]

Are vertex arrays good enough? Or should I use VBOs?

Cheers.
/def

##### Share on other sites
You can't just use VBOs for quads.
I mean, you can, but then you'd need a vertex fragment program if you want to modify your particles.
Just use standard begin/end.

##### Share on other sites
I'm all for vertex arrays. But actually you may see a slight performance gain if you were to use dynamic VBO's (since you can allocate a set size on the graphics card, which should in theory help performance)
hope that helps (also, its supposed to be better to use 2 triangles rather than a quad because of the work the driver hasta do to turn it into two triangles)
-Dan

##### Share on other sites
Quote:
 Original post by RaduprvYou can't just use VBOs for quads.I mean, you can, but then you'd need a vertex fragment program if you want to modify your particles.

What about dynamic VBOs, updated every turn. Shouldn't it be better than glBegin/glEnd?

Quote:
 Original post by Ademan555also, its supposed to be better to use 2 triangles rather than a quad because of the work the driver hasta do to turn it into two triangles

But that means sending 50% more data to the driver. How much work would the splitting add to the process anyway?

Cheers.
/def

##### Share on other sites
Quote:
Original post by deffer
Quote:
 Original post by RaduprvYou can't just use VBOs for quads.I mean, you can, but then you'd need a vertex fragment program if you want to modify your particles.

What about dynamic VBOs, updated every turn. Shouldn't it be better than glBegin/glEnd?

Quote:
 Original post by Ademan555also, its supposed to be better to use 2 triangles rather than a quad because of the work the driver hasta do to turn it into two triangles

But that means sending 50% more data to the driver. How much work would the splitting add to the process anyway?

Cheers.
/def

Yep, Vertex arrays or dynamic VBOs will certainly be better than glBegin/Ends. I've not used dynamic VBOs much...whenever i have data that isn't static I usually just use vertex arrays so I can't vouche for how much of a performance gain (if any) you get using dynamic VBOs over vertex arrays.

I would just render quads if I were you as well - that's what I did for my particle engine. I think your concern of sending 50% more data is well grounded and I can't see it being a whole lot of work for the driver to split a quad into 2 triangles.

cheers.

##### Share on other sites
Thanks for support ;)

So what should I use then: vertex arrays or dynamic VBOs?
Anyone had any experience with both of them?
Or has any theoretical info that could be of help?

Cheers.
/def

##### Share on other sites
Quote:
 Original post by defferThanks for support ;)So what should I use then: vertex arrays or dynamic VBOs?Anyone had any experience with both of them?Or has any theoretical info that could be of help?Cheers./def

There probably wouldn't be much difference between using the two, though I may be wrong. From my own readings of NVIDIA articles however, dynamic VBOs seem to be the perferred option for modern GPUs- since display drivers are most likely heavily optimised towards using them.

I use VAs myself for my own particle systems, I might try and use dynamic VBOs sometime just to see what the difference is- though i don't think it would be much.

I'd say stick with VAs for the time being though, because they are much easier to use and are more compatible with older drivers / graphics hardware. Its up to you really...

1. 1
2. 2
Rutin
22
3. 3
4. 4
5. 5
frob
12

• 17
• 9
• 31
• 16
• 9
• ### Forum Statistics

• Total Topics
632615
• Total Posts
3007441

×