Optimization/ particle system/ rendering mode spin-off thred

[quasius]

This has almost nothing to do with the thread (http://www.sfml-dev.org/forum/viewtopic.php?t=626) it came from anymore; but it's still interesting so...

this could probably be a whole new thread in it's own since this discussion has severely drifted from the scope of the original question Smile

but as for drawing. i noticed when profiling my particle system that when i had ~1000 particles in a system 50% of my CPU time was spent in the Draw function .. (you can try this yourself by downloading the particle system code(wiki) and running it through AMDs codeanalyst)the only thing that function does is first set states and texture then iterate through all particles and drawing their vertices using immediate mode. This really shows that you get a very large CPU overhead when using immediate mode. as for display lists they are only faster when working with static data. and are probably slower when working with dynamic data Smile. I am in no way an expert in graphics/rendering techniques(I usually stay as far away as possible from that particular subject when it comes to making games) but it would definitely be worth checking out vertex arrays / Vertex Buffer Objects and the like. I have tried to learn how to use them and how to apply them to particles but i have thus far failed to make it work Smile (mostly because the motivation isn't really there)

and as for the never ending collision question. i agree with you but i think it is important to point out that it is in fact possible it's just very hard to make it work well Smile ( and your time is probably better spent making actual games (unless of course you are looking for a career in physics programing))

hmm if i use any more parentheses people are going to start thinking i am a lisp programmer :S

Although I haven't specifically touched particles yet.  (It's on the list though...)  My first thought would be to make a vertex buffer of every pixel in some arbitrary box representing the max size of a particle system.  This single buffer could be statically referenced in every instance of the particle system class.  Then you'd have a local index buffer with each index being a particle.  Update each index as necessary as a "lookup" into your vertex buffer, then you just have to send one index buffer.
The static vertex buffer would always be referenced from the origin, but you'd just translate the modelview based on the particle system's position before the render.

[zarka]

Although I haven't specifically touched particles yet.  (It's on the list though...)  My first thought would be to make a vertex buffer of every pixel in some arbitrary box representing the max size of a particle system.  This single buffer could be statically referenced in every instance of the particle system class.  Then you'd have a local index buffer with each index being a particle.  Update each index as necessary as a "lookup" into your vertex buffer, then you just have to send one index buffer.
The static vertex buffer would always be referenced from the origin, but you'd just translate the modelview based on the particle system's position before the render.

I am not entirely sure i understand you. But what i'm currently looking into is to allow every emitter to have one vertex buffer in which it will push all of it's particles(a particle is at the moment a quad with 4 vertices and texture coordinates).

Something i also would very much like to test is if there would be anything to gain from using VBOs in rendering normal sprites .. since they are only 4 vertices it seams like it could be a mayor waste of time.. a better solution might be some kind of batch class where you can add a bunch of sprites and have them added to a VBO and drawn.. but then we get to the question Z ordering ...

[quasius]

Although I haven't specifically touched particles yet.  (It's on the list though...)  My first thought would be to make a vertex buffer of every pixel in some arbitrary box representing the max size of a particle system.  This single buffer could be statically referenced in every instance of the particle system class.  Then you'd have a local index buffer with each index being a particle.  Update each index as necessary as a "lookup" into your vertex buffer, then you just have to send one index buffer.
The static vertex buffer would always be referenced from the origin, but you'd just translate the modelview based on the particle system's position before the render.

I am not entirely sure i understand you. But what i'm currently looking into is to allow every emitter to have one vertex buffer in which it will push all of it's particles(a particle is at the moment a quad with 4 vertices and texture coordinates).

Something i also would very much like to test is if there would be anything to gain from using VBOs in rendering normal sprites .. since they are only 4 vertices it seams like it could be a mayor waste of time.. a better solution might be some kind of batch class where you can add a bunch of sprites and have them added to a VBO and drawn.. but then we get to the question Z ordering ...

First of all, you should almost be certainly be using GL Point Sprites here and not quads.  That alone should get you massive performance increases.  Point Sprites are in OpenGL 1.2 and OpenGL ES, so it's old and safe to use.
As for z-ordering, I generally doubt you'd be able to notice or care since all the particles are the same texture, right?

[zarka]

First of all, you should almost be certainly be using GL Point Sprites here and not quads.  That alone should get you massive performance increases.  Point Sprites are in OpenGL 1.2 and OpenGL ES, so it's old and safe to use.
As for z-ordering, I generally doubt you'd be able to notice or care since all the particles are the same texture, right?

i have thought about using PointSprites.. but then all my oparticles would have to be perfect squares ... plus i belive ther are a size limit to PointSprites.
the z ordering issue would appear if i started adding up regular sprites in a VBO sprites that are not particles