Alpha blending fillrate
Author
Hey all,
I'm just wondering if anyone has any pointers for dealing with the horrendous fillrate consumption of alpha blended objects.
In my game, I have some models using opacity maps (trees, billboard plants, etc). Now at a distance, the impact is not too bad as obviously fillrate is hurt less when the effect is over a smaller screen area. The problem is when I zoom right up to an object.... the whole game world slows down hugely. Now this isn't a problem by itself, the framerate is usually still up above 65 frames per second (with about 110-200 FPS being normal) .... but I have yet to put in as many particle effects as I would like, still have AI to contest with and would like to make my physics more accurate. Not to mention that I'd also like the game to run smoothly on older machines.
Obviously I could limit the zoom as it is an overhead based game, which would make the blended areas cover less screen space, but this isn't really preferable, as I'd like players to be able to zoom into the action if they desire, so I wondered if anyone had any other tricks to reduce fillrate impact? I already know to use alpha testing to remove zero alpha areas earlier in the pipeline... so does anyone have any other optimisation ideas?
Thanks very much for any suggestions!
Cheers,
Steve
Sure thing mephs,
You shouldn't be using alpha blended objects on tree's and plants. You should be using alpha testing. This is practically free operation. In d3d you would do something like this
EnableAlphaTest(true);
AlphaRef(0x70)
AlphaFunc(Less);
There's a good article in GPU Gems 2 on grass rendering using alpha testing and a screen type effect to give good blending. I highly suggest checking it out.
You shouldn't be using alpha blended objects on tree's and plants. You should be using alpha testing. This is practically free operation. In d3d you would do something like this
EnableAlphaTest(true);
AlphaRef(0x70)
AlphaFunc(Less);
There's a good article in GPU Gems 2 on grass rendering using alpha testing and a screen type effect to give good blending. I highly suggest checking it out.
Oh I just read you said you were already doing alpha testing. Now what are you using alpha blending for exactly?
Author
Thanks for the advice, I'd stupidly not thought about simply alpha testing on it's own. The reason being that when I first implemented opacity maps, alpha testing wasn't working as intended, so I switched to blending which did the job right first time, and I'd just done it that way ever since and never considered the standard way. Anyhoo, I fixed alpha testing and it does increase the framerate by around 5 FPS or so which is better than nothing. I'm still a bit confused why my framerate still drops below normal in this particular area of my level... I wonder if it's simply a high density of objects or something.
Anyhoo... problem partially solved for now, so thanks!
Steve
Anyhoo... problem partially solved for now, so thanks!
Steve
Could it be that you are drawing back-to-front and therefore when zooming, considering have many trees stacked behind each other, would suddenly become a lot bigger (for instance, each tree would cover the entire screen many times instead of just more trees covering very small areas)?
Sure, that is the only "native" way of drawing alpha transparent sprites, but there might be less beautiful ways that would allow you to skip what is not seen (e.g. front-to-back with ugly edges)... or occlusion culling to some extent. (or perhaps it would be possible to draw front-to-back without the alpha edges, then drawing back-to-front and thus only drawing what's really seen)
This is just a pure guess and might not actually have anything to do with it.
Sure, that is the only "native" way of drawing alpha transparent sprites, but there might be less beautiful ways that would allow you to skip what is not seen (e.g. front-to-back with ugly edges)... or occlusion culling to some extent. (or perhaps it would be possible to draw front-to-back without the alpha edges, then drawing back-to-front and thus only drawing what's really seen)
This is just a pure guess and might not actually have anything to do with it.
As Syranide suggests, overdraw is also a consumer of fillrate, regardless of how much alpha blending you have going on.
- Trying to ensure a rough front-to-back render order for your opaque geometry will reduce overdraw and so fillrate, texture fetch and pixel operation overhead. The sorting need not be precise, just a rough per-object sort will suffice, let the Z buffer worry about opaque polygon and pixel sorting.
- Using a Z buffer pre-pass for your opaque geometry can be a win if you're getting a big hit from a)texture fetches and/or b)pixel shader complexity for occluded pixels. A Z prepass is still useful in conjunction with rough front-to-back sorting since one deals with pixels, and one deals with objects.
- Always render your skybox/skydome AFTER all other opaque geometry and before your alpha. Even some commercial games have been known to get that wrong - a skybox is a massive fill user and is [nearly] always occluded to some degree.
- One trick for low frequency/detail things such as smoke, fire and explosions is to render those effects to a render target texture that's smaller than the frame buffer (e.g. half the size) using the Z buffer of the scene to do the occlusion, that way, the number of read-modify-write operations and the fillrate used for the overdraw is halved. You then apply this render target texture to a big quad that's blended with the frame buffer. The main downside/tradeoff is the smaller your effect buffer is, slower moving effects don't move as smoothly.
- You can extend the above by not clearing the effect render target every frame - so for things like explosions that build up, you can just let them build up and increase in volume the render target over a few frames so that the new pixels being filled every frame is further reduced.
- Try using alpha test at the **same time** as alpha blending to exclude pixels with alpha of 0 (or close to). A pixel excluded by alpha test won't be written to the Z buffer or be subject to frame buffer blending (a frame buffer blend with an alpha of 0 is just a waste of fill - unless you're on hardware which early-outs that pixel). Do experiment with this though - particularly if you have complex pixel shaders.
- Take a close look at the textures for your alpha polygons, if there are a lot of opaque, A=100% pixels (say over 30% - depending on how much extra batches cost on your hardware and API), then it can be a win to render things using that texture in two passes:
PASS1: render object as opaque geometry (including front-to-back sorting); Z writes on, alpha blend OFF; and enable alpha test to exclude pixels with ANY transparency (i.e. only pass if A==1.0)
PASS2: render object again as transparent geometry along with the other transparent geometry; Z writes off; Z test on; alpha blend ON; and enable alpha test to exclude pixels that are opaque (i.e. only pass if A<1.0)
- Trying to ensure a rough front-to-back render order for your opaque geometry will reduce overdraw and so fillrate, texture fetch and pixel operation overhead. The sorting need not be precise, just a rough per-object sort will suffice, let the Z buffer worry about opaque polygon and pixel sorting.
- Using a Z buffer pre-pass for your opaque geometry can be a win if you're getting a big hit from a)texture fetches and/or b)pixel shader complexity for occluded pixels. A Z prepass is still useful in conjunction with rough front-to-back sorting since one deals with pixels, and one deals with objects.
- Always render your skybox/skydome AFTER all other opaque geometry and before your alpha. Even some commercial games have been known to get that wrong - a skybox is a massive fill user and is [nearly] always occluded to some degree.
- One trick for low frequency/detail things such as smoke, fire and explosions is to render those effects to a render target texture that's smaller than the frame buffer (e.g. half the size) using the Z buffer of the scene to do the occlusion, that way, the number of read-modify-write operations and the fillrate used for the overdraw is halved. You then apply this render target texture to a big quad that's blended with the frame buffer. The main downside/tradeoff is the smaller your effect buffer is, slower moving effects don't move as smoothly.
- You can extend the above by not clearing the effect render target every frame - so for things like explosions that build up, you can just let them build up and increase in volume the render target over a few frames so that the new pixels being filled every frame is further reduced.
- Try using alpha test at the **same time** as alpha blending to exclude pixels with alpha of 0 (or close to). A pixel excluded by alpha test won't be written to the Z buffer or be subject to frame buffer blending (a frame buffer blend with an alpha of 0 is just a waste of fill - unless you're on hardware which early-outs that pixel). Do experiment with this though - particularly if you have complex pixel shaders.
- Take a close look at the textures for your alpha polygons, if there are a lot of opaque, A=100% pixels (say over 30% - depending on how much extra batches cost on your hardware and API), then it can be a win to render things using that texture in two passes:
PASS1: render object as opaque geometry (including front-to-back sorting); Z writes on, alpha blend OFF; and enable alpha test to exclude pixels with ANY transparency (i.e. only pass if A==1.0)
PASS2: render object again as transparent geometry along with the other transparent geometry; Z writes off; Z test on; alpha blend ON; and enable alpha test to exclude pixels that are opaque (i.e. only pass if A<1.0)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
