Sign in to follow this  

What instead of point_sprites ?

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Quote:
Original post by deffer
What can I use instead?
Quads done by hand?


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 deffer
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


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 this post


Link to post
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 this post


Link to post
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...]

How about displaying them?
Are vertex arrays good enough? Or should I use VBOs?

Cheers.
/def

Share this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Raduprv
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.


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

Quote:
Original post by Ademan555
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


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

Cheers.
/def

Share this post


Link to post
Share on other sites
Quote:
Original post by deffer
Quote:
Original post by Raduprv
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.


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

Quote:
Original post by Ademan555
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


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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by deffer
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


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

Share this post


Link to post
Share on other sites
Quote:
Original post by deffer
Quote:
Original post by Raduprv
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.


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

Quote:
Original post by Ademan555
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


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

Cheers.
/def


well rather than sending 4 vertices you're sending 4 vertices + 6 indices, assuming you're using 16 bit indices which you should be, thats not all that much extra data. And as far as the extra work required to split the quad into two triangles, apparently its rather large because i've been told that triangles posess a noticable speed advantage over quads (of course, premature optimization is the root of all evil, so i suppose only change that if it turns out to be a bottleneck)

hope that helps
-Dan

Share this post


Link to post
Share on other sites
Thanks for your suggestions.

As I had some problems with properly setting the texturing with VA/VBO, I temporarily switched to immediate mode, but I finally made it work.
The effect you can see here(jpg) or here(bmp) (some parameter tweaking may be still to do).

I'll test quads vs. indexed triangles later and post results.

Cheers.
/def

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this