Jump to content
  • Advertisement
Sign in to follow this  
blueskies9041

OpenGL Using OpenGL for particle systems...

This topic is 2051 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

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? 

Share this post


Link to post
Share on other sites
Advertisement

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!