I got my particle system up and running, made some awesome looking smoke (if I do say so myself) but when I added fire to the equation using a 2nd emitter I noticed I had some problems: Although I fixed alpha sorting/blending problems for 1 particle emitter, when a 2nd emitter is in the scene it's particles arent sorted with the particles from the first resulting in some undesirable graphics (see screen shots). After some thinking I decided to make a new class that would store an array of display lists, their depth, and thier texture/blending settings. Each frame instead of rendering I'd create a display list and pass it and the other appropriate values to this class then have the class sort them all by their depth (back to front) and then call the sorted lists and changing texture/blending settings when necessary. It worked :D *BUT* at a poor 12 frames per second, well below the 60+ previously attained. After some profiling I found that the part that was killing me was the display lists, which makes sense since there was 400+, each only rendering a 2 poly tri-strip with billboarding. So my problem is, how can I postpone the rendering of an object till after it is sorted with other objects without using a display list? I want to be able to sort all polys with alpha not just particles and am not too keen on the idea of using function pointers (tho that's the best idea I can come up with atm). Screen Shots: Smoke rendered 2nd (looking good) Smoke rendered 2nd (looking bad) Fire rendered 2nd (looking good) Fire rendered 2nd (looking bad) I like my smoke, please help make it better :) [Edited by - Skiller on November 28, 2005 9:45:09 AM]

Better solution were shaders. There are samples in ATI RenderMonkey for OpenGL and DirectX on particle systems.

@Seroja
I was using display lists because they can store the matrix information for billboarding and because they can be used for any polys with alpha. At the moment the only polys using alpha are the particles, but I'll be wanting to add beams and such later on and they'll need to be sorted with the particles. Also the slowness wasn't from constant state/texture changing, I profiled the changes and it was only taking 0.0008 secs a frame, a far cry from the 0.078 secs that the delete lists was taking.

@Red_falcon
Are those shaders fp20 compatible? I'm aiming at GeForce 4 as min requirement and gf4 only has fp20 shader profile :(.

@Scythen
I'm already using pools for my particles to avoid dynamic memory allocation so it would be easy to set up, but as mentioned I would like a more generic solution so that I can use it for beams and other polys with alpha.

I think I'd better change topic name since it not really just for particles ;)

@Skiller

I have ATI Radeon 9800 Pro. If i'm not wrong it has fp20 only too. All examples from RenderMonkey (OpenGL or DirectX) are running with my card.

I'm pretty sure ATI Radeon 9800 Pro and even I think the 9600s support fp30, you might be getting confused with pixel shader 2.
If memory serves fp20 = pixel shader 1.x, fp30 = pixel shader 2.

Sorry my mistake,

just installed RenderMonkey again and noticed, that almost all GL examples are GLSL. I don't know if gf4 supports glsl.

Quote:Original post by Seroja
Can't these commands be issued in immediate mode? They might be slower to execute, but won't it compensate for the overhead of creating and deleting lists?

True, but then the problem is that I'd have to store an extra variable to say what type of thing is to be rendered, particle, beam, mesh ect. then have a big if else if list for all the different rendering types since they need to be rendered differently. For this to be managable/readable I'd probably need to use function pointers (this is the way I was thinking of doing it from first post) which when being called 400+ times a frame could incur a drop in speed (tho probably not as much as I fear ;) ).

Quote:Original post by Seroja
And generally, is there any reason to create display lists unless the same list is going to be called multiple times? (Or are you rendering every particle several times?)

Not really, I was just after a generic way to render different things with minimal effort to implement.
The way I used render particles is create a particle of size 1 with tex coords, put that in a display list. Each particle would set up the matrix rotation/position so it always faced camera, set desired color then scaled it to size and called the display list.
Now I put the setting up of matrix, color, size and call to "prototype" particle into another display list and just pass the resulting GLuint to the sorting/rendering class as mentioned in first post.