• Advertisement
Sign in to follow this  

How to render ParticleSystem effectively??

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

hey Here I got a problem about my ParticleSystem Editor. I want to render the particle System , but I create a Particle class which stores the information of each particle . Most important information of each particle is the position. And I want to render it by DrawPrimitiveUp function . If there is too much vertex , vertex buffer is a proper way to do it . But how can I use the vertex buffer if I store each particle information into Particle class. If I get all of the position into a vertex buffer , I have to spend double time to render it. If I store the position information into the vertex buffer , how could I remove the particle if it's "dead". I'm really confused. Any opinion is welcome , really appreciate!!!

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by CodeBoyCjy
If I get all of the position into a vertex buffer , I have to spend double time to render it.
You need to do a pass over the data to load it into the vertex buffer, yes. This is the usual way to do it. Keep one copy of the data in the vertex buffer in system memory, and every frame update it and memcpy it to the dynamic vertex buffer, then render it.

Alternatively, if your particles positions can be expressed with a fairly simple equation (E.g. parametric), you can use a vertex shader to move all of the particles and just store velocity and optionally acceleration in your vertex struct.

Share this post


Link to post
Share on other sites
I've been professionally creating special effects for games for some years now so this is a subject that gets me really quite fired up (for a number of reasons).

A particle should be considered as a primitive piece of information that's used to store a small amount of information about the behaviour and state of a component of an effect. It only needs to contains a very small amount of useful information. A couple of vectors that you could use for position and perhaps a direction, a float showing the age of the particle, a random number because they're always useful, and perhaps a couple of spare unsigned chars for what ever reason comes to mind. It's important not to tie yourself down to much and at all costs avoid filling a particle class with rubbish like 'StartSize, EndSize, StartColour, etc..'

The rendering of such particles should be considered separately and the use of the other values is then based on context. That way the particles can represent anything, from simple screen facing quads (vanilla particle system) to flocks of animated birds or clouds of asteroids (or 1001 other things).

I suggest creating a system that can deal with the very dynamic vertex data that an effects (particles) system generates should be one of your first priorities. It should have a simple interface that allows you to fill in the individual positions colours and mappings of vertices. It shouldn't care where its vertex information comes from. Obviously it should be as blindingly fast as you can make it. Once it works you can then go on to create a few helper functions like FillVertsAsParticle(Vertex* v) or something.

Once that works then you can make effects manager classes that render and animate particles for a given type of effect, feeding the resulting vertex data into your dynamic vertex system as it goes.

result: a system that supports anything, literally.



If there was a point to that whole ramble then I think its this:
Before you decide to just throw together yet another limited, screen facing quad drawing, vanilla flavoured particle system that moves glowing blobs through parabolas and sin waves, Stop! It's relatively easy to make something that does all that and more in a nice easy to use extensible way.

Share this post


Link to post
Share on other sites
You can store pointers on allive particles in std::vector class or an array. Than you can copy this particles every frame into some dynamic vertex bufer and render that buffer.

And as Evil Steve said, it is good way to compute paticle movement in vertex shader to free CPU. You just insert into vertex buffer the position where particles starts.

Share this post


Link to post
Share on other sites
Quote:
Original post by DarkPsychosis
A particle should be considered as a primitive piece of information that's used to store a small amount of information about the behaviour and state of a component of an effect. It only needs to contains a very small amount of useful information. A couple of vectors that you could use for position and perhaps a direction, a float showing the age of the particle, a random number because they're always useful, and perhaps a couple of spare unsigned chars for what ever reason comes to mind. It's important not to tie yourself down to much and at all costs avoid filling a particle class with rubbish like 'StartSize, EndSize, StartColour, etc..'

If there was a point to that whole ramble then I think its this:
Before you decide to just throw together yet another limited, screen facing quad drawing, vanilla flavoured particle system that moves glowing blobs through parabolas and sin waves, Stop! It's relatively easy to make something that does all that and more in a nice easy to use extensible way.
I have to quote this since I agree 100%!
Quote:
Original post by amigocz
You can store pointers on allive particles in std::vector class or an array.
It isn't exactly the same thing! It's more like saying: your car needs wheels. They can be circular or quadrilateral. Personally when it comes to the HW I don't like containers at all.

Share this post


Link to post
Share on other sites
Consider creating a vertex buffer twice the size that is needed. During your first frame, lock your buffer with D3DLOCK_DISCARD, write particle information to the first half of buffer and render with it. During your second frame, lock the second half with D3DLOCK_NOOVERWRITE you fill the second half. Keep alternating, and you ensure that you do not stall the card on locks to the buffer in case your card is still rendering (some cards render one or two frames behind the application).

Also, pay in mind that your vertex structure does not have to store at all the same information as the particle structure. If most of your particle animation is done on the CPU, for example, it may be sufficient to only store a position and a color in the vertex structure.

Also, consider storing any data that does not vary between particles, but does vary between the particle sprite's corners (such as texture coordinates), to constant registers and indexing to them in the vertex shader via an integer index that is stored as vertex attributes (note that this obviously will not work in a pixel shader because the index gets interpolated). Note that if your card supports changing vertex stream frequency, it is probably faster to store this data on a separate stream and use that instead. I have not tried this though.

Finally, particle systems are the text book definition of eye candy. If you are not doing any sort of particle collision detection or something else that requires your particle system to be exactly in sync to the rest of your scene, put your particle system updates in a separate thread.

[Edited by - Jaska on March 17, 2008 12:20:29 PM]

Share this post


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

  • Advertisement