Jump to content
  • Advertisement
Sign in to follow this  
Skiller

Delayed rendering for sorting

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

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]

Share this post


Link to post
Share on other sites
Advertisement
What is the point in display lists if you create them EVERY frame? You could just pass your particle structure, and draw the particles in immediate mode.

But it's likely that the slowness results from texture binding, not a lot of display lists. I haven't done a particle engine yet, but do you really need texturing? Won't color/material be enough?

Share this post


Link to post
Share on other sites
Quote:
Original post by Seroja
What is the point in display lists if you create them EVERY frame?


Well, display lists are not necessarily static things.
My engine creates display lists every frame based on the visibility pass.
Each display lists contains all renderable objects affected by a set of lights.
There are actually two display lists per light set, one for transparent sorted by Z and one for opaque sorted by shader/texture/instancing. The renderer receives display list groups and renders them.

About the particles,

Why not just use one pool of particles. Each emitter gets its particles from the pool, updates them and puts them in one large particle buffer. Then sort that one buffer by Z and render.
Probably best to use pointer to particles in the intermediate buffer that will be sorted then copy the sorted particle data into a vertex buffer.

Share this post


Link to post
Share on other sites
@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 ;)

Share this post


Link to post
Share on other sites
@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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sorry my mistake,

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

Share this post


Link to post
Share on other sites
Quote:
Original post by Skiller
@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.


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?

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?)

Share this post


Link to post
Share on other sites
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.

Share this post


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

  • 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!