• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
spek

Particle techniques

8 posts in this topic

Hey,

I'd like to know how modern games manage their particles. I can think of 3 ways:
- Let the CPU calculate the motion and render quads. The "traditional" way.
- Make a VBO, and let the vertex-shader update the positions/motion via a texture (like GPU cloth works)
- Make a VBO, and let the vertex-shader interpolate the position based on some parameters (start, velocity, currentTime, ...)

I can imagine solution 2 and 3 are quite a lot faster, but these are somewhat limited when it comes to complex movement, spawning time schedules, or (simple) collision detection with the floor. Plus I wouldn't know how to depth-sort the particles then.

So, I still prefer the old CPU way. In order to optimize a bit, I'll use clusters that contain multiple particles. So I don't sort/calculate per particle, but per cluster. But when we want thousands and thousands of particles, it still becomes a long, long loop of calculations and draw calls... So, how do modern engines solve this?

Rick
0

Share this post


Link to post
Share on other sites
I'm not an expert on this but I can tell you some things that might help:

[quote]Plus I wouldn't know how to depth-sort the particles then.[/quote]

You can solve this by looking up "Premultiplied alpha". That way you don't need depth-sorting anymore, meaning you can draw particles in any order. It should give you a huge performance-boost.
[quote]
But when we want thousands and thousands of particles, it still becomes a long, long loop of calculations and draw calls...
[/quote]

You could at least reduce the amount of draw calls by using hardware instancing, if you are using directx. That way you only need 1 draw call per emitter. Look up the sdk-examples or the nvidia sdk example how to do it.

So if you still want to go with CPU calculations, these 2 steps should give you you at least 8 times the performance. I can draw around 50.000 particles on a single core of an old Core2Duo with 70 FPS, and havn't optimized my particle system yet. Not an excellent value but for standard cases it should work fine.
0

Share this post


Link to post
Share on other sites
50.000 particles sounds perfect. But I'm using OpenGL 2.x here... It doesn't have instancing as far as I know. Pre-multiplied alpha... Not sure what you mean with that, that the sum of alpha would be '1' with X additive blended particles behind each other, to prevent extreme bright values? In some cases I want normal-transparent particles though. For example shrapnel or blood flying around shouldn't be additive. Although that won't come in such huge numbers of course.

But ok, maybe I can just ignore the sorting problem. Let's see what we can do with VBO's:
- Make a fixed large number of quads inside a VBO. The quads are not positioned yet.
- Use a texture to map the current position and motion vector for each particle (1 pixel per particle)
- Vertex shader reads the texture, then updates it ( output.newPosition = input.oldPosition + input.motion + gravity ). Eventually use a simple comparison to detect ground and bounce off the particles (or let them dissapear)
- Finally render the quads in the world using that position texture


I guess this can work, but managing the spawning and "recycling" of old dissapeared particles is nasty. I'd probably need to store a (cyclic) "lifetime" value into one of those textures as well. The VS should get a number of how many particles are active at the time. Say a VBO contains 1000 particles, and I only want to see about 250. The first 250 should fly around, the other 750 should be hidden somewhere. Whenever a particle lifetime has exceeded, it resets to an initial position/motion vector.


The other solution is to work without any textures, just pure mathematical. For each particle, the VS calculates the position based on a formula, given the initial position, motion and elapsed time. But getting that to work in a somewhat flexible way sounds even harder.
0

Share this post


Link to post
Share on other sites
[quote]Pre-multiplied alpha... Not sure what you mean with that, that the sum of alpha would be '1' with X additive blended particles behind each other, to prevent extreme bright values? In some cases I want normal-transparent particles though. For example shrapnel or blood flying around shouldn't be additive. Although that won't come in such huge numbers of course.[/quote]

No, premultiplied alpha is not like additive blending. In the shader (programs in your case?) you multiplied the color of the particles with their alpha value and change the alpha blending to behave in a certain way. Can't really describe it, take a look at this site, it should be quite easy to implement:

[url="http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx"]http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx[/url]

I can't help you with the other stuff, as I haven't tried it out, too. Good luck, though!
1

Share this post


Link to post
Share on other sites
no, if u don't use a simple ADD blend u need to sort particles.

On old hardware u can use of course Textures, which u modify in a shader, for the particle attributes, but with OpenGL 3 u have Transform Feedback with which u can "render" with a Vertex Shader into another buffer object.

Two good resource for GPU particle sorting for once and rendering rediculouse much particles are these two
[url="http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter46.html"]http://http.develope..._chapter46.html[/url]
[url="http://directtovideo.wordpress.com/"]http://directtovideo.wordpress.com/[/url](take also a look at his demos)
1

Share this post


Link to post
Share on other sites
Thanks and thanks! I have something to read this weekend :)

OpenGL 3.0... I'll wait with that one. I'm getting crazy updating everything all the time. Newton2, OpenAL to FMOD, and so on. Or is upgrading OpenGL 2 to 3 a peace of cake? Anyhow, rendering data into a VBO sounds very useful for cloth, physics, and such.

Thank you gentleman
0

Share this post


Link to post
Share on other sites
[quote]no, if u don't use a simple ADD blend u need to sort particles.[/quote]

Well even if premultiplied alpha in fact is nothing more than an add blend, then it doesn't mind. I can render every particle I want, and they look fine. Blood, shrapnel and other solid particles are drawn just as solid as they should, and particles with alpha like fire draw transparent. I just wanted to tell spek that he can use pre-alpha without negative sideeffects like additive/substractive blending.
0

Share this post


Link to post
Share on other sites
As Danny02 said, check out transform feedback buffer based particles.

My implementation of GPU particle systems works with OpenGL 2 (i.e., EXT_transform_feedback). You save [i]a lot[/i] compared to other GPU techniques because you don't need to deal with rasterization; glEnable(GL_RASTERIZER_DISCARD). Basically, you use a vertex shader to transform everything, but the data stops there, and is written to a vertex buffer object.

My version supports multiple emitters, attractors, and collision detection, among other things. The whole thing runs at 50fps with 1 million particles, and at 10fps with 4 million (most of this is drawing the particles. If I don't draw the particles, 4 million runs at 50fps).

-G
0

Share this post


Link to post
Share on other sites
Just discovered there is transform feedback demo in the OpenGL nVidia SDK 10.0 Haven't studied the code yet, but if I understand it right, this technique allows to alter VBO data via a vertex-data, thus without textures to keep track of the vertices. That would be extremely handy, also for cloth physics. And if OpenGL 2 supports it after all.... Better start reading :)

Thanks
0

Share this post


Link to post
Share on other sites

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  
Followers 0