Why does smoke slow down rendering so much?
- Thread starter Raqia
- Start date
"Monster" isn't always enough. Redrawing the entire screen multiple times is hard enough, but adding alpha blending on top of that can make even very simple visuals cost a lot.
It's not about the geometry load - a few rectangles spinning arround is not a big thing, but alpha blending these "smoky" textured planes, makes any HW reject/cull inadequate and thus a lot of bandwidth is involved in heavy read/write op's, and the more of those alpha blended planes are there, the more overdraw factor is.
I remember, that it is possible in PS3.0 to "cancel" group of pixels/fragments, so the heavy blending duty to be minimized. Anyone more on this?
I remember, that it is possible in PS3.0 to "cancel" group of pixels/fragments, so the heavy blending duty to be minimized. Anyone more on this?
IgnorancePersonified
Regular
Isn't smoke in Half Life engine games sprites? What effects the peformace of that?
Best looking smoke was the stuff in COD2 demo - though I am guessing that is quite a different toke.
Best looking smoke was the stuff in COD2 demo - though I am guessing that is quite a different toke.
IgnorancePersonified said:
Its a combination of 2 things usually, first the gpu, has to calculate z-sort (if z-sort is being used) and alpha blend. Both get pretty heavy if not optimized, and from what I've seen in most engines these are almost never optimized
. Z-sort should never be used to begin with it has an exponetial calucation effect depending on objects that use it on the screen, an algo based on radix would be a much better option. Alpha blend hurts a good deal too. But there is ways to code a shader that will do this almost for free on newer hardware (sm 2.0 and up)Secondly depending on number of particles and number of particle entities it could be hurting the CPU.
To my knowledge, there are very few systems that support true per-pixel Z-sorting in the graphics hardware and that includes about 0% of current PC systems.Razor1 said:
The sorting of the translucent polygons is done in the application and then sent to the hardware in the required back-to-front order. (I'm discounting Z-peeling as impractical)
But by emulating a real TBDR using, errrr, Vertex Texturing, of course! *grins* It's funny how many people believe just about everything can be offloaded half-efficiently.Simon F said:
Uttar
EDIT: A pretty nice way to speed-up smoke rendering would be to be able to combine alpha test & alpha blend in a single pass: it would always write to the color buffer, but only to the Z-Buffer if the alpha is >= a certain value (could even benefit from it with 1 for some kinds of particle or smoke effects). Some engines already do this in 2 passes, but imo that's not a big gain.
Last edited by a moderator:
You can implement variants of bitonic sorts on the GPU quite easily.Simon F said:
It won't be much faster than a CPU-based sort on small datasets (< 1 million entries).
It's largely memory bandwidth.
There are other issues on the CPU side of the PC notably sorting (if they bother) and submitting the particles efficiently, since any call to DrawPrim is an expensive operation.
Given the Hi resolutions that most people run PC's games at and the LARGE amounts of transparent overdraw most smoke effects have, coupled with the fact that read modify write is just about the worst way possible to access any memory (dropping it's real world bandwidth dramatically over the advertised figures), it's not really surprising.
There are other issues on the CPU side of the PC notably sorting (if they bother) and submitting the particles efficiently, since any call to DrawPrim is an expensive operation.
Given the Hi resolutions that most people run PC's games at and the LARGE amounts of transparent overdraw most smoke effects have, coupled with the fact that read modify write is just about the worst way possible to access any memory (dropping it's real world bandwidth dramatically over the advertised figures), it's not really surprising.
And how do they compare for data sets < 20?Bob said:
What are we sorting, btw? Have we loaded the N values into a texture and then sorting by running multiple renders to obtain the final sorted result in the framebuffer? How is that going to be a practical solution for sorting a few dozen polygons in the current render?
deviantchild
Regular
The fog in Silent Hill 2 seems pretty cool - although it's hard to tell how efficient it is when you're playing it on an overspec'd system. I think playing with the noise effect on is essential too.
Smoke doesn't really slow everything down, it just makes everything seem to slow down.
Happens to me all the time when I'm baked, just relax and enjoy it.
Happens to me all the time when I'm baked, just relax and enjoy it.
Similar threads
