Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Particle Engine Design Theory

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

A few of you may know I recently (read: 1 year ago), did a particle engine in DirectX. A couple of you have seen it here. Now I got a hankering a while back to start a new one. I recognized the design flaws with the last one are a basic lack of flexibility and functionality. So, for libGDN (hopefully), I've decided to start another one, that will (I hope), blow the old one out of the water and essentially offer limitless possibilities. But I need you suggestions and criticisms of the design that I have come up with. It's based around a double backend way of manipulating the particle system. You can use code in c++ or scripting (Lua) at any stage of the pipeline (about 3 stages) to achieve maximum flexibility. Essentially, you combine a couple code or scripted pieces together to manipulate the properties of a particle and do all kinds of stuff. Now, I've chalked up a basic flow design diagram in Visio to show what I mean. Here it is: Now I have only one slight reservation with the design at this point, and that is regarding the speed of the memory manager. The memory manager allows you to store only properties that you need, which can eliminate memory cost on unused features. But my worry is that the array access which gives the memory offset may be to big of a cost when it's per particle memory operation. Of course, you can alleviate this by only setting memory when you absolutely need it, but I'm still a little iffy. Any suggestions/comments on any part of the system? BTW..if there is significant interest, I'll write an article on how you do something like this after I'm all done. EDIT: I'm trying to think of titles for an article that reflect the diagram. I'm thinking something like: "How to create an advanced particle engine in 12345421 easy steps"
Gamedev for learning. libGDN for putting it all together. An opensource, cross platform, cross API game development library. [edited by - CpMan on April 20, 2003 3:01:15 AM] [edited by - CpMan on April 20, 2003 3:22:47 AM]

Share this post

Link to post
Share on other sites

micepick I''d particularly like your opinion/criticisms as you''re the most recent particle engine "completer" that I know of.

Gamedev for learning.
libGDN for putting it all together.
An opensource, cross platform, cross API game development library.

Share this post

Link to post
Share on other sites
Ahh, I''m really out of it today (bad flu, little sleep), so I don''t really have any brilliant ideas for you right now.

Your memory manager idea doesn''t seem catastrophically inefficient, but an extra array lookup per property per particle per frame might add up to something significant. Looks like an interesting problem; I''ll be thinking about ways to work around this.

Other than that, I think this would be a brilliant particle engine if you can arrange most of those modules to be transparently interchangeable parts. Letting the user derive their own emmission patterns, particle paths, collision response methods, and particle rendering modules with pluggable vertex shaders would go a long way toward making a library with limitless potential.

I''m not sure of the exact structure you had in mind for the particle groups, but allowing them to be arranged into hierarchies (a la scene graphs) would IMO be very useful. Allowing the user to apply forces to a group and having the effects propagate to subgroups may open some interesting possibilities. It may be useful to alter particle properties or set render states for an entire group and its subgroups. Perhaps you already intended to do this, or maybe it would be too inefficient...

Anyway, I''m going to get some work done; I''ll let my subconscious come up with ideas.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!