• FEATURED

View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Using OpenGL for particle systems...

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

4 replies to this topic

### #1blueskies9041  Members

Posted 17 February 2014 - 02:49 PM

I'm a beginner programmer taking a game programming class here in good ole Seattle. I'm ahead of my assignments and my teacher wanted me to find something to do and I decided that a particle system would be a good occupation of my time since the game I'm desining at the moment is very mega man esque (boy do I really want the charge up effect on his blaster).

So after reading multiple OpenGL tutorials I've found that I could either generate a particle system using instancing or a combination of geometry shaders and transform feedback. I've heard arguments for both, instancing will work on almost every computer but uses CPU side processing and therefore would be slower in a more graphic intensive game (not important to my 2D game at the moment), whilst geometry shaders and transform feedback would provide an immense performance increase by taking advantage of GPU processing and would be more useful to me in the future.

So, which do you guys think is a better idea?

### #2C0lumbo  Members

Posted 17 February 2014 - 04:32 PM

If you were just trying to implement a particle system for the sake of getting it done, I'd recommend you keep it simple, and generate all four vertices on the CPU and submit as indexed triangles. In a simple 2D title, neither of the more complex approaches are likely to make any material difference to the final performance. However, it sounds like pushing yourself to learn new techniques is a big part of why you want to do it.

I think instancing doesn't bring much to the table for a particle system. Per instance, you'll need to send position, size, rotation, texture coordinates and it probably won't end up measurably faster than generating and sending all four vertices.

If I understand what you mean by the geometry shader/transform feedback approach, you're talking about using the vertex shader to update your particles using transform feedback and the geometry shader when rendering to expand a single particle into a quad. That sounds much more worthwhile both in terms of learning about interesting parts of the pipeline, and for getting some impressive particle throughput if you want to reuse the system for future demos.

I'd recommend you still start with the CPU approach first though, that way you have a reference point to check that your fancy rendering path is producing correct results, you have a fallback path for older graphics cards that you can use for your game, and you have a reference point to measure the speed boost against (in a job interview situation it's always nice to have solid performance numbers if you're talking about optimisations you made).

### #3Promit  Senior Moderators

Posted 17 February 2014 - 05:01 PM

Geometry shading is one of those things that looks great on paper and works terribly in real life. You're better off driving particle systems from the CPU. Also I've found that once you move into production with actual art goals, instancing doesn't help a lot for particles either. There's too much you want to do and instancing isn't very helpful for performance. It's easiest just to keep a double or triple buffered VBO (two or three buffers marked GL_STREAM_DRAW and switched every frame), and write the vertices manually.

SlimDX | Shark Eaters for iOS | Ventspace Blog | Twitter | Proud supporter of diversity and inclusiveness in game development

### #4TheChubu  Members

Posted 17 February 2014 - 08:51 PM

Here

I had seen the slides before but Valve released the video. First thing in the talk is a way to efficiently manage buffers for particle rendering.

The bad side is that the solution depends on ARB_buffer_storage. Which is a very, very new extension (as in only available in OpenGL 4.4 hardware). Though it explains why the conventional approach is slow, so you might get something out of it anyway.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

### #5Ed Welch  Members

Posted 11 March 2014 - 04:07 PM

The bad side is that the solution depends on ARB_buffer_storage. Which is a very, very new extension (as in only available in OpenGL 4.4 hardware). Though it explains why the conventional approach is slow, so you might get something out of it anyway.

That's an interesting video, but only Nvidia supports OpenGL 4.4 so far

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.