Skip to main content
GameDev.net gamedev.net
🔒 Locked

Particle Systems

Started by foniks munkee Jun 25, 2004 at 9:03 PM 3 replies 750+ views
Original Post
foniks munkee
foniks munkee
Hello, Got a question regarding the design of a particle system in DirectX. I my design I have: 1. A Particle (one object per particle) 2. An Emitter (Creates the particles and emits them) 3. A Particle Manager (redundant for now, but will allow the creation of multiple emitters and control the pool of particles later) I think this is fairly standard from what I have read. But my quesion is: Each particle is a textured trianglestrip. The vertices are stored in a vertex buffer containing custom vertex structures. Now my understanding of these structures is that you should not mix non-DX info with this struct (i.e. time to live, velocity etc). So this would mean keeping another data structure elsewhere that would store this info for each particle. The way I see it, the Emitter class will have one Vertex buffer, and a list containing the structs that store the information regarding velocity etc. Can anyone see any problems with this? Cheers, FM
IFooBar
IFooBar
Quote:
So this would mean keeping another data structure elsewhere that would store this info for each particle. The way I see it, the Emitter class will have one Vertex buffer, and a list containing the structs that store the information regarding velocity etc. Can anyone see any problems with this?


I dont see a problem with that.

you can check this link to see how the particle system was designed.
[size=2]aliak.net
S1CA
S1CA
Personally I'd separate the "rendered" particle from the emitted particle.

The emitted particle is emitted into world space and contains all the current particle details such as velocity, lifetime, bounding information etc.

The rendered particle is what you see on the screen and what gets submitted to D3D for rendering.

In your update, after advancing the emitted particle based on its properties, you'd cull the particle bounding volume (against frustum, cell, portal etc) and produce a list of render particles.

Each render particle would probably be in a format directly passable to D3D and would likely only need position, diffuse colour+alpha and texture coordinate.

Having a strip per quad implies you'll often be calling Draw*Primitive*() once per particle - this will be suicide in terms of performance - avoid doing this at all costs!

I would go for a triangle list instead, probably indexed; An indexed triangle list means you can submit all the triangles to draw in a ***single*** Draw*Primitive*() call, so as long as all the particles for a single emitter use the same texture, then ALL those particles can be rendered in a single D3D call (a good thing!)

Furthermore, since the vertex buffer you're writing to will (potentially) change every frame, you'll need to create a buffer suitable for dynamic writing of data.

Finally, there's no point in copying the render particle list positions into the vertex buffer - you may as well generate particles straight in the VB!, so:

1. Run simulation for all particles
2. Lock VB
3. Cull particles based on position
4. Write all visible particles to VB
5. Unlock VB
Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site
foniks munkee
foniks munkee
Ah. That is some great info all. Thanks :)
Pipo DeClown
Pipo DeClown
You could also use Point Sprites, which are just like trianglestrips, just that you submit the center of each trianglestrip so you're like cutting many vertices away. And the billboarding is done automatically.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.